Unclear size of FWFT Feature Types (Chapter 18) #174
Comments
|
Good catch. |
|
Yes clearly that should be defined as |
|
The documentation says:
This doesn't read very clearly to me. Does that mean the function should be declared as taking an unsigned long but only read 32 bits from it? Or does it mean the function should be declared as taking a 32-bit integer? Also it seems to suggest that the high bits of the register on RV64 can be junk, which is notably not what the psABI says, so you can't just forward the register in assembly to a C function taking a uint32_t. |
|
Though it seems there are a number of interfaces already taking uint32_t and hitting that exact case of a lack of adequate documentation... |
As reported on github [1], the feature types values are described as 32 bits identifiers but declared as unsigned long in function arguments. Use uint32_t for the parameters types to be coherent. Link: riscv-non-isa#174 [1] Reviewed-by: Andrew Jones <[email protected]> Reviewed-by: Atish Patra <[email protected]> Signed-off-by: Clément Léger <[email protected]>
As reported on github [1], the feature types values are described as 32 bits identifiers but declared as unsigned long in function arguments. Use uint32_t for the parameters types to be coherent. Link: riscv-non-isa#174 [1] Reviewed-by: Andrew Jones <[email protected]> Reviewed-by: Atish Patra <[email protected]> Signed-off-by: Clément Léger <[email protected]>
As reported on github [1], the feature types values are described as 32 bits identifiers but declared as unsigned long in function arguments. Use uint32_t for the parameters types to be coherent. Link: #174 [1] Reviewed-by: Andrew Jones <[email protected]> Reviewed-by: Atish Patra <[email protected]> Signed-off-by: Clément Léger <[email protected]>
In the text the FWFT feature types are described as "32-bit identifiers", but in function calls they are described as
unsigned long, which will result in 64-bit identifiers.The text was updated successfully, but these errors were encountered: