[13] defacto established "industry standard" of efficient interrupt handling. Anyone complaining about risc-v likes and wants the NVIC.

The addition of trustzone in armv8m, increases the interrupt latency/jitter due to the need of preserving and zeroing extra "unnecessary" registers. (to prevent potential leaks)

CLIC CLIC is a designated goto for interrupt handling to fulfill everyone needs.

Attempts to be an unix capable interrupt controller with horizontal nesting of U, S, H (so far only proposed) and M mode.

All used registers must be saved in software, trampoline handlers need to save all ABI registers. If interrupts can be taken at multiple privilege modes, then each handler at higher privilege have to swap stack pointer (and interrupt level ??) by 2 additional CSR instructions per handler. (during vertical nesting those instructions just copy rs1 operand)

Preemption is handled in software by special CSR mechanism, that requires extra boilerplate code in every interrupt handler. Even in "inline" handlers.

Highest priority inline handlers should be possible to be made similar to legacy ones.

Trampoline handlers mimic the late arrival and tail chaining optimizations. Currently trampoline handlers cannot be used alongside "inline" handlers [50].

Introduces unavoidable jitter due to:

• blocks of code executed with disabled interrupts (additive jitter)

• late arrival handled through mnxti read (subtractive jitter of entry time)

• tail chaining handled by another mnxti read (and extra branch) in epilogue

• indirect jump instruction to actual code (branch prediction)

assuming 1 cycle per instruction, 10.2 and 11.1 listings from clic spec CLIC offer:

• entry + 6 cycles of jitter from "inline" handlers.

• entry + 7 + 16 cycles of jitter from "C-ABI" trampoline entry

• 4 + exit or abs(entry - 7) cycles of jitter from "C-ABI" trampoline epilogue

Typical interrupt latency of CLIC trampoline was measured at 33 (inline handler) and 42 (trampoline) cycles for CV32E40P [53].

CV32RT "fastirq" [53] extends CLIC by moving prologue handling entirely into the hardware as well as introducing background lazy stacking from a shadow register set.

The epilogue is still handled in software.

Tail chaining is supported by emret instruction, but a late arrival (higher priority) will have to wait for the background stacking to finish. As a consequence there is a jitter equal to the stacking window.

emb-riscv [1] is clean sheet design that attempts to be universal solution for every microcontroller. Designed with a strong focus on RTOS support.

Achieves lower interrupt latency by introducing EABI with reduced amount of caller-saved registers. FP registers are handled by lazy stacking.

Many similarities with NVIC.

mandates 4 64bit timers (even on RV32):

• cycle counter

• instret counter

• system timer

• rtc timer

Attaches to generic interrupt scheme.

According to CLINT, it provides memory mapped interface for timers and IPI.

Very often refered to as CLINT. e.g. [4].

has optional vectored mode which simply jumps to the position in vector table.

Doesn’t provide any nesting other than privilege levels or a complex boilerplate code to disable reatking active interrupts. Registers and CSR state (fcsr etc.) have to be pushed by software before use

[5], [6]

A heavyweight frontend for delivering interrupts to multiple cores running typical unix OS. Not suitable for microcontrolers.

claim/complete architecture

handlers stay very similar to generic case.

AIA adds another set of CSR registers available only through indirect access mechanism (by miselect and mireg CSRs).

Proprietary design by WCH build on top of generic riscv privileged [28], [29], [30].

Introduces HW stacking and single cycle register shadowing (aka HPE). It is of course necessary to use custom toolchain that implement a "proprietary" attribute: __attribute__((interrupt("WCH-Interrupt-fast")))

Another feature is "vector table free" interrupt mechanism that allows to skip fetching from vector table and jump to handler directly. It provides significant improvement only when all registers are "stacked" by shadow regfile. (or not satcked at all)

The descriptions of a lot of functional behaviour feel like a copy-paste of risc-v privileged. Highly under/undocumented.
e.g. There is nothing about what happens to mepc, mcause or mstatus during nesting (especially on "V2" core).
It is also unknown whether ra register doesn’t have an additional use (like saving mepc…​) during interrupt entry/exit and connot be used immediately as the currently implemented gcc attribute treats those functions the same way as the regular ABI ones with mret based return.
Inline with average chinese documentation standards.

