[meta] ABI deviations

[kito-cheng]

It's meta issue for tracking all ABI deviations.

Anders@IAR has released the first version of the proposal of EABI deviations, the full document is attached, we will use this proposal as base to start the discussion.

Background

A question about an embedded ABI was raised in the RISC-V community. The main reason why a separate embedded ABI was requested, was the fear that a rather high number of temporary (caller save) registers would have an intolerable impact on interrupt functions.

An EABI task group was formed to sort it out, but it turned out that the problem was more complex than anticipated. Later on the work in the EABI TG was transferred to the psABI TG, and the EWRISCV team at IAR Systems AB was appointed to investigate how an ABI for embedded applications should be designed.

The IAR investigation

We have concluded that an embedded ABI in a traditional sense should not be needed. A separate EABI (with fewer temporary registers) would result in both slower and larger regular code, and the problem with many temporary registers for interrupt functions can be handled.

By offering a set of deviations from a main ABI, all of the needs for embedded applications can be fulfilled.

The main objectives in our work have been:

• The deviations must be defined by what can be done in the future. We cannot let current limitations in today’s tools being the guideline in our work. The RISC-V architecture will probably be used for at least 50+ years to come, so the future must be our guideline.
• The deviations must be defined in a way so we tool vendors can implement and improve support for each deviation in a reasonable pace. It must be ok to not support one or more of the proposed deviations.
• Keeping the number of main/top ABIs as low as possible in order to minimize the complexity of the tool ecosystem. This means that the calling conventions for regular non-embedded applications and embedded applications will be the same.
• Handel the deviations as well-defined sidesteps from an ABI. The deviations should be seen as a number of features one can use for fine tuning primarily embedded applications.
• Deviations from an ABI should always be safe and result in smaller and/or faster code when applicable. No sloppy solutions or dirty fixes are allowed!
• The proposed solutions should also be useful for non-embedded applications when applicable.

What is the process?

• Identify and collect possible deviations.
  • First version is proposed by IAR.
  • Create github issue for each deviation to tracking and collect feedbacks
• Discuss the deviations and then follow up in meetings, we may decide to change, accept or reject the proposed deviations individually
• Define the syntax, semantic and encoding.

What is ABI deviation?

Each ABI deviation means an option of ABI design, so that users could pick up the best deviation combination for their own embedded application.

Deviation

• Reservation of registers
• Usage of the tp register
• Usage of the gp register
• Data type restrictions
• Stack alignment
• Interrupts
• Endianess

[asb]

Just a drive-by comment on this - it's clearly a post 1.0 issue.

I think supporting embedded targets through a series of optional "deviations" is an interesting proposal and definitely something that should be considered. But it's not immediately obvious that the result will be better for the RISC-V ecosystem (and toolchain developers ability to deliver well tested and reliable compilers) vs defining a smaller number of specific embedded ABIs. I assume we'll be able to review as more data is available / proposals are made.

[kito-cheng]

Document for more detail proposal from IAR: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/eabi/eabi.adoc

[jnk0le]

Considering the interrupt stuff I came across recently: __attribute__((interrupt("WCH-Interrupt-fast"))) which is said to be equivalent to naked function + extra mret instruction. (llvm refuses here to generate from anything but inline asm)

I think that we need something more powerfull. The __trampoline,__xreg,__freg (and maybe __vreg?) is not enough.

lets consider use cases:

• CLIC trampoline engine or custom hardware stacker, stacking (non standard for CLIC) subset of caller saved registers for better interrupt latency maintaining balanced perf in "typical applications"
• 8051/FIQ like register windowing of all registers except sp/gp (WCH case?)
• 8051/FIQ like register windowing of simplified ranges, like x8-x15 (s0,s1 "prestacked" instead of the bottom regs)
• using hardware stacker/windower designed for e.g. ILP32E under future EABI (otherwise it means an ABI lock-in or underutilization)
• above applied to FP/vect regs

All of those would require custom toolchain like in WCH case for full utilization of HW stacking or working at all.

Something like: __attribute__((interrupt("very_long_string_exactly_describing_prestacked_registers_etc"))) with some short name aliases for common/standard stacking, should cover any possible custom stacker without needing a custom build toolchains.

Tracking the register usage should therefore be doable even in dynamically linked applications, as the interrupt functions most likely have all the information needed when they are built. Register tracking is however not mandatory as it is merely a type of optimization that may be implemented in some future toolchains.

Doable by something like described here: https://github.com/riscv-non-isa/riscv-eabi-spec/issues/12 tracking callbacks will be problematic.

I'm still not sure how dynamically linked code can be tracked without de-facto creating custom ABI for each exported function, that can't be changed once it starts to grow/shrink over time/patches.

[jnk0le]

Document for more detail proposal from IAR: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/eabi/eabi.adoc

adoc/markdown turns that 80col formatting into infinitely long lines until empty newline. RAW version is a bit more readable at the moment.

[asb]

EDIT: Scratch my previous question - I'd missed that the link was to a separate branch rather than master/main.