RISC-V ABIs and stack alignment (was Re: [sw-dev] Re: Towards a "golden model" of the RISC-V calling convention(s))

131 views
Skip to first unread message

Alex Bradbury

unread,
Sep 7, 2017, 3:57:06 PM9/7/17
to Bruce Hoult, Andrew Waterman, Stefan O'Rear, Samuel Falvo II, RISC-V SW Dev
On 7 September 2017 at 20:36, Bruce Hoult <br...@hoult.org> wrote:
> OK, so .. a concrete proposal:
>
> There are at least four mutually-incompatible ABIs already, counting only
> floating point differences (M and C multiply this further of course):
>
> 1) RV32 soft float
> 2) RV32 hard float
> 3) RV64 soft float
> 4) RV64 hard float
>
> (I suspect RV64 soft float might be comparatively rare, but let's assume
> someone in the embedded world wants it)

I've changed the mail subject, as this thread has deviated from its
original topic.

M and C don't affect the ABI - I can freely link code including M and
C instructions however I want, the calling convention and object+stack
layout is unmodified. But there are actually more ABIs than you
suggest:

1. RV32E: -march=rv32e -mabi=ilp32 [this is the only case where stack
alignment depends on -march]
2. RV32I: -march=rv32i -mabi=ilp32
3. RV32IF: -march=rv32if -mabi=ilp32f
4. RV32G (RV32IFD): -march=rv32ifd -mabi=ilp32d
5. RV64I: -march=rv64i -mabi=lp64
6. RV64IF: -march=rv64if -mabi=lp64f
7. RV64G (RV64IFD): -march=rv64ifd -mabi=lp64d
8. RV64IFDQ: -march=rv64ifdq -mabi=lp64q

You can probably assume 6) and 8) will see little use - even if Q is
implemented, it seems likely systems will try to stick to the RV64G
ABI to maximise software compatibility.

Best,

Alex

Bruce Hoult

unread,
Sep 7, 2017, 4:10:12 PM9/7/17
to Alex Bradbury, Andrew Waterman, Stefan O'Rear, Samuel Falvo II, RISC-V SW Dev
I did say "at least".

I don't understand what would prevent a library compiled for RV64IF from being linked to code compiled for RV64G and use on an RV64G machine *unless* they have different required alignments.

Does RV64IF mean that you can use double FP in your code but it'll be passed in integer registers/stack?

In any case, if all those you list above are immiscible then they could logically, with no harm to anything, have required alignments as follows:

4: RV32E, RV32I, RV32IF
8: RV32G, RV64I, RV64IF, RV64G
16: RV64IFDQ



--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CA%2BwH297d6fGLY4WgfBrzLaj4ptLpswXhxENgx-wJcCOgg8HF%3Dg%40mail.gmail.com.

Stefan O'Rear

unread,
Sep 7, 2017, 4:11:24 PM9/7/17
to Bruce Hoult, Alex Bradbury, Andrew Waterman, Samuel Falvo II, RISC-V SW Dev
On Thu, Sep 7, 2017 at 1:10 PM, Bruce Hoult <br...@hoult.org> wrote:
> I did say "at least".
>
> I don't understand what would prevent a library compiled for RV64IF from
> being linked to code compiled for RV64G and use on an RV64G machine *unless*
> they have different required alignments.
>
> Does RV64IF mean that you can use double FP in your code but it'll be passed
> in integer registers/stack?

Yes.

-s
Reply all
Reply to author
Forward
0 new messages