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

Groups > comp.arch > #117718 > unrolled thread

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

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.

Contents

  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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#118885

On Tue, 27 Oct 2026 17:06:29 GMT, MitchAlsup
<user5857@newsgrouper.org.invalid> wrote:

>But "lack of division" is also costly !! especially if some future
>implementation will have division {which it will} and then you have
>no direct means to make the dusty decks fast.
>
>Note to µArchitects, put the instruction in even if you are going to
>TRAP to SW emulation. Later on when DIV is implemented it just runs
>faster and you had to do nothing (but put it in).

An excellent point!

John Savard

[toc] | [prev] | [next] | [standalone]

#118914

MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> 
>> 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:
> 
> But "lack of division" is also costly !! especially if some future
> implementation will have division {which it will} and then you have
> no direct means to make the dusty decks fast.

You assume binaries or assembler code.  In microcontroller world
programs are frequently compiled for one specific CPU model.
And in case of microcontrollers savings due to ommision of
divide circuit can be significant.  I know you do not like
Risc-V, but one small model (CH32V003) even skips multiplication.
IIUC even smallest Arm-s have multiplication (which theoretically
can be slow, but on all small models that I know it 32 bit
multiplication executes in 1 cycle).

> Note to µArchitects, put the instruction in even if you are going to
> TRAP to SW emulation. Later on when DIV is implemented it just runs
> faster and you had to do nothing (but put it in).

You need to make it fast enough so that compilers are not tempted
to call software emulation.  Also beware of interrput latency,
if division is slow microcontroller probably should allow
interrupts in the middle of division.

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#118916

On Wed, 28 Oct 2026 12:33:44 -0000 (UTC), antispam@fricas.org (Waldek
Hebisch) wrote:
>MitchAlsup <user5857@newsgrouper.org.invalid> wrote:

>> But "lack of division" is also costly !! especially if some future
>> implementation will have division {which it will} and then you have
>> no direct means to make the dusty decks fast.

>You assume binaries or assembler code.  In microcontroller world
>programs are frequently compiled for one specific CPU model.

This may be, but his advice is still eminently sound for the Windows
desktop PC world. Which is the one in which billions of helpless
consumers face the industry almost completely on their own.
Corporations implementing devices containing microcontrollers, on the
other hand, are much more likely to be able to take care of
themselves.

John Savard

[toc] | [prev] | [next] | [standalone]

#118919

antispam@fricas.org (Waldek Hebisch) posted:

> MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
> > anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> > 
> >> 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:
> > 
> > But "lack of division" is also costly !! especially if some future
> > implementation will have division {which it will} and then you have
> > no direct means to make the dusty decks fast.
> 
> You assume binaries or assembler code.  In microcontroller world
> programs are frequently compiled for one specific CPU model.
> And in case of microcontrollers savings due to ommision of
> divide circuit can be significant.

This gets at my point: my point is the opposite of RISC-V--that is
one defines all the OpCodes and if an implementation does not deal
with OpCode X, that implementation takes an OPERATION fault. RISC-V
leaves that OpCode slot undefined (potentially available for other
uses).

>                                     I know you do not like
> Risc-V, but one small model (CH32V003) even skips multiplication.
> IIUC even smallest Arm-s have multiplication (which theoretically
> can be slow, but on all small models that I know it 32 bit
> multiplication executes in 1 cycle).
> 
> > Note to µArchitects, put the instruction in even if you are going to
> > TRAP to SW emulation. Later on when DIV is implemented it just runs
> > faster and you had to do nothing (but put it in).
> 
> You need to make it fast enough so that compilers are not tempted
> to call software emulation.  Also beware of interrput latency,

I am shooting at 10 cycles there and 10 cycles back.

> if division is slow microcontroller probably should allow
> interrupts in the middle of division.
> 

[toc] | [prev] | [next] | [standalone]

#118950

MitchAlsup <user5857@newsgrouper.org.invalid> writes:

>> > Note to µArchitects, put the instruction in even if you are 
>> > going to TRAP to SW emulation. Later on when DIV is 
>> > implemented it just runs faster and you had to do nothing 
>> > (but put it in). 
>>  You need to make it fast enough so that compilers are not 
>> tempted to call software emulation.  Also beware of interrput 
>> latency, 
> 
> I am shooting at 10 cycles there and 10 cycles back. 

Would it be possible to have a hardware version of polyfill?  The 
basic idea would be that instead of emulation via trapping, the 
software calls a standardized divide routine.  On hardware with a 
divide instruction it checks the routine and if it sees it's the 
standard divide routine it just uses its divide instruction 
instead.  If it doesn't have hardware division it just runs the 
divide routine.