The vendor provided headers, of course, contain 46 instances of "NVIC" string and just 5 for "PFIC"

There is also under/undocumented "EABI enable" bit in INTSYSCR on "V2" core. Most probably it reduces number of HW stacked registers to match the official EABI proposal [31].

QingKeV4 implements 3 shadow registers sets (aka HPE), given to handlers on first comes first served basis. Result is that only 3 lowest level handlers can practically use shadow registers.

[44] Adds another horizontal nesting level above the machine mode, that works very similarly to generic interrupts. Achieved by providing additional set of CSR registers as well as interrupt return instruction (mnret).

Note: The IRQ handling features in PicoRV32 do not follow the RISC-V Privileged ISA specification. Instead a small set of very simple custom instructions is used to implement IRQ handling with minimal hardware overhead.

Original author of the PicoRV found the riscv-privileged to be too heavy for minimal core, and provided own [9] interrupt scheme.

Proprietary TI architecture [23] sporting an ancient looking accumulator-memory architecture (with 8 pointer registers), similar to the classic CISCs. An x86 of motor control and signal processing. FPU [24] is more RISC-ish with a bit of VLIW in some instructions.

According to [22], the core automatically saves some of the registers, rest must be pushed in software.
"High priority" interrupts can also save and restore all 8 floating point registers into shadow registers using special instructions.
There are also 5 (4 in prologue) defacto useless instructions for aligning stack and setting "C28 modes"

To allow nesting of "low priority" interrupts handlers must include extra boilerplate code to handle prioritiy masking in software. (8 instructions in prologue, 3 in epilogue)

As a consequence there is 21 cycles of jitter (to HPI and other LPIs) and 43 (HPI) or 63 (LPI) cycles of interrupt latency in worst case.

Use of RPT istruction will introduce even more jitter and latecy as the sequence is uninterruptible and takes arbitrary numbers of cycles to execute.

CLA [51] is a separate coprocessor designated to offload main core from control loop tasks "freeing it to handle other tasks such as handling communication stacks"
Exactly those workloads that are general purpose tasks for which "c2000 architecture was not optimized for"

Offers less registers/instrucrtiions and lacks TMU so it’s not always faster than the main core.

Can be used as a true coprocesor for delegation of certain tasks to it. According to [52] this mode of operation brings just 12% improvement in motor FOC current loop.

CLA tasks are uninterruptible. TI claims [14],[15],[27] that their task driven machine "reduces interrupt latency and jitter" compared to classic CPU even though it does exactly the opposite when there is more than one (async) interrupt to handle (which happens in [14] example)

Xh3irq extension (as implemented by hazard3) [54] provides nested and vectored interrupt handling that is conceptually similar to CLIC (mnxti) trampoline.

Unlike CLIC, dispatcher has to index pointer array in software (by using index from meinext)

Example handler implements only jumptable but it can be easily convertod into pointer table.

Access to configuration bits of all 512 inputs is performed by inline windowing of configuration CSRs, which is incompatible with zicsrind.

In this case interrupts must always push all caller saved registers to be able to use functions without __attribute__((interrupt*)) annotation. Leading to ABIs with less caller saved registers

It also requires preinitialized table with pointer to startup code, sp, gp, and of course any other addition like Zcmt JVT csr.

This table is also not necessarily smaller than software setup, e.g. sp can be usually done with single lui instruction.

There is still a risk of corruption if the compiler decides to reorder something before initialization of .data/.bss sections.

Such startup code is also inefficient as it will have to obey the ABI (spill ra to stack) and compilers can’t optimize out link time symbols anyway. (even though some can be assumed to always be at certain addresses or offset from each other)

Of course I often find that there is a competition on who will make the worst startup code in assembly. So pure C/C++ startup code turns out to be "better" due to confirmation effect. But let’s have a look at my "combotablecrt" implementation [7] for stm32f030x4/6. Is your compiler able to do that?

