Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #117718 > unrolled thread
| Started by | Kragen Javier Sitaker <kragen@canonical.org> |
|---|---|
| First post | 2026-09-01 17:00 -0300 |
| Last post | 2026-09-03 02:56 +0000 |
| Articles | 6 on this page of 46 — 18 participants |
Back to article view | Back to comp.arch
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
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) antispam@fricas.org (Waldek Hebisch) - 2026-09-02 12:28 +0000
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) makendo <makendo@makendo.invalid> - 2026-10-27 14:17 +0800
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-27 16:14 +0000
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-27 17:06 +0000
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) Michael S <already5chosen@yahoo.com> - 2026-10-27 19:17 +0200
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-27 20:59 +0000
128/64 division (was: interrupt handling latency and weird register use) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-28 08:34 +0000
Re: 128/64 division (was: interrupt handling latency and weird register use) quadibloc@invalid.com (John Savard) - 2026-10-28 11:10 +0000
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-27 19:20 +0100
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) quadibloc@invalid.com (John Savard) - 2026-10-27 18:49 +0000
Re: floating point, interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) John Levine <johnl@taugh.com> - 2026-10-27 20:08 +0000
Re: floating point, interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) "Brian G. Lucas" <bagel99@gmail.com> - 2026-10-27 17:44 -0400
Re: floating point, interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) antispam@fricas.org (Waldek Hebisch) - 2026-10-28 12:10 +0000
Re: floating point, interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) John Levine <johnl@taugh.com> - 2026-10-28 16:46 +0000
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) antispam@fricas.org (Waldek Hebisch) - 2026-10-28 12:17 +0000
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-28 12:41 +0000
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) antispam@fricas.org (Waldek Hebisch) - 2026-10-28 19:06 +0000
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) BGB <cr88192@gmail.com> - 2026-10-28 16:39 -0500
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) quadibloc@invalid.com (John Savard) - 2026-10-27 18:46 +0000
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) antispam@fricas.org (Waldek Hebisch) - 2026-10-28 12:33 +0000
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) quadibloc@invalid.com (John Savard) - 2026-10-28 15:20 +0000
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-28 15:47 +0000
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) Josh Vanderhoof <x@y.z> - 2026-10-29 19:25 -0400
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-30 00:30 +0000
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) BGB <cr88192@gmail.com> - 2026-10-30 14:01 -0500
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) Josh Vanderhoof <x@y.z> - 2026-10-31 01:02 -0400
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-31 08:44 +0100
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) Thomas Koenig <tkoenig@netcologne.de> - 2026-10-31 15:15 +0000
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) Terje Mathisen <terje.mathisen@tmsw.no> - 2026-11-01 09:02 +0100
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) Paul Clayton <paaronclayton@gmail.com> - 2026-11-04 23:53 -0500
Unimplemented opcodes via jump tables (was: interrupt handling latency and weird register use) Thomas Koenig <tkoenig@netcologne.de> - 2026-10-31 09:45 +0000
Re: Unimplemented opcodes via jump tables (was: interrupt handling latency and weird register use) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-31 18:27 +0000
Re: Unimplemented opcodes via jump tables (was: interrupt handling latency and weird register use) Thomas Koenig <tkoenig@netcologne.de> - 2026-10-31 19:10 +0000
Re: Unimplemented opcodes via jump tables (was: interrupt handling latency and weird register use) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-11-01 16:11 +0000
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V jgd@cix.co.uk (John Dallman) - 2026-10-30 11:50 +0000
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) BGB <cr88192@gmail.com> - 2026-10-28 15:52 -0500
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-29 16:57 +0000
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) quadibloc@invalid.com (John Savard) - 2026-10-27 18:45 +0000
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) BGB <cr88192@gmail.com> - 2026-10-27 13:56 -0500
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
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-03 02:59 +0000
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) scott@slp53.sl.home (Scott Lurndal) - 2026-09-03 14:41 +0000
Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-03 02:56 +0000
Page 3 of 3 — ← Prev page 1 2 [3]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-10-27 13:56 -0500 |
| Message-ID | <11bqs85$1pt4n$1@dont-email.me> |
| In reply to | #118868 |
On 10/27/2026 11:14 AM, Anton Ertl wrote:
> makendo <makendo@makendo.invalid> writes:
>> The case where division is implemented but
>> multiplication is not does not have a name assigned -- it is pretty
>> well known that hardware designers, compiler writers and low-level
>> programmers hate division far more than multiplication, so I doubt
>> if divison-only hardware is even out in the wild for any ISA...
>
> I don't think that "hate" is the right concept. Division is costly:
> Costly to implement and it tends to run slowly (although ARM tries
> hard to disprove that part, even on low-end cores like the
> Cortex-A53). And it's not that frequent, which means that if you
> throw lots of hardware at making it fast, the payoff will be small.
> And because it is slow, various potential use cases avoid it and
> prefer to use shifts or multiplication by the inverse, making it even
> less frequent.
>
Yes.
General purpose division is infrequent enough that even slow hardware
support is debatable, vs implementing it in software as a runtime function.
And, since generally everyone knows division is often slow, there is a
tendency for programmers to avoid it whenever possible, which ironically
lessens the incentive for faster division in the general case.
Then, there are niche cases where one wants it to be fast.
But, then often in these cases a usable strategy is to use a lookup
table of reciprocals, which is often also a usable strategy to speed up
runtime-library division.
In the naive case, one can have a table of reciprocals and only divide
via the table when in range of the lookup table. However, this scales
poorly. With care, there are tricks to push it further with a smaller
lookup table, but more care is needed to avoid cases that would result
in inexact results (in cases where it is necessary to have an exact result).
One trick is, say:
You have a table of root reciprocals;
You have a table of derived reciprocals, holding an index to the root
reciprocal, and a right shift value (say, both packed into a 16-bit number);
This can be used as the main division table.
If outside of the naive range of the table:
Is the current divisor a power-of-2 multiple of an index in the table?
reuse that index, but add the scale to the final right-shift.
Maybe try some factorization tricks.
Else, fall back to a generic-but-slow strategy.
Such as a shift-and-subtract loop.
For something like a 3D renderer, typically exact results are not needed
so it is possible to behave as-if the power-of-2 case is always true.
Another option is doing a trick of trying the power-of-2 case, then
back-multiplying the result.
q_apx = div_apx(dividend, divisor);
dvi_apx = q_apx * divisor;
rem_apx = dividend - dvi_apx;
if(rem_apx < divisor)
return(q_apx); //exact
if(rem_apx < (divisor*2))
return(q_apx+1); //off by 1
//rare path, fall back to slow strategy.
Though, this approach mostly only makes sense if one assumes that the
multiplier is reasonably fast compared to the divider slow-path.
If using a shift-add multiplier, this approach does not make sense.
For 3D rendering, there is often a need for fast approximate
floating-point division, but then a reasonable strategy is:
Generate a reciprocal:
Do a magic integer subtract;
Patch it up with a few N-R stages.
Do division via multiplication by reciprocal.
Likewise for square-root, and reciprocal-square-root.
Though, another option is to do approximate floating-point reciprocal by
extracting the mantissa and then using an approximate integer reciprocal
of the HOBs as the starting point (with the shift-factors added to the
computed new exponent).
This is more complicated than the "subtract and N-R" trick, but can work
out being potentially faster if the FPU isn't particularly fast (or if
doing FPU emulation).
> Even relatively recent architectures like Alpha (1992) and IA-64
> (2001) do not include integer division instructions.
>
> So I found the inclusion of division in the RISC-V M extension
> surprising. They then separated them again by defining Zmmul.
>
If one assumes that multiplication is done with a Shift-and-Add unit,
then division comes cheaply as a very modest logic tweak.
Doesn't work if one uses a different strategy to implement multiply though.
In my case, I used shift-and-add for 64-bit multiply, and for 32 and 64
bit division.
64-bit multiply:
A little slower than the "decompose and use 32-bit multiply in software"
strategy, but less inconvenient.
32-bit divide:
A little faster than the software-side lookup-table trickery.
64-bit divide:
Notably faster than the shift-subtract loop.
However...
In most cases division is infrequent enough that it doesn't make a big
difference either way.
A cheaper strategy would be to only provide for 32-bit narrow and
widening multiply in a 64-bit machine.
Then argue that everything else be faked using 32-bit widening multiply.
But... annoyingly... RV64 doesn't provide a 32-bit widening multiply
instruction.
Though, did recently get around to adding a special case to BGBCC that
things like:
int x, y, z;
...
z=(((long long)x)*((long long)y))>>24;
Will now use a widening multiply (when available) rather than a full
64-bit multiply. Previously, was mostly often using an intrinsic for
this sort of thing, but this kinda sucked.
For RISC-V, can fake the full version of M with trap-and-emulate, but
this is the slowest option.
...
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-02 01:43 +0000 |
| Message-ID | <1788313406-5857@newsgrouper.org> |
| In reply to | #117718 |
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
[toc] | [prev] | [next] | [standalone]
| From | Andy Valencia <vandys@vsta.org> |
|---|---|
| Date | 2026-09-02 08:11 -0700 |
| Message-ID | <178836187516.12856.389882077315734305@media.vsta.org> |
| In reply to | #117718 |
Kragen Javier Sitaker <kragen@canonical.org> writes: > ... 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). This brings back memories of MIPS' K0 and K1 registers. From non-interrupt code perspective their value could change asynchronously, as they were there to be scratched upon by the lowest level of interrupt and trap entry. It always struck me as a covert channel, though I never came up with a way to use it. Andy Valencia Home page: https://www.vsta.org/andy/ To contact me: https://www.vsta.org/contact/andy.html No AI was used in the composition of this message
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-03 02:59 +0000 |
| Message-ID | <117anqg$3au5h$5@dont-email.me> |
| In reply to | #117736 |
On Wed, 02 Sep 2026 08:11:15 -0700, Andy Valencia wrote: > This brings back memories of MIPS' K0 and K1 registers. From > non-interrupt code perspective their value could change > asynchronously, as they were there to be scratched upon by the > lowest level of interrupt and trap entry. It always struck me as a > covert channel, though I never came up with a way to use it. People were so much more naïve back then ... In the early versions of VAX/VMS, the whole of the kernel address space was readable from a nonprivileged user program. And then there was this feature in a “message section” (a shareable library containing diagnostic messages indexed by status code) where its header contained executable code that would be entered *from the kernel*, in privileged mode ...
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-03 14:41 +0000 |
| Message-ID | <EGfmS.228900$aK2e.18697@fx17.iad> |
| In reply to | #117750 |
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes: >On Wed, 02 Sep 2026 08:11:15 -0700, Andy Valencia wrote: > >> This brings back memories of MIPS' K0 and K1 registers. From >> non-interrupt code perspective their value could change >> asynchronously, as they were there to be scratched upon by the >> lowest level of interrupt and trap entry. It always struck me as a >> covert channel, though I never came up with a way to use it. > >People were so much more naïve back then ... > >In the early versions of VAX/VMS, the whole of the kernel address >space was readable from a nonprivileged user program. You'll need to support this statement. It wasn't true with VMS 2.0.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-03 02:56 +0000 |
| Message-ID | <117ank0$3au5h$4@dont-email.me> |
| In reply to | #117718 |
On Tue, 01 Sep 2026 17:00:23 -0300, Kragen Javier Sitaker wrote: > 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. As I recall, early versions of Sun SPARC omitted integer hardware multiply and divide, on the grounds that such instructions occurred infrequently in the traces the designers collected while running various example programs. They changed their minds later. Seymour Cray omitted floating-point divide in favour of multiplication by the reciprocal. He did include a reciprocal-approximation instruction that would give a full-accuracy result after two iterations. However, I think there are rounding issues with trying to make floating-point multiplication-by-reciprocal stand in for division in general. Which is why nobody follows Cray’s example these days.
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | comp.arch
csiph-web