I think I'd be more likely to use new instructions if they worked 
this way, providing the standard polyfill routine in the 
documentation for the new instruction.  The way things work now I 
only use them after they've been around for a decade.

[toc] | [prev] | [next] | [standalone]

#118953

Josh Vanderhoof <x@y.z> posted:

> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> 
> >> > Note to µArchitects, put the instruction in even if you are 
> >> > going to TRAP to SW emulation. Later on when DIV is 
> >> > implemented it just runs faster and you had to do nothing 
> >> > (but put it in). 
> >>  You need to make it fast enough so that compilers are not 
> >> tempted to call software emulation.  Also beware of interrput 
> >> latency, 
> > 
> > I am shooting at 10 cycles there and 10 cycles back. 
> 
> Would it be possible to have a hardware version of polyfill?  The 
> basic idea would be that instead of emulation via trapping, the 
> software calls a standardized divide routine.  On hardware with a 
> divide instruction it checks the routine and if it sees it's the 
> standard divide routine it just uses its divide instruction 
> instead.  If it doesn't have hardware division it just runs the 
> divide routine.

I do not see any justification of NOT having DIV as an instruction
and in HW (by means of some king of sequencer). In the same way
we can put 16 GBOoO cores on a single die with 256-bit wide SIMD, 
the amount of area saved not doing DIV is invisible when seen at 
the die-level.

In the smallest conceivable implementations, DIV is a multiplexer in
the feedback-loop around the integer ADDer and a 5-state sequencer.

For me, I can't see building a core that does not have a 64×64
multiplier, either. 
 
> I think I'd be more likely to use new instructions if they worked 
> this way, providing the standard polyfill routine in the 
> documentation for the new instruction.  The way things work now I 
> only use them after they've been around for a decade.

I have no idea what you mean by polyfill.

[toc] | [prev] | [next] | [standalone]

#118969

On 10/29/2026 7:30 PM, MitchAlsup wrote:
> Josh Vanderhoof <x@y.z> posted:
> 
>> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>>
>>>>> Note to µArchitects, put the instruction in even if you are
>>>>> going to TRAP to SW emulation. Later on when DIV is
>>>>> implemented it just runs faster and you had to do nothing
>>>>> (but put it in).
>>>>   You need to make it fast enough so that compilers are not
>>>> tempted to call software emulation.  Also beware of interrput
>>>> latency,
>>>
>>> I am shooting at 10 cycles there and 10 cycles back.
>>
>> Would it be possible to have a hardware version of polyfill?  The
>> basic idea would be that instead of emulation via trapping, the
>> software calls a standardized divide routine.  On hardware with a
>> divide instruction it checks the routine and if it sees it's the
>> standard divide routine it just uses its divide instruction
>> instead.  If it doesn't have hardware division it just runs the
>> divide routine.
> 
> I do not see any justification of NOT having DIV as an instruction
> and in HW (by means of some king of sequencer). In the same way
> we can put 16 GBOoO cores on a single die with 256-bit wide SIMD,
> the amount of area saved not doing DIV is invisible when seen at
> the die-level.
> 
> In the smallest conceivable implementations, DIV is a multiplexer in
> the feedback-loop around the integer ADDer and a 5-state sequencer.
> 
> For me, I can't see building a core that does not have a 64×64
> multiplier, either.
>   


I did such a thing in an FPGA (for 64-bit MUL/DIV):
   Shift 1-bit left;
   Do an ADD/SUB;
   Maybe use carry status as a comparison;
   ~ 36 or 68 clock cycles for 32 or 64 bit DIV;
   ...
And it still managed to burn through around 1000 LUTs.

Granted, not particularly large if compared with some things (the L1 D$ 
is far larger, etc), but still not exactly negligible either.
   Well:
     L1 D$, I$, regfile/forwarding, and instruction decoder
   Being the "big eaters".
     Followed by, say:
       Main FPU
       SIMD Unit (Binary16/Binary32)
       Int64 MUL/DIV
       Integer ALUs (3 of them);
       ...
     Shift was more than plain ALU,
       but limited to the first 2 lanes.
       Third lane only does plain ALU ops.


There was an investigated option to allow speculatively running the 
32-bit DIV through the 32-bit multiplier by using a small lookup table 
for reciprocals, and using this result (skipping the main divider) if it 
hit (32-bit value being divided by a divisor in the range of 1 to 63 or 
similar).

This was actually effective, but the relative impact of making 
common-case divides faster was small enough to be negligible for overall 
performance; for a non-zero cost.


Still probably worth having a DIV instruction in any "application class" 
core though.
Where, if a core is intended for general purpose application software, 
probably should have a divide instruction. If intended for embedded 
systems or microcontrollers (where typically cost optimization is the 
dominant concern and code is typically compiled for a specific CPU 
model), maybe a good idea to leave it out.

I originally was more opposed to having instructions for things which 
couldn't be guaranteed to be affordably viable or cost effective in 
hardware; but have since softened more to the idea of using 
trap-and-emulate in these cases.

There is an option of trap and emulate, or hot-patch, but does require 
that the kernel has some space within JAL/BSR distance to patch into.


Can note that a lot of the mainline/dominant cores (in the ARM space) 
are in-order dual-issue.


This is arguably cheaper than the 3-wide approach I had used:
   Lane 1: ALU, Shift, BRA, CMP, MEM, FPU, ...
   Lane 2: ALU, Shift, CMP (3R), FPU-ALT, ...
   Lane 3: ALU

The main merit of 3 wide here is that:
   A 3-input instruction can co-execute with another instruction;
   Can dual issue 3-input ops;
   Can support 128-bit 3-input ops;
   ...

Whereas a strictly dual-lane core couldn't do any 128-bit 3-input ops, 
various edge-case instructions, ... And couldn't dual-issue instructions 
whenever doing something like an indexed store.

That said, 4R2W is still cheaper than 6R3W.
And, 6R2W dual-issue doesn't save enough to be worthwhile, vs having a 
3rd ALU; even if the 3rd lane ALU is relatively low traffic (but does 
occasionally pay off in dense integer-math heavy code).

In this case, the ALU does:
   ADD/SUB/AND/OR/XOR (in both 3R and 3RI variants).
   Also MOV(2R/2RI) / MV / LI, ...


But, despite the ARM cores being dual-issue, they tend to have NEON, 
which looks like a more expensive approach to SIMD than what I had been 
using (needs its own register file, etc).

Whereas my core had been using the GPR regfile for everything, and just 
pretending to have a GPR and FPR regfile for sake of the RISC-V mode.

Not seen a particularly strong case for having a split between GPRs and 
FPRs other than "FPU ops are higher latency than ALU ops, so need their 
own regfile and pipeline for 'reasons'...".


Though, in my case, that I went for having typically higher latency for 
ALU ops:
   The MV / LI cases are 1-cycle;
   Other ALU / Shift / etc: 2 cycle.
   Load: 3 or 4 cycles.
     3 cycles: Basic memory load;
     4 cycles: Load with a converter step
       Eg: Binary32->Binary64 or texture loads.

A lot of the other RV cores it seems had aimed for:
   1 cycle: All basic instructions;
   2 cycle: Memory Load;
   ...

Did experiment with some fast-path cases for ALU and Load, but had noted 
that while they helped the basic/pure RV64G base, they didn't help 
notably with other cases, and most of the difference for RV64G was tied 
fairly specifically to the need for multi-op sequences for index 
calculations. If you have LEA/SHnADD, and indexed-load, the relative 
performance gain of 1-cycle latency on Shift and ADD instructions and 
similar mostly goes away; except maybe when spinning in tight loops 
(which is seemingly a poor case on my CPU design).

Well, say "while(*ct++==*cs++);" is something preferably avoided.


Seemingly ran into a bit of an issue in this space:
Can't really move to higher clock speeds without sacrifices that hurt 
more than they gain;
Can't really do that much more per-cycle without needing to drop lower 
in terms of clock speed (which also hurts);
...

Like, it seems like I had found a local optimum in the current 50 MHz 
target range (at least for the current Artix-7 chips).


Like, can make a core that runs at 75 MHz on an FPGA, but the only thing 
it can really gain is "slightly faster at Doom, slower on everything else".

Or, maybe go for RV32IM at 100 MHz, which runs Doom and similar well, 
but is pretty limited for other tasks.


More recently, stuff has gotten a lot slower as this search space seems 
to be pretty much explored; and practical usefulness is more debatable 
(vs, say, the cheaper option of maybe using an ARM SBC maybe paired with 
a separate 8/16 microcontroller chip for any RT stuff).


And, all I really achieved with my own CPU design was seemingly just 
using it for running ports of games and similar, rather than for 
anything "actually useful".

Well, and even then, "Make framerates in Quake not suck" still being a 
difficult problem.


>> I think I'd be more likely to use new instructions if they worked
>> this way, providing the standard polyfill routine in the
>> documentation for the new instruction.  The way things work now I
>> only use them after they've been around for a decade.
> 
> I have no idea what you mean by polyfill.


My understanding of it is, say:
You call a function for something as the default path (possibly with an 
indirect call via a function pointer);
If there is a faster version, it patches over to that after detecting 
that it exists;
If an instruction exists, one could maybe go further and patch out the 
original function call itself.

Say:
   JAL X1, __divsi   //Default case
Then, say:
   __divsi:
     LD  X5, __divsi_fptr  //decomposes into AUIPC+LD or similar
     JALR X0, X5, 0

   .section .data
   __divsi_fptr .quad __divsi_initial

Where __divsi_initial checks if a faster divide exists and if so 
replaces itself with that, or replaces the call with a call to the 
generic version.

Say:
   __divsi_fast:
     DIVW X10, X10, X11   //if we have the DIVW instruction...
     RTS

   __divsi_slow:
     ... //ye olde shift-subtract loop


Or, basically the inverse of the "have instruction, but trap and 
emulate" case.

[toc] | [prev] | [next] | [standalone]

#118975

MitchAlsup <user5857@newsgrouper.org.invalid> writes:

> Josh Vanderhoof <x@y.z> posted: 
> 
>> MitchAlsup <user5857@newsgrouper.org.invalid> writes:  
>> >> > Note to µArchitects, put the instruction in even if you 
>> >> > are  going to TRAP to SW emulation. Later on when DIV is 
>> >> > implemented it just runs faster and you had to do nothing 
>> >> > (but put it in).  
>> >>  You need to make it fast enough so that compilers are not  
>> >> tempted to call software emulation.  Also beware of 
>> >> interrput  latency,  
>> >  I am shooting at 10 cycles there and 10 cycles back.  
>>  Would it be possible to have a hardware version of polyfill? 
>> The  basic idea would be that instead of emulation via 
>> trapping, the  software calls a standardized divide routine. 
>> On hardware with a  divide instruction it checks the routine 
>> and if it sees it's the  standard divide routine it just uses 
>> its divide instruction  instead.  If it doesn't have hardware 
>> division it just runs the  divide routine. 
> 
> I do not see any justification of NOT having DIV as an 
> instruction and in HW (by means of some king of sequencer). In 
> the same way we can put 16 GBOoO cores on a single die with 
> 256-bit wide SIMD,  the amount of area saved not doing DIV is 
> invisible when seen at  the die-level. 
> 
> In the smallest conceivable implementations, DIV is a 
> multiplexer in the feedback-loop around the integer ADDer and a 
> 5-state sequencer. 
> 
> For me, I can't see building a core that does not have a 64×64 
> multiplier, either.  

I get that, but I'm not really talking about the necessity of 
divide instructions.  I'm talking about dealing with processors 
with different sets of features.

Say instead it's for something called featurex and some processors 
want it in hardware and some don't.  It'd be much easier for 
someone writing the software if a standard sequence of 
instructions for doing featurex was defined and new processors 
that do featurex in hardware automatically checked call targets 
and recognize when the instruction sequence matches featurex. 
Then when the routine is called later uses the dedicated 
instruction instead doing the call.

It's be really nice because the code would be identical for 
everything and also run about as fast as possible on everything. 
I have no idea how hard it would be to keep the track of which 
subroutines are actually new instructions though.

I'd much rather have something like this than have to write 
multiple versions of things depending on whether or not some CPUID 
bit is set.
 
>> I think I'd be more likely to use new instructions if they 
>> worked  this way, providing the standard polyfill routine in 
>> the  documentation for the new instruction.  The way things 
>> work now I  only use them after they've been around for a 
>> decade. 
> 
> I have no idea what you mean by polyfill. 

When they add new stuff to Javascript they provide equivalent code 
that works in older versions that's called "polyfill".  It's 
convenient because it lets you use the new API without needing 
alternate versions for older interpreters.

[toc] | [prev] | [next] | [standalone]

#118976

Josh Vanderhoof wrote:
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> 
>> Josh Vanderhoof <x@y.z> posted:
>>> MitchAlsup <user5857@newsgrouper.org.invalid> writes: >> > Note to 
>>> µArchitects, put the instruction in even if you >> > are  going to 
>>> TRAP to SW emulation. Later on when DIV is >> > implemented it just 
>>> runs faster and you had to do nothing >> > (but put it in). >>  You 
>>> need to make it fast enough so that compilers are not >> tempted to 
>>> call software emulation.  Also beware of >> interrput  latency, >  I 
>>> am shooting at 10 cycles there and 10 cycles back.  Would it be 
>>> possible to have a hardware version of polyfill? The  basic idea 
>>> would be that instead of emulation via trapping, the  software calls 
>>> a standardized divide routine. On hardware with a  divide instruction 
>>> it checks the routine and if it sees it's the  standard divide 
>>> routine it just uses its divide instruction  instead.  If it doesn't 
>>> have hardware division it just runs the  divide routine. 
>>
>> I do not see any justification of NOT having DIV as an instruction and 
>> in HW (by means of some king of sequencer). In the same way we can put 
>> 16 GBOoO cores on a single die with 256-bit wide SIMD,  the amount of 
>> area saved not doing DIV is invisible when seen at  the die-level.
>> In the smallest conceivable implementations, DIV is a multiplexer in 
>> the feedback-loop around the integer ADDer and a 5-state sequencer.
>> For me, I can't see building a core that does not have a 64×64 
>> multiplier, either. 
> 
> I get that, but I'm not really talking about the necessity of divide 
> instructions.  I'm talking about dealing with processors with different 
> sets of features.
> 
> Say instead it's for something called featurex and some processors want 
> it in hardware and some don't.  It'd be much easier for someone writing 
> the software if a standard sequence of instructions for doing featurex 
> was defined and new processors that do featurex in hardware 
> automatically checked call targets and recognize when the instruction 
> sequence matches featurex. Then when the routine is called later uses 
> the dedicated instruction instead doing the call.

There is simply no way to do that for individual instructions intended 
to be used in a tight loop. The AES opcodes are a typical example:

You can write two different functions, one using AES opcodes and one 
doing it with regular integer instructions, but if you try to replace 
each AES opcode with a sequence that can be back-patched into the actual 
instructions, then you will probably end up with far slower results.

The correct way here is to have a function pointer that initially points 
at a thunk which checks (CPUID) the local cpu and then updates the 
pointer to go directly to the optimized version.

Terje
> 
> It's be really nice because the code would be identical for everything 
> and also run about as fast as possible on everything. I have no idea how 
> hard it would be to keep the track of which subroutines are actually new 
> instructions though.
> 
> I'd much rather have something like this than have to write multiple 
> versions of things depending on whether or not some CPUID bit is set.
> 
>>> I think I'd be more likely to use new instructions if they worked  
>>> this way, providing the standard polyfill routine in the  
>>> documentation for the new instruction.  The way things work now I  
>>> only use them after they've been around for a decade. 
>>
>> I have no idea what you mean by polyfill. 
> 
> When they add new stuff to Javascript they provide equivalent code that 
> works in older versions that's called "polyfill".  It's convenient 
> because it lets you use the new API without needing alternate versions 
> for older interpreters.

They have the luxury of JIT everywhere so they can still run at 
near-hardware speed after first finding the opcodes are available.

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[toc] | [prev] | [next] | [standalone]

#118985

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:

> The correct way here is to have a function pointer that initially points 
> at a thunk which checks (CPUID) the local cpu and then updates the 
> pointer to go directly to the optimized version.

gfortran does that for calling different versions of matmul
compiled with different flags.

-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#119003

Thomas Koenig wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> 
>> The correct way here is to have a function pointer that initially points
>> at a thunk which checks (CPUID) the local cpu and then updates the
>> pointer to go directly to the optimized version.
> 
> gfortran does that for calling different versions of matmul
> compiled with different flags.
> 
I re-invented this technique for my final (?) word count version, it has 
4-5 different kernels plus a benchmarking startup: Measure the speed for 
a 4KB block of input, testing every kernel, then patch the pointer to go 
directly to the fastest.

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[toc] | [prev] | [next] | [standalone]

#119060

On 10/31/26 3:44 AM, Terje Mathisen wrote:
> Josh Vanderhoof wrote:
[snip]
>> Say instead it's for something called featurex and some 
>> processors want it in hardware and some don't.  It'd be much 
>> easier for someone writing the software if a standard sequence 
>> of instructions for doing featurex was defined and new 
>> processors that do featurex in hardware automatically checked 
>> call targets and recognize when the instruction sequence 
>> matches featurex. Then when the routine is called later uses 
>> the dedicated instruction instead doing the call.
> 
> There is simply no way to do that for individual instructions 
> intended to be used in a tight loop. The AES opcodes are a 
> typical example:
> 
> You can write two different functions, one using AES opcodes and 
> one doing it with regular integer instructions, but if you try 
> to replace each AES opcode with a sequence that can be 
> back-patched into the actual instructions, then you will 
> probably end up with far slower results.

