Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Register
  • Sign in
  • S sdv-lammps
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 100
    • Issues 100
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Terraform modules
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • djurado
  • sdv-lammps
  • Wiki
  • Home

Home · Changes

Page history
Update Home authored Jan 17, 2023 by djurado's avatar djurado
Hide whitespace changes
Inline Side-by-side
Home.md
View page @ e4fb5b5f
......@@ -106,18 +106,20 @@ The proposed solution was to try to use `vwadd` with inline assembler, but that
For the implementation of this instruction in the VPU, output is written to two consecutive registers, altough only one is specified as an operand.
This can lead to compilation errors, since the inline assembler is not aware of this and may automatically choose a combination of input and output registers that overlap, and generate and error when assembling the instructions.
Sometimes the compiler produces this error, but changing the optimization setting (from -O0 to -O2) can fix the issue since a different combination of registers may be used which happen to not overlap.
For this reason, this approach has not been used.
For this reason, this approach has been discarded.
In the end, a bithack trick was used to extend the array of 32-bit unsigned integers into a vector register with SEW width of 64-bits.
The trick is to load the 32-bit array into a register with 64-bit SEW, and then use an `vand` operation to blank the most significant half of the elements, mimicking an extension with zeros.
To get the other half, it is needed to perform a shift right logic before applying the `vand`.
This method is very low level and depends on the endianness of the system in order to work (TODO elaborate why).
Moreover, it also requires a bit of extra handling for the case in which the array has and odd number of elements.
In addition, this method also requires a bit of extra handling for the case in which the array has and odd number of elements.
The following figure shows a representation of the operations needed for the 32-bit to 64-bit conversion.
To see the code in detail, check annex (TODO).
![evenodd](uploads/82a21f4b6d4321ea2481d04fa9818f9e/evenodd.png)
It is important to check if a unaligned memory access exception can be produced with vector loads.
For instance, to place a 32-bit array inside a 64-bit register, performing a load with a SEW of 64 eventually produces an unaligned access exception.
For this reason, it is needed to perform the memory load with a SEW of 32, and the move the contents to a 64-bit register using `vmv.v.v` (as with TODO union_int_float_t in section X).
For instance, to place a 32-bit array inside a 64-bit register, performing a load with a SEW of 64 produces an unaligned access exception if the starting address is not aligned.
For this reason, it is needed to perform the memory load with a SEW of 32, and then move the contents to a 64-bit register using `vmv.v.v` (as with TODO union_int_float_t in section X).
### Handling union_int_float_t
......
Clone repository

Home

  1. Introduction
  2. Overview

  • Sidebar