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

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

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

[toc] | [next] | [standalone]

#117721

Kragen Javier Sitaker <kragen@canonical.org> writes:
>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.

And Alpha and, most recently, IA-64.

Grinberg actually mentioned it, but got it wrong.  He claimed that
multiplication and division are indepenently optional, while in the
RISC-V specification, you get none or both.

I found that surprising, too, but the world has continued to turn
since the days of Alpha and IA-64, so I guess they thought: Any CPU
big enough to have a multiplier will also be big enough for a division
instruction.

Followups set to comp.arch.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2026 CFP: http://www.euroforth.org/ef26/cfp.html

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

#117735

In comp.arch Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Kragen Javier Sitaker <kragen@canonical.org> writes:
>>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.
> 
> And Alpha and, most recently, IA-64.
> 
> Grinberg actually mentioned it, but got it wrong.  He claimed that
> multiplication and division are indepenently optional, while in the
> RISC-V specification, you get none or both.

Reading current spec I see:

: The Zmmul extension implements the multiplication subset of the M
: extension. It adds all of the instructions defined in Section 12.1,
: namely: MUL, MULH, MULHU, MULHSU, and (for RV64 only) MULW.
: The encodings are identical to those of the corresponding M-extension
: instructions. M implies Zmmul.

So, one can get multiplication without division.  One can not
get division without multiplication, but that is not a surprise.
 
> I found that surprising, too, but the world has continued to turn
> since the days of Alpha and IA-64, so I guess they thought: Any CPU
> big enough to have a multiplier will also be big enough for a division
> instruction.

-- 
                              Waldek Hebisch

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

#118864

> Grinberg actually mentioned it, but got it wrong.  He claimed that
> multiplication and division are indepenently optional, while in the
> RISC-V specification, you get none or both.

RISC-V allows only implementing multiplication without implementing
division, with "Zmmul" being the official name for this partial
implementation of M. 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...

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

#118868

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.

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.

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

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

#118875

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.

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

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

Let me assert that adding IDIV/UDIV is WAY LESS COSTLY than adding 1300
SIMD instructions.

>               And it's not that frequent, which means that if you
> throw lots of hardware at making it fast, the payoff will be small.

Having it perfectly defined is the critical part {bit patterns in,
bit patterns out} then each implementation can choose for itself
whether to put it in or leave it out.

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

I have considered a x / (2^n) instruction--only a few gates worse than
SRA.
 
> Even relatively recent architectures like Alpha (1992) and IA-64
> (2001) do not include integer division instructions.

And look at where they are now.
 
> So I found the inclusion of division in the RISC-V M extension
> surprising.  They then separated them again by defining Zmmul.

RISC-V is like a shotgun with a short barrel and no choke--it just
needs to hit something for its backers to say they hit something.
> 
> - anton

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

#118876

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

> 
> Having it perfectly defined is the critical part {bit patterns in,
> bit patterns out} then each implementation can choose for itself
> whether to put it in or leave it out.
> 

An interesting question here is "Do one has to include 128b / 64b
division in the ISA or it's better to leave it off?".
AMD decided that it was needed, but it seems that nobody else followed
the suit.

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

#118897

Michael S <already5chosen@yahoo.com> posted:

> On Tue, 27 Oct 2026 17:06:29 GMT
> MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
> 
> > 
> > Having it perfectly defined is the critical part {bit patterns in,
> > bit patterns out} then each implementation can choose for itself
> > whether to put it in or leave it out.
> > 
> 
> An interesting question here is "Do one has to include 128b / 64b
> division in the ISA or it's better to leave it off?".
> AMD decided that it was needed, but it seems that nobody else followed
> the suit.

My 66000 provides 128/64 by means of the CARRY instruction-modifier.

Few architectures have what CARRY provides en-the-large--everything from
ADC-SUBC to double wide shifts, double wide inserts, exact FP arithmetics
...

And on the exact FP arithmetics, the inexact bit does not get set (when
it is not providing useful information).

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

#118908 — 128/64 division (was: interrupt handling latency and weird register use)

Michael S <already5chosen@yahoo.com> writes:
>An interesting question here is "Do one has to include 128b / 64b
>division in the ISA or it's better to leave it off?".
>AMD decided that it was needed, but it seems that nobody else followed
>the suit.

The same can be seen already in the 32-bit relatives.  Most (all?)
RISCs just have 32/32 division, if they have division at all, IA-32
has 64/32.  So they continue that in 64-bit RISCs and AMD64.

Given the existing programming languages, the need for 128/64 bit
division is rare (Forth has UM/MOD and SM/REM, which correspond to
AMD64 DIV and IDIV instructions, respectively), and three source
registers does not fit in usual instruction encodings, so most
architectures leave 128/64 to software.

About software implementations: Implementing 128/64 when you only have
64/64 is messy, however.  And general long division is messy in any
case (but I expect that 128/64 helps in that case; certainly n/64 for
arbitrary n is easy with 128/64 and messy with 64/64).

Let's see how expensive they are on a Ryzen 8700G (Zen4, with 128/64
support) and Power8 (without):

Invocations:

