Skip to content
This repository has been archived by the owner on Feb 15, 2024. It is now read-only.

Statement about handling of 32-bit floating point numbers on RV64 doesn't match the current psABI #14

Open
asb opened this issue Jan 24, 2022 · 2 comments

Comments

@asb
Copy link

asb commented Jan 24, 2022

The specification states "Sign-extending 32-bit floating-point numbers when held in RV64 x registers matches the existing RV64 calling conventions, which require all 32-bit types to be sign-extended when passed or returned in x registers."

But this doesn't match the psABI, which states "When passed in registers or on the stack, floating-point types narrower than XLEN bits are widened to XLEN bits, with the upper bits undefined.". See also here.

CC @kito-cheng @jrtc27 (as psABI TG chairs)

@jrtc27
Copy link

jrtc27 commented Jan 24, 2022

I imagine the real motivation is that C.LW exists but not C.LWU? Otherwise it doesn't matter what gets picked.

asb added a commit to asb/riscv-isa-manual that referenced this issue Mar 24, 2023
…in GPRs

As I noted previously in
<riscvarchive/riscv-zfinx#14>, it's incorrect to say
that floating point values passed in GPRs are signed-extended in the
standard calling convention. The [current, ratified
psABI](https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/6cda8927232dc59424426f4dd0de2e0723d865fb/riscv-cc.adoc)
states "Floating-point reals are passed the same way as aggregates of
the same size" and the relevant part from the description of
aggregates is "Bits unused due to padding, and bits past the end of an
aggregate whose size in bits is not divisible by XLEN, are undefined."
@asb
Copy link
Author

asb commented Mar 24, 2023

It seems zfinx now lives in riscv-isa-manual. I've filed a PR to correct this riscv/riscv-isa-manual#998

asb added a commit to asb/riscv-isa-manual that referenced this issue Mar 24, 2023
… in GPRs

As I noted previously in
<riscvarchive/riscv-zfinx#14>, it's incorrect to say
that floating point values passed in GPRs are signed-extended in the
standard calling convention. The [current, ratified
psABI](https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/6cda8927232dc59424426f4dd0de2e0723d865fb/riscv-cc.adoc)
states "Floating-point reals are passed the same way as aggregates of
the same size" and the relevant part from the description of
aggregates is "Bits unused due to padding, and bits past the end of an
aggregate whose size in bits is not divisible by XLEN, are undefined."
asb added a commit to asb/riscv-isa-manual that referenced this issue Mar 24, 2023
… in GPRs

As I noted previously in
<riscvarchive/riscv-zfinx#14>, it's incorrect to say
that floating point values passed in GPRs are sign-extended in the
standard calling convention. The [current, ratified
psABI](https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/6cda8927232dc59424426f4dd0de2e0723d865fb/riscv-cc.adoc)
states "Floating-point reals are passed the same way as aggregates of
the same size" and the relevant part from the description of
aggregates is "Bits unused due to padding, and bits past the end of an
aggregate whose size in bits is not divisible by XLEN, are undefined."
asb added a commit to asb/riscv-isa-manual that referenced this issue Mar 24, 2023
… in GPRs

As I noted previously in
<riscvarchive/riscv-zfinx#14>, it's incorrect to say
that floating point values passed in GPRs are sign-extended in the
standard calling convention. The [current, ratified
psABI](https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/6cda8927232dc59424426f4dd0de2e0723d865fb/riscv-cc.adoc)
states "Floating-point reals are passed the same way as aggregates of
the same size" and the relevant part from the description of
aggregates is "Bits unused due to padding, and bits past the end of an
aggregate whose size in bits is not divisible by XLEN, are undefined."
asb added a commit to asb/riscv-isa-manual that referenced this issue Mar 24, 2023
… in GPRs

As I noted previously in
<riscvarchive/riscv-zfinx#14>, it's incorrect to say
that floating point values passed in GPRs are sign-extended in the
standard calling convention. The [current, ratified
psABI](https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/6cda8927232dc59424426f4dd0de2e0723d865fb/riscv-cc.adoc)
states "Floating-point reals are passed the same way as aggregates of
the same size" and the relevant part from the description of
aggregates is "Bits unused due to padding, and bits past the end of an
aggregate whose size in bits is not divisible by XLEN, are undefined."
aswaterman pushed a commit to riscv/riscv-isa-manual that referenced this issue Mar 24, 2023
… in GPRs (#998)

As I noted previously in
<riscvarchive/riscv-zfinx#14>, it's incorrect to say
that floating point values passed in GPRs are sign-extended in the
standard calling convention. The [current, ratified
psABI](https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/6cda8927232dc59424426f4dd0de2e0723d865fb/riscv-cc.adoc)
states "Floating-point reals are passed the same way as aggregates of
the same size" and the relevant part from the description of
aggregates is "Bits unused due to padding, and bits past the end of an
aggregate whose size in bits is not divisible by XLEN, are undefined."
wmat added a commit to riscv/riscv-isa-manual that referenced this issue Apr 3, 2023
Manually applying commit #998.  As I noted previously in
<riscvarchive/riscv-zfinx#14>, it's incorrect to say
that floating point values passed in GPRs are sign-extended in the
standard calling convention. The [current, ratified
psABI](https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/6cda8927232dc59424426f4dd0de2e0723d865fb/riscv-cc.adoc)
states "Floating-point reals are passed the same way as aggregates of
the same size" and the relevant part from the description of
aggregates is "Bits unused due to padding, and bits past the end of an
aggregate whose size in bits is not divisible by XLEN, are undefined."
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants