riscv-rt: Use callee-saved registers for preserving arguments
#325
Conversation
|
Another simpler option could be to preserve only register |
|
Acknowledged, on camp rn. Will read up on Mon. |
There was a problem hiding this comment.
Yeah it works for RVE. Also checked the compiled assembly. Could we use a6 instead of a5 (see below code comment)?
I understand mp_hook typically contains just the code to identify the current core. So constraints don't seem too bad as they're well documented.
| //! - `s0`: Contains the original value of `a0` (hart ID). | ||
| //! - `s1`: Contains the original value of `a1` (usually a pointer to the device tree blob). | ||
| //! - **IN RISCVI TARGETS `s2`**: Contains the original value of `a2` (usually reserved for future use). | ||
| //! - **IN RISCVE TARGETS `a5`**: There are no more callee-saved registers, so `a2` is preserved in `a5`. |
There was a problem hiding this comment.
The non-ratified EABI calling conventions reuse also x6/t1, x7/t2, and x14/a4 as callee saved registers (and call them s3--s5) but I understand we must assume RVE + standard ABI here.
There was a problem hiding this comment.
One take away from EABI would be that it redeclares x16/a6 as s5 (callee save), and we could use that instead of x15/a5 since it's also currently unused. The other substitutions are x6/t1 -> s3 and x7/t2 -> s4 but t1 and t2 are used by the RAM initialization algorithm at that point.
There was a problem hiding this comment.
Do RV32E targets have x16? I thought it was up to x15
There was a problem hiding this comment.
Oops, my mistake on cross-referencing ABI tables. RV32E is up to x15 only (while---of course---EABI also specifies what to do with registers up to x31 on RVI targets).
As pointed out by @janderholm , the current implementation of
riscv-rtviolates RAM utilization during the.initsection. This PR replaces the stack with registers for preserving input parameters.@hegza can you bless this PR for RVE targets?
Closes #315