There is also a case of interrupt handlers that are using only a few registers and don’t need to take latency of the whole ABI/EABI.

The rationale of introducing ABIs with reduced number of caller saved registers is to reduce interrupt latency.

The major downside of such approach is lowered overall performance and code denisty. Which is highly unliked across riscv community [10] and stalls development of such (E)ABI.

I think for marketing reasons we should have the RISC-V EABI mimic the competitor ABI as closely as possible, and be available and supported by the tools, even if almost no-one should end up actually using it.

Zcmp[e] was also prepared for such fragmentation by reserving first 4 points in rlist for EABI, so the cores can implement UABI and EABI push/pop instructions at the same time. Those 4 points are, of course, supposed to handle 20 caller saved regs of EABI (probably with some reuse of few higher points).

It will also make the processors capable of stacking 2 registers per cycle, underutilized during HW stacking due to shorter stacking time than pipeline refill.

An alternative is to provide interrupts with defacto customizable ABIs by e.g. prestacked annotation (to match the HW stackers) and handle the function call pressure by IPRA.

aka generic riscv __attribute__((interrupt))

The major issue lies within the principles of hardware stackers.

When entering interrupt handler, the core first fetches the entry from vector table and then jumps to that address. Both of those fetches can hit a flash waitstate or a cache miss. During that operation the data bus remains idle waiting for a first store instruction to be executed.

Those cycles can be accomodated for a "free" stacking of registers. If a higher amount of registers is stacked then it can hide a bit of jitter coming from cache misses or flash waitstates.

Even stacking by the special push instructions (e.g. XTheadInt [12] or PUSHINT [11] and maybe a subsets of those), won’t help much. Those start pushing after the latency of double (waitstated) miss was taken.

The only situation when soft stacking yields better results is when HW stacker has to push way more registers than is actually used.

To be able to call RVE only code from RVI ABI
Recurrig thing in RVE ABI proposals.

The idea is to allow compilers and software vendors to provide a single set of precompiled libraries for RVI and RVE ABIs.

The issue with this approach is that the code arbitrarily compiled for RVE is likely to turn out to be less efficient than RVI one. It also limits the capabilities of RVI ABI like trading off argument registers for temporary/saved ones.

Having one universal solution for all possible scenarios brings a lot of inefficiency to all of them. Due to mandatory support for a lot of rarely used functionality, keeping the compatibility with unused legacy, or having to be a subset of a bigger architecture optimized for a different use cases.

Even if that "flexibility" is made completely optional and non intrusive the vendors will implement it anyway for the sake of having the longest "flexibility" bar.

aka "HANDLER_RETURN" on emb-riscv and "EXC_RETURN" on ARM

The idea is to put special pattern in ra during handler entry and exit by reusing regular return mechanism provided by the ABI. Requires certain memory area to be non executable (e.g. 0xF0000000 - 0xFFFFFFFF)

This mechanism follows the typical ABI function call and together with HW stacking, allows the interrupt handlers to be a regular C functions.

The downside is that the ra and pc both have to be pushed onto stack and in some specifc cases, it could add extra stall cycles after the tail due to the waitstates or cache miss caused by delayed prefetch.

Alternatively we can just stack the ra and put there current pc with lowest bit set to trigger handler return operation. One less register counted towards interrupt latency.

It’s simply inefficient in truly vectored scenario. The vector entries will have to be populated with jump instructions anyway. Those have to take the second round of waitstates or cache miss without amortization by register stacking.

And if the code is far away from vector table (e.g. in SRAM for more deterministic execution), compiler will have to emit a jump island, aka "veener", that will perform yet another unamortized jump. Additionally far jumps require a free register which in typical scenario reqires pushing to stack and returning to veener from handler to handle epilogue.

allocating 8 bytes per entry, allowing lui + jalr sequence, will severly trump the code density and performance in typical use scenarios.

In case of mass initialization MMIO could result in better code density CSR space is also limited.

My take is that anything architecturally coupled to the core should reside in CSR space and keep the rest in MMIO.

Nothing should exist as both.

There is no point in avoiding CSR registers when the cost of Zicsr instructions is already taken.

Very often claimed, yet those claims rarely meet with reality.

Cortex-m0 offers a "zero jitter" by optional IP (RTL for ASICs) configuration that adjusts the best case of interrupt latency by extra cycle to acommodate random stall from bus contention.

Cortex-m3/4 offer up to 6 cycles of jitter due to "late arrival" and "pop pre-emption". Regular handler entry is dominated by stacking registers, giving some headroom for extra vector/instruction fetch latency.

Cortex-m7 of course suffers from Proprietary&Confidential syndrome. Most probably it’s similar to cm3/4.

In case of C2000 CLA, TI claims [14],[15],[27] that their task driven machine (non preemptible) "reduces interrupt latency and jitter" compared to classic CPU, even though it does exactly the opposite when there is more than 1 async interrupt to handle.

The Linux cargo cult.
Because a simplest tasks suitable for bunch of 555&74s or a simple microcontroler with a few KiB of flash and RAM must be done under linux so it will work somehow "better".

To be able to properly run linux you need quite beefy unit (usually with MMU), 2-4MiB of flash, 4-8MiB of RAM (usually external DRAM), long boot time and a bad power consumption in idle.
Just to run the OS itself.

One of the the most blatant example is NOMMU linux on stm32f429 with memory mapped SDRAM that is not even cached by cpu. If the XIP image doesn’t fit in 2MiB internal flash, it has to land in external parallel NOR flash, which is of course not cached by cpu and shares bus with SDRAM.
Any attempt to touch internal SRAM regions will defeat the remaining "universality/portability of linux apps" arguments.
Not to mention much higher unit price than typical 200+Mhz cotex A5/7 SOCs.

Of course there are still actual reasons to use linux in non-realtime embedded, consisting of large collection of drivers for external devices, higher portability or access to the raw performance (at much better perf/price ratio) not available in typical microcontrollers [16].

Lazy stacking allows to skip stacking of FP registers if handler doesn’t touch floating point registers.

The main issue is that all of the caller saved FP registers are saved (execution stalls during push) onto stack whenever FP instruction is executed even though only a few of the registers are used.

Requires additional CSR to hold address of reserved space in stack frame.

So far, mostly the application processors used in bare metal.

Use cases for such also have different requirements than from typical 32bit microcontrollers.

should be 2x`XLEN`, mandated thorought entire program execution so as to not require special realignment in interrupts.

Major ilp32e issue is that the addi16sp instruction works on 16 byte stack increment. Once the c.addi range (-32..+31) is exhausted compilers have to chose beetwen denser code and more efficient use of stack.

Zcmp extension was also designed for 16 byte aligned stack. There is Zcmpe extension postponed to the future which should handle the EABI. Lowering the stack alignment requires doubling (per bit of alignment) waste of codepoints by push/pop instructions.

Low pin count devices (8-32) need a denser debug interface as the JTAG uses too many wires.

There are industry proven 2 wire interfaces like cJTAG or ARM SWD.
It would be best to have 1 wire solution like avr8 debugWIRE/updi or the WCH "SDI" (aka "SWD") [46]

Currently there is no universal solution to indicate which registers in interrupt handlers can be freely used without stacking them.

• __attribute__((interrupt)) makes all registers callee saved and uses mret to return.

• __attribute__((interrupt("SiFive-CLIC-preemptible"))) extends regular interrupt by CLIC preemption

• __attribute__((interrupt("WCH-Interrupt-fast"))) requires custom build toolchain, no floating point regs (even on the cores with F extension), still uses mret

• Or just a plain C function that requires prestacking of all caller saved registers, reuses standard return mechanism to exit interrupt context

Even worse, there are already hardware stackers designed for ilp32e and ilp32. When the new and better ABI will be introduced, it will be impossible to use with pre-existing HW stackers. The same applies to creating HW stackers that stack less registers to optimize interrupt latency.

Therefore we need universal way to annotate which registers are available for use in a given function as a defacto calller saved one (aka create custom calling convention)

• prestacked("") attribute

• no whitespaces in string parameter