# 64/64
time ./gforth-fast -e ': foo #1_000_000_000_000 {: addend :} 1_000_000_000 {: divisor :} addend 100000000 0 do divisor /mod + addend + loop . ; foo bye'
# 128/64
time ./gforth-fast -e ': foo #1_000_000_000_000_000_000_000_000. 1_000_000_000 {: divisor :} divisor 2/ 1- {: dmax :} 100000000 0 do divisor sm/rem swap dmax min loop d. ; foo bye'

64/64  128/64
0.385s 0.424s Ryzen 8700G
1.176s 2.115s Power8

Given the rarity of 128/64, a factor of 2 looks acceptable.  But if
the division was as fast as on Power8 as on the Ryzen 8700G, the
overhead of 128/64 might be a larger factor (that would probably still
be considered acceptable).

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

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

#118910 — Re: 128/64 division (was: interrupt handling latency and weird register use)

On Wed, 28 Oct 2026 08:34:27 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>The same can be seen already in the 32-bit relatives.  Most (all?)
>RISCs just have 32/32 division, if they have division at all, IA-32
>has 64/32.  So they continue that in 64-bit RISCs and AMD64.

Since System/360 had 64/32 division, quite automatically I included
128/64 division in Concertina II as the DIVIDE EXTENSIBLY instruction,
while having simple 32/32 and 64/64 instructions also as the plain
DIVIDE instruction (the System/360 only had the former) on the grounds
that this is what compilers will usually use.

John Savard

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

#118881

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

Intel actually did this correctly back in 1978/79 when they designed the 
8087: If you did not have the FPU, then the main 8088 CPU would trap to 
an emulation layer which did what was required. The only real problem 
was that this was significantly slower than a direct call to a SW 
function which did the same operation.

What we ended up with on most applications was a hybrid, where the 
compiler would generate calls to a shim, said shim would inspect the 
available HW (FPU/No FPU) and patch the call:

Either just modify the call target to go directly to the emuation 
function, or replace the CALL FDIV_EMULATION machine code with the 
actual 8087 FDIV opcode.

Since FPU ops could be both larger and shorter than a 16-bit CALL, the 
compiler also had to pad each instance to whatever was larger.

Terje

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

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

#118886

On Tue, 27 Oct 2026 19:20:04 +0100, Terje Mathisen
<terje.mathisen@tmsw.no> wrote:

>The only real problem 
>was that this was significantly slower than a direct call to a SW 
>function which did the same operation.

Hence, SANE on the early Macintosh. Which was insane because it
rejected Mitch's approach, and forced subroutine calls even if you had
an FPU.

John Savard

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

#118895 — Re: floating point, interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant)

According to Terje Mathisen  <terje.mathisen@tmsw.no>:
>Intel actually did this correctly back in 1978/79 when they designed the 
>8087: If you did not have the FPU, then the main 8088 CPU would trap to 
>an emulation layer which did what was required. The only real problem 
>was that this was significantly slower than a direct call to a SW 
>function which did the same operation.

Sadly, no.  Without an 8087 the 8088 just ignored the ESC opcode used
by floating instructions, but ...

>What we ended up with on most applications was a hybrid, where the 
>compiler would generate calls to a shim, said shim would inspect the 
>available HW (FPU/No FPU) and patch the call:

The Wizard C compiler, the predecessor of Turbo C, had a hack where it
emitted floating point instructions but with the first byte replaced
by a trap opcode.  Then it was roughly as you described, patch it
to a real float instruction if there was an 8087, or call the software
version.

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

#118903 — Re: floating point, interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant)

On 10/27/26 3:08 PM, John Levine wrote:
> According to Terje Mathisen  <terje.mathisen@tmsw.no>:
>> Intel actually did this correctly back in 1978/79 when they designed the
>> 8087: If you did not have the FPU, then the main 8088 CPU would trap to
>> an emulation layer which did what was required. The only real problem
>> was that this was significantly slower than a direct call to a SW
>> function which did the same operation.
> 
> Sadly, no.  Without an 8087 the 8088 just ignored the ESC opcode used
> by floating instructions, but ...
> 
>> What we ended up with on most applications was a hybrid, where the
>> compiler would generate calls to a shim, said shim would inspect the
>> available HW (FPU/No FPU) and patch the call:
> 
> The Wizard C compiler, the predecessor of Turbo C, had a hack where it
> emitted floating point instructions but with the first byte replaced
> by a trap opcode.  Then it was roughly as you described, patch it
> to a real float instruction if there was an 8087, or call the software
> version.
> 
We also did that in the PC/IX kernel.

Brian

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

#118911 — Re: floating point, interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant)

John Levine <johnl@taugh.com> wrote:
> According to Terje Mathisen  <terje.mathisen@tmsw.no>:
>>Intel actually did this correctly back in 1978/79 when they designed the 
>>8087: If you did not have the FPU, then the main 8088 CPU would trap to 
>>an emulation layer which did what was required. The only real problem 
>>was that this was significantly slower than a direct call to a SW 
>>function which did the same operation.
> 
> Sadly, no.  Without an 8087 the 8088 just ignored the ESC opcode used
> by floating instructions, but ...