Besides the slowness factor (though still faster than trap-and-
emulate), there is the problem that one would need either to use
fixed registers for the inputs and outputs or provide something
like the Mill's conform operation to select the arguments and
define the destination. If the number of operands was limited to
the number in general instructions (say four register operands),
a prefix instruction (similar to My 66000's DOUBLE) could
provide the explicit operands (with implicit operands also
being possible).

If the function call used a table index rather than an offset
from the instruction address, one index could be available for
each new instruction so hardware could quickly determine the
instruction.

This would seem to double the size of the "instruction" — e.g.,
a 32-bit operand-defining prefix and a 32-bit operation-
designating instruction. (One might have implicit operands
defined when the prefix is not used.) It is not clear if
such is a good tradeoff.

Intel at least also seems to be eager to exclude functionality,
so an automated handling faster than trap-and-emulate might not
be attractive to Intel even if the performance was slow.

(Some functionality would also be difficult to emulate in
software. While x86 transactional memory required having a
fallback path (so it was more hint-like), the performance
benefit of the extra hardware support was the main motivation.)

For AES there are probably also advantages for emulation
software not using per-instruction "translation". Software might
also choose to use a different operation that is good enough for
its use case and have easier software implementation. There may
also be I/O devices which provide acceleration for some
operations, a processor core might not be able to decide between
software emulation and handoff to an accelerator.

> The correct way here is to have a function pointer that 
> initially points at a thunk which checks (CPUID) the local cpu 
> and then updates the pointer to go directly to the optimized 
> version.

I feel that the _correct_ way is to use an intermediate software
distribution format that is translated to the specific machine
code. (This would still have code duplication issues when
supporting multiple architectures within a family if the special
code was required to be supported on all cores.) This even
allows new intermediate format software to run on old hardware
by updating the translator. (Old hardware might not cache the
function addresses near the instruction cache for much later
added instructions. Caching the actual functions would also have
storage limitations compared to ROM microcode.)

(The Stanford MIPS design used a code reorganizer to support an
intermediate format that was agnostic of pipeline
characteristics. If commercial MIPS had used an intermediate
software distribution format, delayed branches could have been
eliminated even with a very simple translation mechanism. With a
more complex intermediate format, multiplication and division
could have been changed to use GPRs.)

Sadly, using an intermediate format can cause problems when
there are bugs in the final translator or when the software has
bugs that are only manifested in a later implementation. Formal
methods might eliminate the former, but "it works on my system"
seems a common attitude and even with good intentions bugs can
be released where an intermediate layer makes debugging harder.

[toc] | [prev] | [next] | [standalone]

#118982 — Unimplemented opcodes via jump tables (was: interrupt handling latency and weird register use)

Josh Vanderhoof <x@y.z> schrieb:

> Say instead it's for something called featurex and some processors 
> want it in hardware and some don't.  It'd be much easier for 
> someone writing the software if a standard sequence of 
> instructions for doing featurex was defined and new processors 
> that do featurex in hardware automatically checked call targets 
> and recognize when the instruction sequence matches featurex. 
> Then when the routine is called later uses the dedicated 
> instruction instead doing the call.

You could have instructions that either do things in hardware or
jump to a subroutine at a defined address from a jump table
index by opcode.  That would solve the problem, I think, and

> It's be really nice because the code would be identical for 
> everything and also run about as fast as possible on everything. 
> I have no idea how hard it would be to keep the track of which 
> subroutines are actually new instructions though.

this would be OK.

Has anybody actually done this?  Seems obvious, but maybe only
in hindsight, and could save the RISC-V compiler writers a
lot of grief, at least as far as compatibility is concerned, but
cost would be another matter.

-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#118992 — Re: Unimplemented opcodes via jump tables (was: interrupt handling latency and weird register use)

Thomas Koenig <tkoenig@netcologne.de> posted:

> Josh Vanderhoof <x@y.z> schrieb:
> 
> > Say instead it's for something called featurex and some processors 
> > want it in hardware and some don't.  It'd be much easier for 
> > someone writing the software if a standard sequence of 
> > instructions for doing featurex was defined and new processors 
> > that do featurex in hardware automatically checked call targets 
> > and recognize when the instruction sequence matches featurex. 
> > Then when the routine is called later uses the dedicated 
> > instruction instead doing the call.
> 
> You could have instructions that either do things in hardware or
> jump to a subroutine at a defined address from a jump table
> index by opcode.  That would solve the problem, I think, and

That would add LDD-latency plus JUMP-latency to instruction-latency--
even if the index was extracted by HW. Probably around 5-6 cycles.
 
> > It's be really nice because the code would be identical for 
> > everything and also run about as fast as possible on everything. 
> > I have no idea how hard it would be to keep the track of which 
> > subroutines are actually new instructions though.
> 
> this would be OK.
> 
> Has anybody actually done this?

How do you think microCode works ??

>                                  Seems obvious, but maybe only
> in hindsight, and could save the RISC-V compiler writers a
> lot of grief, at least as far as compatibility is concerned, but
> cost would be another matter.
> 

[toc] | [prev] | [next] | [standalone]

#118995 — Re: Unimplemented opcodes via jump tables (was: interrupt handling latency and weird register use)

MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> posted:
>
>> Josh Vanderhoof <x@y.z> schrieb:
>> 
>> > Say instead it's for something called featurex and some processors 
>> > want it in hardware and some don't.  It'd be much easier for 
>> > someone writing the software if a standard sequence of 
>> > instructions for doing featurex was defined and new processors 
>> > that do featurex in hardware automatically checked call targets 
>> > and recognize when the instruction sequence matches featurex. 
>> > Then when the routine is called later uses the dedicated 
>> > instruction instead doing the call.
>> 
>> You could have instructions that either do things in hardware or
>> jump to a subroutine at a defined address from a jump table
>> index by opcode.  That would solve the problem, I think, and
>
> That would add LDD-latency plus JUMP-latency to instruction-latency--
> even if the index was extracted by HW. Probably around 5-6 cycles.

Sounds reasonable.  Much faster than trap+emulate, fixup at runtime
would probably need lots of NOPs, and branching to different
versions multiplies code size by the number of versions you have.

It would simply be just another compromise, I guess.

>  
>> > It's be really nice because the code would be identical for 
>> > everything and also run about as fast as possible on everything. 
>> > I have no idea how hard it would be to keep the track of which 
>> > subroutines are actually new instructions though.
>> 
>> this would be OK.
>> 
>> Has anybody actually done this?
>
> How do you think microCode works ??

What I was thinking of was to expose this in the ISA, so people
could use multiplication etc without having to switch on CPU
type, which is a pain.  Call it poor man's millicode.

-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#119004 — Re: Unimplemented opcodes via jump tables (was: interrupt handling latency and weird register use)

Thomas Koenig <tkoenig@netcologne.de> writes:
>MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
>> Thomas Koenig <tkoenig@netcologne.de> posted:
>>> You could have instructions that either do things in hardware or
>>> jump to a subroutine at a defined address from a jump table
>>> index by opcode.  That would solve the problem, I think, and
>>
>> That would add LDD-latency plus JUMP-latency to instruction-latency--
>> even if the index was extracted by HW. Probably around 5-6 cycles.

Just treat it like a call, and predict it very accurately after the
first execution.  The major cost is the extraction of the various
fields and the access to the registers; alternatively, have 32K
variants of each software-defined three-address instruction (assuming
32 registers) where the registers are hard-coded in the variant.

>What I was thinking of was to expose this in the ISA, so people
>could use multiplication etc without having to switch on CPU
>type, which is a pain.

Ideally the CPU exposes the defined instruction, and leaves the
implementation details to some deeper level in the implementation, and
for this kind of implementation maybe in the firmware.  If the
implementations are visible in the user-level and system-level address
space, we cannot avoid making it somewhat visible.

An alternative would be to put these implementations in a separate
address space, but:

1) That implies additional hardware costs which are not necessarily
worth the benefit.