• register range cover all registers between and including specified (x4-x6 is equivalent to x4,x5,x6)

• register range must span at least 3 consecutive registers

• registers/ranges are separated by comma

• calee saved registers have to be properly turned into temporary when included in the list

• CSRs taking part in calling conventions are also subject to this mechanism

• should use raw names instead of ABI mnemonics as to make it ABI agnostic (more portable)

• registers must be sorted (integer, floating point, vector, custom, then by lowest numbered)

• CSRs must be put after the architectural regfiles, those don’t have to be sorted

• must not collide with __attribute__((interrupt)) as to support "legacy" handler return mechanisms

• must not imply __attribute__((interrupt)) as well

• custom CSRs would also have to be somehow covered. (hw loops etc.)

• annotated functions should be callable by regular code

• argument registers that are passed but not included in the list, can be assumed to be unmodified after return from an annotated function

ilp32 caller saved:

__attribute__((prestacked("x5-x7,x10-x17,x28-x31")))

ilp32f, caller saved:

__attribute__((prestacked("x5-x7,x10-x17,x28-x31,f0-f7,f10-f17,f28-f31,fcsr")))

preemptible CLIC irq with simplified ranges(e.g. shadow register file):

__attribute__((interrupt("CLIC-preemptible"), prestacked("x8-x15")))

TEIC irq, range0 + shadow regs of half integer regfile (where bit 2 of operand is set, covers range1+2) and F + P extensions:

__attribute__((prestacked("x4-x7,x10,x11,x12-x15,x20-x23,x28-x31,fcsr,vxsat")))

ch32v003 irq (ilp32e + PFIC HW stacker, assuming ra doesn’t have some undocumented use):

__attribute__((interrupt, prestacked("x1,x5-x7,x10-x15")))

So far implemented only by llvm [8].
Limited to statically linked code.
There are almost no benchmarks results, especially the ones other than x86 at -O3.

In simple explanation, it makes every function export information about its usage of caller saved registers effectively allowing non leaf functions to use caller saved registers as a callee saved ones. That avoids some of the stacking/spilling leading to a more efficiet code.

requirements and improvements needed for efficient IPRA:

• this mechanism must cover the CSRs as well as the registers (e.g. fcsr, vtype, vl etc.)

• custom registers and CSRs should also be covered (e.g. HW loops) (unnamed?)

• compilers need to avoid using more registers than necessary (currently no reason)

• registers from compressible range should be allocated only when it will benefit code density (currently no reason)

• to avoid regressions, compilers need some kind of heuristic to detect when stacking certain (compressible) callee saved registers would yield better code density than using more temporaries from non compressible ranges

• need special assembly directive to annotate such exports from pure assembly code (workaround exists applying IPRA to assembly functions)

• precompiled libraries should also do an "IPRA exports"

• very important point is resolving IPRA annotations of callbacks, where the callback call will use the smallest common regmask of all functions that can be called through this point

  • callbacks initialized once at startup (typical in many HALs)

  • callbacks passed as function parameters

  • queues (of structs) with callbacks

• it can be used to annotate that passed function arguments (through registers or stack) were not modified and can be recycled by caller (e.g. in loops)

• it can also "export" list of deterministic constants (and addresses) that are left in registers after return

The reset state of all architectural registers is undefined unless explicitly specified in specific extension.

If the application start is preceeded by bootloader, or the application enters the bootloader, then the the switch code shall ensure that before redirecting execution to the target address:

• all peripherals are disabled, or initialized to reset state if enabled on reset (e.g. watchdogs)

• external GPIOs are configured to reset state

• the oscillators, PLLs, clock selects and divisors are configured to their reset state

• all nesting levels in teic_irq_msk are enabled

• teic_irq_vect is set to the target entry point, right before the jump happens

Register ranges define which registers are pushed onto the stack on irq entry.

Adding certain range require inclusion of all previous ranges.

The selection is implementation specific, fixed at silicon level. Shall not deviate from the predefined ranges.

stack frame pseudocode

when a given interrupt nesting level (reflected by pending_nestx in teic_irq_status) becomes pending which is not masked out by corresponing bit in teic_irq_msk register, the interrupt entry procedure is triggered.

