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

Groups > comp.lang.forth > #135519

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

Cross-posted to 3 groups.

Show all headers | View raw

Kragen Javier Sitaker <kragen@canonical.org> posted:

> 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.-------snip-------
> 
> 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).

My 66000 has HW perform the register movements (save and restore) as
if the RF was a write back cache. This enables HW to start saving
registers before the first instruction in ISR has been fetched
(which, necessarily, is after the address of the ISR has been loaded).
For interrupts all this pre-loading can transpire in parallel with
the storing of the registers to be pushed out.

For SVCs, R0-R8 are arguments to the SVC, while R9-R15 are not saved
{just like R9-R16 is not preserved in a normal procedure call}. An
SVR <return> R1-R2 contain returning arguments while R3-R15 are cleared.
So, supervisor can see noise in R3-R15 but caller cannot see noise after
return. R16-R31 are preserved across the SVC-SVR just like between CALL
and RET.

It also has the benefit that once control arrives in ISR, you have
<at least> 16 registers with useful state {SP to ISR stack, FP,
and various pointers to structures the ISR might need} without
having to load them with instructions.

While "IN" an ISR, the ISR might need to schedule a DPC or softIRQ.
My 66000 allows this to become manifest with a single instruction
(a store to the Interrupt aperture with a message describing where
the DPC/softIRQ arguments are to be found.) And a few instructions
setting up the deferred arguments.
 
> (Note that most existing RISC-V cores like the QingKe core used in the
> CH32V003 have their own, incompatible, interrupt-handling mechanisms.

Almost always a bad decision.

> 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.

In My 66000, There is a 6 instruction dispatcher (could be per Thread
or common across all threads of a given privilege) that is written in
ASM, but the ISR is written in any suitable HLL.

I went with a dispatcher model so that SW gets to decide where the
tables are, how they are configured, sized, and accessed--without
arbitrary boundaries (page alignment page size).
 
> 8 registers is probably enough for the FIQ handler, so with RV32I you
> have 24 left over for the rest of the code.

A 24 register machine will perform ~6% worse than a 32-real register
machine. Can you make up in responsiveness of interrupts for this
loss ?? Most RISCs are not 32-real register machines. R0 containing
the value 0, certain registers dedicated to dynamic linking (MIPS),
R1 containing the return address, and any special registers that have
to do with multiply and divide (sometimes double wide shifts).
 
----------
> 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>

             // you want to pass control to thread in R19 ADA-like
             CR    R19,Application,R19
             // R19 now points to yourself, but control is now there
> 
> 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.

And with that attitude ARM deserves the competition.
 
> 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.

This leaves out the CRAY solution of a reciprocation instruction making
FDIV to be RCP->FMUL. {{Handwaving about how you cannot achieve IEEE 754
precision and accuracy doing it that way...}}

FDIV is so bad that many GPU languages carry around w=1/SQRT(x^2+y^2+z^2)
so that for all intents and purposes, FDIV is a FMUL.

But all languages support FDIV, thereby, FDIV should be an available
instruction--differing implementations can provide for this using any
means chosen by implementation; including {trap to SW, Slow FU, medium
FU, fast FU, SIMD FU, ...} {{{If you choose 'trap to SW'--you better 
haven a clean trapping mechanism}}}
 
> 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