2) When the implemented instruction performs memory accesses or
control flow, extra capabilities are needed to do that in the
usr/system address space.

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

[toc] | [prev] | [next] | [standalone]

#118961 — Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V

In article <ygnwlr084yt.fsf@y.z>, x@y.z (Josh Vanderhoof) wrote:

> Would it be possible to have a hardware version of polyfill?  The 
> basic idea would be that instead of emulation via trapping, the 
> software calls a standardized divide routine.  On hardware with a 
> divide instruction it checks the routine and if it sees it's the 
> standard divide routine it just uses its divide instruction 
> instead.  If it doesn't have hardware division it just runs the 
> divide routine.

Older 32-bit versions of AIX had a version of this IIRC that IBM called
"millicode." The problem was that POWER1 and POWER2 didn't have quite the
same ISA as 32-bit PowerPC. IBM produced lots of material about how they
were /mostly/ the same, but the differences were a real pain for
compilers. 

You could do the same things on the variant ISAs, but some of them needed
more than one instruction. So the compiler would generate enough space
for the longest of the alternative instruction sequences and the loader,
which knows what hardware it's running on, would fill in the correct
sequences, and no-ops in any spare space. 

None of this was necessary on 64-bit AIX, where the core ISA was
standardised from the beginning. 

John 

[toc] | [prev] | [next] | [standalone]

