Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #135510

interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant)

Cross-posted to 3 groups.

Show key headers only | View raw

antispam@fricas.org (Waldek Hebisch) writes:
> Paul Rubin <no.email@nospam.invalid> wrote:
>> https://dmitry.gr/?r=06.%20Thoughts&proj=12.%20RV
>
> Some comments.
>
> 1) Interrupt latency claim is half-truth.  First, normal RISC-V has
> 32 registers while ARM has 16.  If you can do with 16 registers
> divide register set into 2 parts, use one part for normal code
> and the other for interrupt handler.  That way you will get few
> cycle overhead, impossible feat for Cortex M.  So it is really
> a tradeoff; do you want to have modest overhead for pretty
> typical use case, or do you for very low overhead in cases that
> need it and higher overhead for typical cases?

This is a really good point, and one I should have thought of.  You can
reserve some registers as “FIQ” registers and only use them inside
interrupt handlers, depsite the absence of an architectural FIQ
mechanism (which was present on the ARM2 but excised in the Cortex-M).

(Note that most existing RISC-V cores like the QingKe core used in the
CH32V003 have their own, incompatible, interrupt-handling mechanisms.
Generally these are FIQ-like, enabling lower latency than the standard
RISC-V mechanism but with a limited depth of nested interrupts.)

You can write the “FIQ” handler itself in assembly, since if it needs to
be more than about 16 instructions long you might as well switch to the
standard ABI, but you also need to compile the rest of your application
with the “FIQ registers” reserved, including any system libraries you
might be using, such as an integer division subroutine.  This is true
whether you’re using Forth, or C, or any other language.

8 registers is probably enough for the FIQ handler, so with RV32I you
have 24 left over for the rest of the code.

Reserving some registers is a very small modification to most compilers
(those that do some kind of register allocation), and Forth compilers
are fairly small, but making any modification to GCC or LLVM is a bit
daunting, even writing a new “machine definition” file.  I had
previously looked for an existing way to do this with GCC and given up,
but it turns out that it’s fairly simple; GCC has an `-ffixed-reg`
option, where `reg` is the name of the register to reserve.  See
<https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html>.

So, in theory, you ought to be able to reserve x24 through x31 for “FIQ”
handlers by compiling all your C source code with something like

    gcc -ffixed-x24 -ffixed-x25 -ffixed-x26 -ffixed-x27 -ffixed-x28 \
        -ffixed-x29 -ffixed-x30 -ffixed-x31

I have verified that GCC does indeed accept these command-line options,
and that it respects -ffixed-a5, but I haven’t written code with
sufficient register pressure to provoke GCC to try to use x24 (s8) even
without this option.  So, it’s documented to work, but it’s kind of a
niche feature, and I haven’t tried it in practice.

You might be tempted to try to use GCC’s global register variables
<https://gcc.gnu.org/onlinedocs/gcc/Global-Register-Variables.html> for
this:

    register int *foo asm ("r12");

However, the documentation specifically says that you should use
`-ffixed-reg` instead, because global register variables will not work
for the interrupt-handling case:

>>> Similarly, it is not safe to access the global register variables
>>> from signal handlers or from more than one thread of control. Unless
>>> you recompile them specially for the task at hand, the system
>>> library routines may temporarily use the register for other things.
>>> Furthermore, since the register is not reserved exclusively for the
>>> variable, accessing it from handlers of asynchronous signals may
>>> observe unrelated temporary values residing in the register.

For this particular case, another possibility may be to compile for
RV32E, which only has 16 architectural general-purpose registers but is
otherwise compatible with RV32I.

I had looked for how to achieve this three years ago for a project
called Monokokko, which is a five-machine-instruction-long
cooperative-multitasking OS for ARM:

            .thumb_func
    yield:  push {r4-r9, r11, lr}   @ save all callee-saved regs except r10
            str sp, [r10], #4       @ save stack pointer in current task
            ldr r10, [r10]          @ load pointer to next task
            ldr sp, [r10]           @ switch to next task's stack
            pop {r4-r9, r11, pc}    @ return into yielded context there

<http://canonical.org/~kragen/sw/dev3/monokokko.S>

Now I know how to solve the problem!  So I can write Monokokko tasks in
C now!

> 5) Optionality.  I do not like it and it is probably biggest
> problem of RISC-V.  OTOH to have any chance of success RISC-V
> need a buy-in from several independent parties.  I suspect that
> the only practical way to get consensus from varied parties is
> by making most of specification optional.

For CPU vendors and computer architecture researchers, I suspect this is
the biggest selling point of RISC-V: they can add experimental vector
extensions without waiting for them to be ratified, they can add
FIQ-style low-latency interrupt handling, they can implement their own
memory protection mechanisms, they can add zero-overhead loops, etc.  As
I understand it, Berkeley researchers’ nightmarish negotiations with ARM
to get a license to perform such experiments on ARM cores was the hell
from which RISC-V came in the first place.

It also means that bad decisions by RISC-V International have much less
impact on licensees.  The most obvious example, to my mind, is something
Grinberg’s critique doesn’t even mention — it’s having the divide
instruction in the M extension.  Hardware multiplication is crucial for
all kinds of applications, including software-defined radio and other
DSP, image processing, 3-D rendering, and neural networks.  By contrast,
hardware division is a minor advantage but rarely appears in inner
loops, and has been omitted from historical architectures including the
Cray-1, Cray-2, and ARM.

Kragen

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

OT: Epic RISC-V rant Paul Rubin <no.email@nospam.invalid> - 2026-08-14 22:22 -0700
  Re: OT: Epic RISC-V rant jkn <jkn+nin@nicorp.co.uk> - 2026-08-15 10:10 +0100
  Re: OT: Epic RISC-V rant albert@spenarnc.xs4all.nl - 2026-08-22 18:23 +0200
    Re: OT: Epic RISC-V rant anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-22 16:45 +0000
  Re: OT: Epic RISC-V rant antispam@fricas.org (Waldek Hebisch) - 2026-08-22 22:36 +0000
    Re: OT: Epic RISC-V rant albert@spenarnc.xs4all.nl - 2026-08-23 13:44 +0200
      Re: OT: Epic RISC-V rant antispam@fricas.org (Waldek Hebisch) - 2026-08-29 19:49 +0000
    Re: OT: Epic RISC-V rant anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-08-24 07:55 +0000
      adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-01 17:15 -0300
        Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) John Ames <commodorejohn@gmail.com> - 2026-09-01 14:31 -0700
          Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) BGB <cr88192@gmail.com> - 2026-09-01 17:18 -0500
          Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-02 02:04 +0000
            Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) John Ames <commodorejohn@gmail.com> - 2026-09-02 08:23 -0700
              Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-11 13:48 -0300
                Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-11 18:03 +0000
          Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-09 11:16 +0000
        Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-02 01:53 +0000
        Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-09 10:50 +0000
          Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) Paul Rubin <no.email@nospam.invalid> - 2026-09-09 22:10 -0700
          Re: adding overflow and carry to every GPR (was Re: OT: Epic RISC-V rant) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-11 14:28 -0300
    Re: OT: Epic RISC-V rant antispam@fricas.org (Waldek Hebisch) - 2026-08-29 20:12 +0000
    interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-01 17:00 -0300
      Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-01 20:51 +0000
      Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-02 01:43 +0000
    interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) Andy Valencia <vandys@vsta.org> - 2026-09-02 08:11 -0700

csiph-web