I did not look at 8088, but 80386 trapped when requested.

-- 
                              Waldek Hebisch

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

#118920 — Re: floating point, interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant)

According to Waldek Hebisch <antispam@fricas.org>:
>> Sadly, no.  Without an 8087 the 8088 just ignored the ESC opcode used
>> by floating instructions, but ...
>
>I did not look at 8088, but 80386 trapped when requested.

The 8087 and 80287 were separate chips that sat on the bus
and snooped to see what to do.  No x87, no snooping, no
action.

The 386 had a much more complicated coprocessor interface which could
work with either a 16 bit 287 or a 32 bit 387.  As you note, it added
an option to trap if you had neither.

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

#118912

Terje Mathisen <terje.mathisen@tmsw.no> wrote:
> MitchAlsup 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.
> 
> Intel actually did this correctly back in 1978/79 when they designed the 
> 8087: If you did not have the FPU, then the main 8088 CPU would trap to 
> an emulation layer which did what was required. The only real problem 
> was that this was significantly slower than a direct call to a SW 
> function which did the same operation.

I used TeX on 386.  It did relatively small number of floating
point operations.  On 386 with 387 FPU operation almost vanished
in noise.  On 386 without FPU TeX on one of my inputs had 3 times
longer execution time, that is about 66% time was spent in FPU
emulator.  IIRC emulation was at least hundreds (if not thousends)
times slower than FPU (which was also not that fast).

That partially could be due to specific emulation, but when
program needed to run fast on machines without FPU one basically
wanted to eradicate all uses of FPU in that program.

-- 
                              Waldek Hebisch

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

#118915

antispam@fricas.org (Waldek Hebisch) writes:
>I used TeX on 386.  It did relatively small number of floating
>point operations.

AFAIK TeX does not do FP, or at least the versions from those times
did not.  That's because TeX was intended to create reproducible
results across machines, and FP was not useful for that when TeX was
written, because FP operations behaved differently on different
machines.

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

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

#118926

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> antispam@fricas.org (Waldek Hebisch) writes:
>>I used TeX on 386.  It did relatively small number of floating
>>point operations.
> 
> AFAIK TeX does not do FP, or at least the versions from those times
> did not.  That's because TeX was intended to create reproducible
> results across machines, and FP was not useful for that when TeX was
> written, because FP operations behaved differently on different
> machines.

Wrong.  Main computations like line and page breaking were integer
only.  But some positioning decisions that could only lead to
tiny error were done in floating point.  Knuth claimed that each
implementation would do line and page breaks in "the same" place
and AFAIK this was true.  But he did not claim bit-for-bit indentical
results, the claim was that differences were smaller that human
can see.

IIRC Knuth allowed use of fixed point for those computations, but
WEB to C system (and probably also other implementations) used
floating point.

-- 
                              Waldek Hebisch

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

#118929

On 10/28/2026 7:41 AM, Anton Ertl wrote:
> antispam@fricas.org (Waldek Hebisch) writes:
>> I used TeX on 386.  It did relatively small number of floating
>> point operations.
> 
> AFAIK TeX does not do FP, or at least the versions from those times
> did not.  That's because TeX was intended to create reproducible
> results across machines, and FP was not useful for that when TeX was
> written, because FP operations behaved differently on different
> machines.
> 

Still sort of an issue IME:

Different compilers, different optimization settings, whether it is 
using x87 or SSE, ..., may subtly change the results of FP calculations.


Well, or sometimes it may be CPU dependent:
I had encountered some code that failed when compiled for 64-bit and run 
on an Intel CPU, but still worked fine on an AMD CPU;
I eventually figured out it was because the code in question was doing 
something unorthodox (using "float*" and "double*" operations to copy 
memory) and the Intel CPU's MOVSS and MOVSD instructions were apparently 
stomping the value if it was a NaN (changing the NaN bit pattern to a 
different NaN bit pattern).

Whereas, on the AMD CPU, "MOVSS/MOVSD xmm, [mem]" behaved the same as 
"MOVD/MOVQ xmm, [mem]", leaving the NaN's alone.



Though, that said, did at one point have a CPU that seemingly had 
non-deterministic floating-point math, where one could run the same 
calculation multiple times and get slightly different results each time.

I think I eventually realized that this particular CPU (an AMD Athlon64 
/ Clawhammer) had floating-point math that was sensitive to CPU 
temperature (CPU got hot, and FPU math got noisy).

Nothing drastic, mostly it was like it would start adding random noise 
into the low-order bits of FPU calculations. Mostly didn't effect much.

Not exactly the worst issue this computer had (actually, it was horribly 
unstable and crash-prone in general).


Well, I suspect it was maybe a case of CPUs were often clocked at a 
point where they were on the knife edge of being able to work at all. I 
lot of my follow-on computers, I ended up needing to explicitly underclock.

Actually, my current Xen+ PC is the first I ended up not needing to 
underclock, as it appears to run pretty stable and reliable at its stock 
CPU speed.

...


> - anton

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

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.arch

csiph-web