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