During the interrupt entry the hardware will:

• stacks configured/implemented register ranges at given nesting level (can be affected by n4_stacking)

• decrement sp according to largest configured/implemented register ranges

• put content of interrupted pc into ra register with lowest bit set

• set in_nestx bit in teic_irq_status register

• fetches target address from vector table pointed by teic_irq_vect. The vector entry is selected by handler dispatch process.

• jumps to the fetched address

If irq request is spuriously deasserted during the interrupt entry (or e.g. tail chaining), the core must either; enter the offending handler or immediately return (or e.g. tail chain to yet another handler).

When jalr or cm.popret instruction is executed and the lowest bit in the source register is set (before calculating final target address), the interrupt exit procedure is triggered.
If no interrupt is currently active then irqretnest0_unrec nmi request is set.

During the interrupt exit the hardware will:

• unstack configured/implemented register ranges at given nesting level (can be affected by n4_stacking)

• increment sp according to largest configured/implemented register ranges

• clear in_nestx bit in teic_irq_status register

• jumps to the target address of jalr or cm.popret instruction

NMIs (non maskable interrupts) are a special type of interrupts that cannot be masked by teic_irq_msk register. Typically used for signalling critical conditions.

Entry/exit procedure is similar to regular IRQs with the following excepions:

• activity is signalled by in_nmi in teic_irq_status register

• preserves at least range 0 registers, stacking ranges are impelmentation defined.

• adjusts sp by stacked ranges

Before returning from NMI handler all requests in teic_nmi_cause CSR must be acknowledged (cleared).

Unimplemented optional NMIs can be recycled for custom NMIs other than the ones provided in table above.

Mnemonic

Encoding (RV32, RV64)

Description

Execution of the wfi instruction stalls the execution and allows the core to enter various low power states until the interrupt is taken or any nesting level becomes pending
It is allowed to terminte spontaneously or even be implemented as a nop.

In addition, the wfi instruction is allowed to optionally stack out certain registers ahead of the interrupts, to reduce their latency. In this case, sp is not changed until interrupt arrives.

Mnemonic

Encoding (RV32, RV64)

Description

Similar to wfi instruction, but doesn’t have to terminate after executing interrupts at 4th nesting priority only. Shall terminate if any other nesting level was entered before returning from n4 irq. (i.e. tail chained to n3, then pop preempted back into n4)

If only single nesting priority is implemented (TEIC_IRQ_NESTING_BITS == 0) then this instruction behaves like a standard wfi.

Disabling any nesting level shall take effect immediately before executing next instruction.

bits related to unimplemented nesting levels are hardwired to zero.

The *_async nmi requests have to be cleared within the source peripheral.

For each implemented irq vector, there is corresponding pending bit in pending register at teic_irq_pending[IRQn/32] position.

First 8 bit entries (corresponding to NMIs) are reserved.

Consists of 1023 entries, 1 byte each. First 8 entries (corresponding to NMIs) are reserved.

For each implemented irq vector, there is corresponding priority config register at teic_prio_cfg[IRQn] position.

priority encoding

Unimplemented bottom nesting bits are treated as if they were hardwired to 1. If only 1 bit is implemented then only nest2 and nest4 levels are possible.

additional per vector entry interrupt enable

private to the hart

Adds additional RTOS specific features

After thread mode (aka "user" or "unprivileged") is activated by thread_enter bit:

• Current sp becomes a defacto thread stack

• On irq entry from thread, current sp is swapped with the context of teic_swpspm register which happens after stacking (registers are pushed to thread stack)

• Thread mode protects only CSR registers, memory regions should be protected by additional PMP unit.

• Interrups are always executing in machine mode.

Makes each address entry in irq vector table take only 2 byte in size. (TEIC_IRQ_VECT_ENTRY_SIZE == 2)

The effective addres is constructed by concatenation of the 2 bytes of the vector entry content and top 16 bit of TEIC_ENTRY_VECT_BASE implementation constant.

The TEIC_ENTRY_VECT_BASE must be 64KiB aligned.