#118928

On 10/28/2026 7:33 AM, Waldek Hebisch wrote:
> MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>>
>>> 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:
>>
>> But "lack of division" is also costly !! especially if some future
>> implementation will have division {which it will} and then you have
>> no direct means to make the dusty decks fast.
> 
> You assume binaries or assembler code.  In microcontroller world
> programs are frequently compiled for one specific CPU model.
> And in case of microcontrollers savings due to ommision of
> divide circuit can be significant.  I know you do not like
> Risc-V, but one small model (CH32V003) even skips multiplication.
> IIUC even smallest Arm-s have multiplication (which theoretically
> can be slow, but on all small models that I know it 32 bit
> multiplication executes in 1 cycle).
> 

Yeah.

Ironically, the smallest microcontroller style core I did was using a 
very limited subset of the SuperH ISA.

But, in this case, can note:
   16-bit instructions;
   No multiply or divide;
   No general-purpose shift;
     Would use "shift slides".
   No auto-increment (was present in normal SH);
   Not pipelined and would do an I$ miss every 8 instrs;
     Also no real D$ either, would miss nearly every access;
     And memory access was not pipelined.
   ...

This whole thing kind of died off, ironically, because I didn't have 
much particular use for cheap-but-slow cores.

A small RISC-V core would cost more, but be a little more useful.
For a microcontroller use-case, RV32I is actually pretty sane; though 
RV32IMC or RV32IC is more industry-standard here.

There is RV32E (with 16 registers), but it seems relatively few people 
want to limit the register space that bad.

Main "cheapening" would be to only allow X0 and X1 as destinations for 
JAL and JALR, and requiring that Rs2 for Bcc ops is X0.


>> Note to µArchitects, put the instruction in even if you are going to
>> TRAP to SW emulation. Later on when DIV is implemented it just runs
>> faster and you had to do nothing (but put it in).
> 
> You need to make it fast enough so that compilers are not tempted
> to call software emulation.  Also beware of interrput latency,
> if division is slow microcontroller probably should allow
> interrupts in the middle of division.
> 

Yeah.


Fast interrupt handling is always a long standing issue.

Seemingly, there is a multi-way split:
   Require ISR to spill/reload registers manually;
     Looks bad on paper, but often cheaper/faster in practice.
   Register Banks:
     Looks fast, but there are a lot of "hidden gotchas" here.
   Automatic spill/reload to/from memory contexts:
     Seems clever, but likewise comes with a lot of "gotchas".


Half tempting is to provide some way to allow the ISRs to patch 
instructions directly to a handler sequence.
This makes a problem though mostly for things like addressing.

Say, in many cases, something like a RISC-V JAL doesn't reach far enough 
to be able to put a patched-in handler in-range.

So, one almost needs something like a hidden architectural jump table, 
say and special instructions to jump via this jump table.


For BGBCC, I had taken a different option:
The PE/PEL loading is handled by the kernel;
The PE read-only sections, data/bss, and stack, are unrelated;
The compiler counts up how many "potentially trapping" instructions are 
used and explicitly leaves space for basic patch handling (enough pad 
space for encode an Abs64 branch).

For RV64, this pad space would need to be within 1MB of the offending 
instruction, but for XG3 can be within 16MB.


There is still a little more complexity if dealing with Linux ELF-PIE 
binaries (and dealing with glibc's "ld.so" behavior), but there are 
possible options that could be tried (to maybe provision for providing 
free space near the ".text" sections).

[toc] | [prev] | [next] | [standalone]

#118943

MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>especially if some future
>implementation will have division {which it will} and then you have
>no direct means to make the dusty decks fast.
>
>Note to µArchitects, put the instruction in even if you are going to
>TRAP to SW emulation. Later on when DIV is implemented it just runs
>faster and you had to do nothing (but put it in).

Microarchitects will not implement an instruction that's not in the
instruction set designed by the architects.  But for architects, your
advice is good and not just for division.

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

[toc] | [prev] | [next] | [standalone]

#118884

On Tue, 27 Oct 2026 16:14:14 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

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

I certainly don't. Doing anything by software is excruciatingly slow,
especially if the program includes any branch instructions. Divisions
are needed less often than multiplies, yes, but if they're slow they
will still impact performance severely.

John Savard

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.arch

csiph-web