The entry encoding with the least significant bit set, is reserved.

Implies XTeicTinyIrqTable extension.

If the fetched vector entry has the lowest bit set, then the effective addres is constructed by concatenation of the 2 bytes of the vector entry content and top 16 bits of TEIC_EXEC_SRAM_BASE implementation constant.

The TEIC_EXEC_SRAM_BASE must be 64KiB aligned.

Used for limiting sp when hart is in thread mode or thread_enter == 0.

available only with XTeicRTOS

Used for limiting sp when hart is in interrupt (machine) mode (thread_enter == 1).

Flushes the pipeline and prefetch buffers before executing next instruction.
Encoded in bit 0 of fence.i immediate

Mnemonic

Encoding (RV32, RV64)

Ensures that the following instructions are executed after the architectural state change by a preceding CSR instructions (or equivalent) takes effect. Encoded in bit 1 of fence.i immediate

Mnemonic

Encoding (RV32, RV64)

RV32E:
case 0: {reg_list="ra"; xreg_list="x1";}
case 1: {reg_list="ra, s0"; xreg_list="x1, x8";}
case 2: {reg_list="ra, s0-s1"; xreg_list="x1, x8-x9";}
case 3-15: reserved
RV32I:
case 0: {reg_list="ra"; xreg_list="x1";}
case 1: {reg_list="ra, s0"; xreg_list="x1, x8";}
case 2: {reg_list="ra, s0-s1"; xreg_list="x1, x8-x9";}
case 3: {reg_list="ra, s0-s2"; xreg_list="x1, x8-x9, x18";}
case 4: {reg_list="ra, s0-s3"; xreg_list="x1, x8-x9, x18-x19";}
case 5: {reg_list="ra, s0-s4"; xreg_list="x1, x8-x9, x18-x20";}
case 6: {reg_list="ra, s0-s5"; xreg_list="x1, x8-x9, x18-x21";}
case 7: {reg_list="ra, s0-s6"; xreg_list="x1, x8-x9, x18-x22";}
case 8: {reg_list="ra, s0-s7"; xreg_list="x1, x8-x9, x18-x23";}
case 9: {reg_list="ra, s0-s8"; xreg_list="x1, x8-x9, x18-x24";}
case 10: {reg_list="ra, s0-s9"; xreg_list="x1, x8-x9, x18-x25";}
case 11: {reg_list="ra, s0-s10"; xreg_list="x1, x8-x9, x18-x26";}
case 12: {reg_list="ra, s0-s11"; xreg_list="x1, x8-x9, x18-x27";}
case 13-15: reserved

case 0..1:   stack_adj_base = 8
case 2..3:   stack_adj_base = 16
case 4..5:   stack_adj_base = 24
case 6..7:   stack_adj_base = 32
case 8..9:   stack_adj_base = 40
case 10..11: stack_adj_base = 48
case 12:     stack_adj_base = 56
case 13..15: reserved

Valid values:
case 0..1:   stack_adj = [ 8|16|24|32|40|48|56|64]
case 2..3:   stack_adj = [16|24|32|40|48|56|64|72]
case 4..5:   stack_adj = [24|32|40|48|56|64|72|80]
case 6..7:   stack_adj = [32|40|48|56|64|72|80|88]
case 8..9:   stack_adj = [40|48|56|64|72|80|88|96]
case 10..11: stack_adj = [48|56|64|72|80|88|96|104]
case 12:     stack_adj = [56|64|72|80|88|96|104|112]
case 13..15: reserved

Synopsis

Allocates stack frame and saves registers selected by rlist.

Mnemonic

Encoding

Synopsis

Deallocates stack frame and loads registers selected by rlist.

Mnemonic

Encoding

Synopsis

Deallocates stack frame, loads registers selected by rlist and returns.

Mnemonic

Encoding

Description

The ra register may not be populated.

Synopsis

Deallocates stack frame, loads registers selected by rlist, writes zero to a0 and returns.

Mnemonic

Encoding

Description

The ra register may not be populated. Unlike in Zcmp the load to a0 is non atomic.

those are quite annoying on rve