On 7/21/2021 2:57 PM, Marcus wrote:
> On 2021-07-21 18:58, Anton Ertl wrote:
>> Marcus <m.delete@this.bitsnbites.eu> writes:
>>> As we all know, support for floating-point exceptions comes with a cost
>>> (sometimes significant, since it dictates many aspects of a HW
>>> implementation for instance).
>>
>> Unfortunately, wrt. IEEE FP "exception" has a different meaning (it's
>> a condition that, by default, results in setting a sticky flag) than
>> in computer architecture (a control-flow change).  Which one do you
>> mean?
>
> It does not matter for answering the questions. I am aware of the
> different possibilities and interpretations. For instance I think that
> some TI DSP:s use sticky flags rather than HW traps.
>
> That said I see problems with both implementations (traps vs flags), if
> nothing else from a programmer's point of view.
>

Some cases could at least be encoded using bit patterns in NaNs, though
cases which do not result in a NaN would effectively be lost.

Ideally, something like 'inexact' would be carried along with the value
so that one could determine whether or not a particular calculation
needed to be rounded. Though, alas, the standard FP formats make no
provision for this.

In theory, one could make the assumption that any result where the
low-order bits are non-zero is inexact, and potentially the FPU could
use a rounding hack where an inexact result is never rounded such that
the low-order bits are all zeroes. Spreading this over multiple bits
would means that on-average it only carries a fraction of a bit of
precision loss.

Ironically, this also plays well with "limited carry propagation"
rounding, since a chain of ones being rounded to zeroes is the main case
where this would occur, and will not typically occur with limited carry
rounding. Though, there is still the possibility of a previously-inexact
operation landing on zero by chance. In this case, there would be some
logic of "if result would land on zero, and inputs are marked inexact,
round so that it does not land on zero".

Worth making it a defined behavior? Probably not.

Ironically, it would make doing integer math using doubles actually less
accurate, since rather than one having a full 2^52 to play with (and
typically always getting an exact result over this range), they would
only (safely) have ~ 2^48 or so before the wacky rounding rules kick in
(assuming the 'inexact' status is based on the low-order 4 bits).

>>
>>> If we imagine an alternative universe in
>>> which the dominant floating-point standard did not require exceptions,
>>> I suspect that most hardware (and language) implementations would most
>>> likely be simpler, more energy efficient and more suitable for parallel
>>> and pipelined floating-point operations.
>>
>> Detecting IEEE exceptions is part of computation of the result; you
>> have to handle divide-by-zero, inexact, invalid, overflow, and
>> underflow conditions when computing the result.  Ok, you then need to
>> propagate the flags such that a later instruction can read it, but
>> looking at the integer condition codes present in the dominant
>> architectures, that does not seem to be a big problem.
>>
>> The dynamic rounding mode seems to be a bigger problem and has been
>> discussed here repeatedly.
>
> I agree - that's the second grudge that I have with the IEEE 754
> standard. As a programmer I have gotten nothing but problems from the
> dynamic rounding modes. As a hardware developer I have just ignored the
> problem (I only implement a single rounding mode).
>

Likewise. If anything, it might make sense to have it as part of the
instruction.

Say, one has instructions which either do round-to-nearest or
truncate-towards-zero. Global flags are kind of a poor option, more so
if they have a non-local range of effect.

Though, ironically, given the way the FPU worked in SH-4 (one needed to
reload the status register to switch between operating on single and
double precision values), this would also implicitly clear the sticky
flags and reset the rounding mode to whatever is encoded in value being
reloaded into the register.

>>
>>> My questions are:
>>>
>>> 1) What (in your opinion) are the benefits of floating-point exceptions?
>>
>> Numerical experts use them for special purposes.  I have seen and
>> forgotten examples that looked sensible to me.
>>
>>> 2) In what situations have you had use for floating-point exceptions?
>>
>> None.  I hardly use FP.
>
> Same - except I use FP all the time.
>

I use FP fairly often, but it is still "a fairly small part of the pie"
if compared with integer operations.

On 2021-07-22 02:31, Stephen Fuld wrote:
> On 7/21/2021 6:46 AM, Marcus wrote:
>> On 2021-07-21 15:44, Marcus wrote:
>>> Hi!
>>>
>>> I would like to ask a couple of simple questions in this group, related
>>> to the IEEE 754 standard and floating-point exceptions.
>>>
>>> (Some of you may know that I've been pondering this subject before in
>>> other forums).
>>>
>>> As we all know, support for floating-point exceptions comes with a cost
>>> (sometimes significant, since it dictates many aspects of a HW
>>> implementation for instance). If we imagine an alternative universe in
>>> which the dominant floating-point standard did not require exceptions,
>>> I suspect that most hardware (and language) implementations would most
>>> likely be simpler, more energy efficient and more suitable for parallel
>>> and pipelined floating-point operations.
>>>
>>> My questions are:
>>
>> To answer my own questions... In my fields which over the past 2-3
>> decades include 3D graphics, ray tracing, 3D polygonal mesh manipulation
>> algorithms, compression algorithms for triangle meshes, audio DSP, audio
>> synthesis, audio compression, space/satellite signal processing, image
>> processing and compression algorithms, AI / neural networks, image-based
>> eye- and head-tracking, least squares solvers, and so on, etc, I have to
>> say:
>
> Without in any way deprecating your experience, which is much greater
> than mine, it seems to be oriented toward the kinds of situations where
> errors are "contained" either in space or time. E.g. if an audio DSP
> messes up, it probably won't be noticed by the vast majority of users,
> and in any event, its effect will be gone in a small fraction of a second.
>
> Contrast this with the types of applications where errors might
> propagate or expand either in space or time, and thus cause noticeable
> problems.  I am thinking of perhaps FE modeling, or physics simulations.
>  John Dallman could probably provide more and better examples.

I have worked with things like IIR filters where errors will propagate
indefinitely. Same thing with many other of the problems that I've
worked with: if you get a NaN somewhere it will end up everywhere.

>
> Thus your response might be biased toward the "they don't matter" side
> of the question.
>

That is true. For all application areas that I mentioned, and all that I
can think of, I personally end up in the "they don't matter" camp.

Hence my questions - I am looking for valid reasons to use floating-
point exceptions, but since I have been unable to find them myself I
need help from others.

/Marcus

On 2021-07-21 22:15, Stefan Monnier wrote:
>> For instance, the very notion of floating-point exceptions (be they
>> exact HW traps, inexact "something went wrong" traps, or sticky flags
>> that you can poll, or something else) requires that you can make some
>> use of them - for instance take some corrective action in software,
>> using means that usually depend on the programming language.
>
> I always assumed (for no concrete reason) that the main users of those
> flags are very special-purpose code such as the implementation of the
> `sin` or `atan` functions, or the implementation of 128bit floats
> primitives on top of 64bit float hardware ops, ...

Mitch gave a good example (ATAN2): You check conditions *before* doing
calculations, to *avoid* exceptions. On a machine with sticky flags you
have the option to check conditions after the calculation instead, but
that is probably more work (you would have to deduce *what* went wrong).

Plus (and this is the kicker IMO): If your code *relies* on certain
floating-point exceptions to be enabled, you would have to make sure
that they are. In a library function this means that you would have to
push the current FPU configuration, set up your desired FPU
configuration, and at the function exit pop the FPU configuration of the
caller.

This can get really messy if you also have to push/pop the exception
handler (in case of trapping HW), or preserve old exception state (in
case of HW with sticky flags). And also - how would you propagate
legitimate exceptions to the caller (if the caller has enabled
exceptions, it may be expecting to get exceptions from the library
call)?

/Marcus

Marcus <m.delete@this.bitsnbites.eu> schrieb:

> Plus (and this is the kicker IMO): If your code *relies* on certain
> floating-point exceptions to be enabled, you would have to make sure
> that they are. In a library function this means that you would have to
> push the current FPU configuration, set up your desired FPU
> configuration, and at the function exit pop the FPU configuration of the
> caller.

This is exactly the model that Fortran follows if you use its IEEE
features (and they are supported).

https://j3-fortran.org/doc/year/18/18-007r1.pdf , clause 17, has all
the gory details.

You can change things like the underflow, halting or rounding mode
on entry to a procedure, but all the chapters specify that "the
processor shall not change the XXX mode on entry, and on return
shall ensure that the XXX mode is the same as it was on entry".

> This can get really messy if you also have to push/pop the exception
> handler (in case of trapping HW), or preserve old exception state (in
> case of HW with sticky flags). And also - how would you propagate
> legitimate exceptions to the caller (if the caller has enabled
> exceptions, it may be expecting to get exceptions from the library
> call)?

Fortran has no model of exceptions except for the IEEE ones.

If you want to see what IEEE support in a programming language
could look like, I think the draft Fortran standard is a good text
to look at.

On 2021-07-21 22:06, MitchAlsup wrote:
> On Wednesday, July 21, 2021 at 2:41:50 PM UTC-5, Marcus wrote:
>> On 2021-07-21 20:27, MitchAlsup wrote:
>>> On Wednesday, July 21, 2021 at 8:44:44 AM UTC-5, Marcus wrote:
>>>> Hi!
>>>>
>>>> I would like to ask a couple of simple questions in this group, related
>>>> to the IEEE 754 standard and floating-point exceptions.
>>>>
>>>> (Some of you may know that I've been pondering this subject before in
>>>> other forums).
>>>>
>>>> As we all know, support for floating-point exceptions comes with a cost
>>>> (sometimes significant, since it dictates many aspects of a HW
>>>> implementation for instance). If we imagine an alternative universe in
>>>> which the dominant floating-point standard did not require exceptions,
>>>> I suspect that most hardware (and language) implementations would most
>>>> likely be simpler, more energy efficient and more suitable for parallel
>>>> and pipelined floating-point operations.
>>>>
>>>> My questions are:
>>>>
>>>> 1) What (in your opinion) are the benefits of floating-point exceptions?
>>> <
>>> There are 6 people in the world who want FP exceptions with the semantic
>>> anywhere close to what IEEE 754 specifies. It is these same 6 people (and
>>> 18 professors) that want rounding modes anywhere close to what was
>>> specified.
>>> <
>>> Something like 99% of all FP applications, turn these features off and
>>> live with overflow->infinity, underflow->zero, and I still don't know anyone
>>> other than Kahan and Coonen that want inexact reported. 100% of
>>> physics programs start with data that is ALREADY inexact........
>> Thanks, that confirms my feelings.....
>>>>
>>>> 2) In what situations have you had use for floating-point exceptions?
>>> <
>>> None:
>>> <
>>> 3) Is making exception detection in HW hard at all ?
>>> <
>>> No, absolutely not. Detecting and raising exceptions in HW adds 0.0001%
>>> complexity to the design and construction of HW FP units {In a processor
>>> that has precise memory exceptions and recovers from branch mispredictions.}
>>> <
>>> It is for this reason that all HW provides FP exceptions--the cost is minuscule
>>> at most and nearly zero at best.
>> I admit that I am just a layman in this matter, but I think that there
>> are more dimensions to this problem, and the related costs.
>>
>> For instance, the very notion of floating-point exceptions (be they
>> exact HW traps, inexact "something went wrong" traps, or sticky flags
>> that you can poll, or something else) requires that you can make some
>> use of them - for instance take some corrective action in software,
>> using means that usually depend on the programming language.
>>
>> In certain classes of CPU and programming language combinations there
>> are straight forward ways of how to deal with this (e.g. HW traps +
>> language exceptions), but in other environments the answer is not as
>> simple.
>>
>> For instance, how should an overflow exception be handled in a GPU
>> shader language?
> <
> When I was doing a GPU, I actually ask the question in front of the majority
> of the design team:: "What, exactly, does it mean when 1,357 FP calculations
> all overflow in the same clock cycle ?" What do we want the semantics to be?"
> <
> Nobody had an answer...........which tells you more about the problem than
> of the team......
> <

Thanks for the story. What did you do in the end? Just ignore overflow?

>> I'm pretty sure that no HW/language combination
>> supports that scenario today (and thus by definition can not be
>> IEEE 754 compliant), and I'm also pretty sure that the cost for adding
>> that support would be non-zero - not only for the GPU ALU pipeline, but
>> for the entire HW/driver/SW stack.
> <
> In a GPU you can isolate the thread with the exception and run the rest
> to completion--then rerun the thread in isolation--you can get away with
> this because of the embarrassingly large amounts of parallelism.

That's only part of the problem. Then what do you do with the exception?
Do you have different privilege levels? Stack traces and status
registers so that you can determine what went wrong, repair the damage
and resume execution? And how would you expose that functionality in a
shader language, so that the programmer can make use of the exception
functionality?

> <
> This, however, fails in GPGPU applications, so it provides no insight
> en the large.

How does it fail (compared to running a GLSL shader for instance)?

>>
>> What's more - such support would most likely /get in the way/ for
>> programmers since even fewer than the 6 people that you mentioned
>> earlier would even be remotely interested in such functionality.
>>
>> So the rebellion in me wants to say: "Ask not how hard it is to add
>> floating-point exceptions to a CPU pipeline - ask what the point is
>> of doing so."
> <
> The thing is that memory has exceptions, DIV has exceptions that are
> already present, DECODE may have exceptions, Stores may have late
> exceptions; and once the pipeline has been configured to deal with
> memory and and the others, the infrastructure is already present.
> <
> So I ask:: "Why not" ???

My main argument for the "not" stand point is that it just complicates
the situation for programmers. Nobody wants floating-point exceptions,
and even fewer understands them, but yet we all get to deal with them.

I don't know how many months of my career I have spent on FPU
configuration issues, but they have all been about ensuring that FPU
features are turned off. For almost all software that I have worked
with the priority order has been:

1. Reproducibility.
2. Performance.
3. Accuracy.

Reproducibility means that the behavior should be the same, regardless
of which machine the software is running on. If one target does not
support a certain feature (such as exceptions) that feature will be
turned off on all targets. An extra complication is when you're
developing a library - you need to take care of preserving the FPU
configuration and state across *all* API call boundaries, so that the
caller of the library is free to set up exception handling etc as it
wishes, without interfering with how the library works, and without the
library interfering with how the caller application works.

Performance usually means that exceptions are off the table (as are
subnormals - if any of the target platforms has a performance penalty
when subnormals are enabled).

Accuracy comes in at a distant third place, as most of the applications
I work with either use physical data as input (and that data is already
subject to measurement errors), or they produce results that only need
to be convincing or pleasing to an observer. In any case, if a floating-
point value is rounded or if a value is flushed to zero (underflow), so
be it. *If* accuracy is an issue - switch up from single precision to
double-precision. If you're already on double-precision, redesign your
algorithms (use a more suitable solver etc).

Yes, exceptions are only part of the problem (rounding modes and
subnormals are the other main parts), but my point is that all they have
ever done for me as a software developer is to cause problems & bugs,
and they have cost me many many hours that I would rather have spent on
more productive things.

Oh, and my second argument would be that by implementing floating-point
exceptions you are acknowledging parts of the standard that simply
should not be. (again - this is the little rebellion in me talking)

> <
> It is only when you can get rid of memory exceptions that you can get
> rid of the pipeline infrastructure. {On the other hand this is already a
> "solved problem" in computer design, so it is not perceived as even
> hard, just work.

This is probably why some DSP:s use sticky bits instead of traps for
floating-point exceptions: They don't have memory exceptions.

>>
>> /Marcus

On 2021-07-22 08:48, Thomas Koenig wrote:
> Marcus <m.delete@this.bitsnbites.eu> schrieb:
>
>> Plus (and this is the kicker IMO): If your code *relies* on certain
>> floating-point exceptions to be enabled, you would have to make sure
>> that they are. In a library function this means that you would have to
>> push the current FPU configuration, set up your desired FPU
>> configuration, and at the function exit pop the FPU configuration of the
>> caller.
>
> This is exactly the model that Fortran follows if you use its IEEE
> features (and they are supported).
>
> https://j3-fortran.org/doc/year/18/18-007r1.pdf , clause 17, has all
> the gory details.

Thanks for the reference.

>
> You can change things like the underflow, halting or rounding mode
> on entry to a procedure, but all the chapters specify that "the
> processor shall not change the XXX mode on entry, and on return
> shall ensure that the XXX mode is the same as it was on entry". >
>> This can get really messy if you also have to push/pop the exception
>> handler (in case of trapping HW), or preserve old exception state (in
>> case of HW with sticky flags). And also - how would you propagate
>> legitimate exceptions to the caller (if the caller has enabled
>> exceptions, it may be expecting to get exceptions from the library
>> call)?
>
> Fortran has no model of exceptions except for the IEEE ones.
>
> If you want to see what IEEE support in a programming language
> could look like, I think the draft Fortran standard is a good text
> to look at.
>

So things seem to be well covered in Fortran land.

BTW, one of my favorite war stories has to do with how a particular
virus killer on a particular machine managed to re-configure the FPU
control register in our process. It took me several weeks (IIRC) to
track down that bug (the only machine that could reproduce the bug was
400 km away and I had to use FTP & RDP over a 64kbit line to deploy and
debug the software). Anyway, I would assume that not even Fortran would
be immune to such errors.

Back in C++ land I've developed a "scoped FPU configuration" class
that's about 200 LOC (+200 LOC unit tests), littered with ifdefs,
compiler specific intrinsics and assembly language for different CPU
architectures. And if you forget to instantiate that class at the
start of a single API call, ...

In C the situation would be even worse (because you wouldn't have RAII).

So, just saying: the problem is real. Floating-point exceptions have a
cost that extends way beyond hardware support - language designers and
implementers as well as software developers *have* to deal with them,
at a non-zero cost.

/Marcus

Michael S wrote:
> On Wednesday, July 21, 2021 at 11:15:48 PM UTC+3, Stefan Monnier wrote:
>>> For instance, the very notion of floating-point exceptions (be they
>>> exact HW traps, inexact "something went wrong" traps, or sticky flags
>>> that you can poll, or something else) requires that you can make some
>>> use of them - for instance take some corrective action in software,
>>> using means that usually depend on the programming language.
>> I always assumed (for no concrete reason) that the main users of those
>> flags are very special-purpose code such as the implementation of the
>> `sin` or `atan` functions, or the implementation of 128bit floats
>> primitives on top of 64bit float hardware ops, ...
>>
>>
>> Stefan
>
> I very certain that exceptions do not help sin or atan.
> I am only like 95% certain that exceptions don't help your second case,
> but I am not aware of environments that do anything like that in practice.
>
I know that directed rounding can help for NR-style sqrt() code, i.e. I
believe Alpha saved a final iteration by judicious use of directed
rounding in one of the final stages.

Personally I want my HW to support both, i.e. rounding modes are part of
the opcode, with one option (the default?) being "use the current system
default", i.e. the only option on x87.

This makes the global rounding mode a serializing resource unless you
rename it.

Terje

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

On Wednesday, July 21, 2021 at 6:19:25 PM UTC+1, EricP wrote:

> It seems to me that the initial cost of adding a precise exception to
> that is 1 bit in the uOp along with the result.

.... which has to propagate across all instructions issued from that point...
(therefore you need a Shadow *Matrix* not a Shadow Vector...)
> When the uOp reaches
> write-back, WB sees the exception flag and inhibits the register write,

.... of *all* downstream instructions issued after the one that has
the exception flag....

> and diddles a wire that flushes the pipeline the same as an
> indirect branch,

....termed "Go Die"... (see diagram)

https://libre-soc.org/3d_gpu/shadow.svg

> and jams an unconditional jump IP into the fetch unit,
> which jams an "I'm an exception" uOp into the pipeline,
> and starts fetching from the new address.

just like any other "trap" or "illegal instruction": store some
state (at least the PC) and go.
> In short, most of the logic is already present to handle
> indirect branches so the initial cost is a few gates and a long wire.

wires plural. unless you are happy to stall after the first possible
instruction that could throw an exception.

do you want to have the instruction that *causes* the exception
to be cancelled, but the ones that were issued after it be allowed
to proceed and thus "damage" memory and regfiles just as badly
as if the exception itself was unnoticed? if so, use just one wire.
if not, it has to be one long wire per instruction that's permitted
to run ahead.

it's also how you can do Precise Exceptions on LD/ST, Write-after-Write
Hazard avoidance, Multi-issue, Predication, and also as you say
Branch speculation: it's all the same logic.

why is it all the same logic?

because all of those can create "damage" if allowed to proceed, therefore
the "writing" phase has to be held back, and that hold-back has to be
"cascaded"

l.

On Thursday, July 22, 2021 at 1:31:31 AM UTC+1, Stephen Fuld wrote:

> Without in any way deprecating your experience, which is much greater
> than mine, it seems to be oriented toward the kinds of situations where
> errors are "contained" either in space or time. E.g. if an audio DSP
> messes up, it probably won't be noticed by the vast majority of users,
> and in any event, its effect will be gone in a small fraction of a second.

ohh trust me, it will be noticed (i worked for CEDAR Audio for 18 months,
early in my career).

an overflow of a single audio sample is equivalent to a transient high-frequency
spike. the change can be so large that it can cause Power Amplifiers to
overload, which in turn amplifies the distortion, which in turn results in a higher
rate of change to the speaker coils, which in turn creates not just excessive
heating of the speaker coil it also drives them beyond the physical material
characteristics, causing the driver cone in some cases to rip apart or even
explode.

you REALLY do not want random transient artefacts introduced into audio.
the best worst-case case behaviour is to "saturate" (to min/max) which results
in clipping, but at least it does not result in trying to drive the speaker one way
in under 0.025 milliseconds and then drive it back the other way again.

even a 1 Watt speaker driven to full distortion overload can put out over 96 dB
in the high frequency range, which is more than enough to create lasting hearing
damage if sustained.

l.

On 7/22/2021 6:05 AM, luke.l...@gmail.com wrote:
> On Thursday, July 22, 2021 at 1:31:31 AM UTC+1, Stephen Fuld wrote:
>
>> Without in any way deprecating your experience, which is much greater
>> than mine, it seems to be oriented toward the kinds of situations where
>> errors are "contained" either in space or time. E.g. if an audio DSP
>> messes up, it probably won't be noticed by the vast majority of users,
>> and in any event, its effect will be gone in a small fraction of a second.
>
> ohh trust me, it will be noticed (i worked for CEDAR Audio for 18 months,
> early in my career).
>
> an overflow of a single audio sample is equivalent to a transient high-frequency
> spike. the change can be so large that it can cause Power Amplifiers to
> overload, which in turn amplifies the distortion, which in turn results in a higher
> rate of change to the speaker coils, which in turn creates not just excessive
> heating of the speaker coil it also drives them beyond the physical material
> characteristics, causing the driver cone in some cases to rip apart or even
> explode.
>

For most smaller speakers, it tends to just result in fairly loud and
obvious pops. Eliminating these sorts of pops are one of the more
annoying aspects of working with audio.

> you REALLY do not want random transient artefacts introduced into audio.
> the best worst-case case behaviour is to "saturate" (to min/max) which results
> in clipping, but at least it does not result in trying to drive the speaker one way
> in under 0.025 milliseconds and then drive it back the other way again.
>

Yeah, this is fairly standard practice.

> even a 1 Watt speaker driven to full distortion overload can put out over 96 dB
> in the high frequency range, which is more than enough to create lasting hearing
> damage if sustained.
>

Pretty much.

It is also kinda funny that a speaker can generate a pop seemingly
somewhat louder than its normal level of audio playback.

Though, the result is that if one goes the PC speaker route, they can
get surprisingly loud results from a small speaker.

Interestingly though, if one uses a bigger speaker as the PC speaker in
a PC (with a current limiting resistor), then the sound is a lot
"softer" than the normal PC speaker. Turns out to not matter much though
as usually about the only time it sees much use is when the bios is
starting.

Mostly came up as an issue in my most recent PC build as apparently
newer PC cases have stopped including speakers, so if one wants one,
they need to supply their own.

luke.l...@gmail.com wrote:
> On Wednesday, July 21, 2021 at 6:19:25 PM UTC+1, EricP wrote:
>
>> It seems to me that the initial cost of adding a precise exception to
>> that is 1 bit in the uOp along with the result.
>
> .... which has to propagate across all instructions issued from that point...
> (therefore you need a Shadow *Matrix* not a Shadow Vector...)

Not for what I'm thinking.

>> When the uOp reaches
>> write-back, WB sees the exception flag and inhibits the register write,
>
> .... of *all* downstream instructions issued after the one that has
> the exception flag....

I haven't read '754 and am going by what x86/x64 basically does as a guide.
So there may be something I have missed.

Fp exceptions are like other faults except the FpStatus register
is updated before exceptions are checked for. If an unmasked exception
is then detected the data register write back is not performed.
If there is no unmasked exception, the result write back is performed.

For an In-Order uArch, the FpStatus register is written at WB like any
other register except the new status bits are OR'd into the FpStatus
rather than overwriting.

Next if the current FpControl register exception mask indicates
there is an unmasked exception, the data register WB is inhibited,
and the exception is triggered, purging the pipeline.

Each calculating FP uOp produces a fp result and 6 FpStatus bits.
If a _potential_ exception occurred, that fp operation is responsible for
producing the correct substitute result in case the exception is masked.
Note that the correct substitute result may depend on flags in the
FpControl register at the time the fp operation reaches WB.

The simplest way to manage FP instructions that explicitly read or write
the FpStatus and FpControl registers is to flush the FP pipelines
before and after those instructions. Faster alternatives are possible,
such as keeping a future version of the FpControl at the front
of the FP pipeline and merging control bits into each queued uOp,
and using those control bits to select the correct substitute result.

>> and diddles a wire that flushes the pipeline the same as an
>> indirect branch,
>
> ....termed "Go Die"... (see diagram)
>
> https://libre-soc.org/3d_gpu/shadow.svg
>
>> and jams an unconditional jump IP into the fetch unit,
>> which jams an "I'm an exception" uOp into the pipeline,
>> and starts fetching from the new address.
>
> just like any other "trap" or "illegal instruction": store some
> state (at least the PC) and go.
>
>> In short, most of the logic is already present to handle
>> indirect branches so the initial cost is a few gates and a long wire.
>
> wires plural. unless you are happy to stall after the first possible
> instruction that could throw an exception.

Yes, 1 wire per different exception IP vector to be stuffed into Fetch.
A priority selector in Fetch is hard wired to choose the signal
from the oldest source, so for example WB detected exceptions
take precedence over Decode detected exceptions.
The chosen wire is used to generate the vector IP.

> do you want to have the instruction that *causes* the exception
> to be cancelled, but the ones that were issued after it be allowed
> to proceed and thus "damage" memory and regfiles just as badly
> as if the exception itself was unnoticed? if so, use just one wire.
> if not, it has to be one long wire per instruction that's permitted
> to run ahead.

I'm talking about normal exceptions in a scalar processor
so all the subsequent instructions are cancelled.
(Vector and register-SIMD or real-SIMD (multiple PE's) have to
sort out reasonable error semantics for each of their own situations.)

There are two kinds of exceptions, faults and traps.

Faults roll back leaving the IP pointing at the faulting
instruction and (mostly) leave registers and memory values unchanged.
I say "mostly" because as noted above, the FpStatus register is
defined as updated before the exception is checked for.

Traps complete the instruction updating the IP and registers and/or memory,
then trigger the exception. Single Step is an example of a trap.

> it's also how you can do Precise Exceptions on LD/ST, Write-after-Write
> Hazard avoidance, Multi-issue, Predication, and also as you say
> Branch speculation: it's all the same logic.
>
> why is it all the same logic?
>
> because all of those can create "damage" if allowed to proceed, therefore
> the "writing" phase has to be held back, and that hold-back has to be
> "cascaded"
>
> l.

Yes, which is part of what the Load Store Queue does -
synchronize instruction Retire with release of its pending store.
An exception cancels all subsequent instructions thus preventing
future stores from reaching Retire.

On Thursday, July 22, 2021 at 11:58:37 AM UTC-5, EricP wrote:
> luke.l...@gmail.com wrote:
> > On Wednesday, July 21, 2021 at 6:19:25 PM UTC+1, EricP wrote:
> >
> >> It seems to me that the initial cost of adding a precise exception to
> >> that is 1 bit in the uOp along with the result.
> >
> > .... which has to propagate across all instructions issued from that point...
> > (therefore you need a Shadow *Matrix* not a Shadow Vector...)
> Not for what I'm thinking.
> >> When the uOp reaches
> >> write-back, WB sees the exception flag and inhibits the register write,
> >
> > .... of *all* downstream instructions issued after the one that has
> > the exception flag....
>
> I haven't read '754 and am going by what x86/x64 basically does as a guide.
> So there may be something I have missed.
>
> Fp exceptions are like other faults except the FpStatus register
> is updated before exceptions are checked for.
<
This sounds dangerous. You should not be updating visible state until
writeback. What you can do is to carry this information along with the
result and deal with it all at writeback.
<
> If an unmasked exception
> is then detected the data register write back is not performed.
> If there is no unmasked exception, the result write back is performed.
>
> For an In-Order uArch, the FpStatus register is written at WB like any
> other register except the new status bits are OR'd into the FpStatus
> rather than overwriting.
>
> Next if the current FpControl register exception mask indicates
> there is an unmasked exception, the data register WB is inhibited,
> and the exception is triggered, purging the pipeline.
<
Only younger instructions are flushed. There may still be older instructions
that still need to complete.
>
> Each calculating FP uOp produces a fp result and 6 FpStatus bits.
<
And probably another 5-8 bits so everything can be deferred until
writeback.
<
> If a _potential_ exception occurred, that fp operation is responsible for
> producing the correct substitute result in case the exception is masked.
<
The easiest way to ensure this is to sent the FpConrol stuff to the FU
(as an operand) so that if an exception needs to be raised, FU can
determine what is the appropriate result.
<
> Note that the correct substitute result may depend on flags in the
> FpControl register at the time the fp operation reaches WB.
>
> The simplest way to manage FP instructions that explicitly read or write
> the FpStatus and FpControl registers is to flush the FP pipelines
> before and after those instructions. Faster alternatives are possible,
> such as keeping a future version of the FpControl at the front
> of the FP pipeline and merging control bits into each queued uOp,
> and using those control bits to select the correct substitute result.
> >> and diddles a wire that flushes the pipeline the same as an
> >> indirect branch,
> >
> > ....termed "Go Die"... (see diagram)
> >
> > https://libre-soc.org/3d_gpu/shadow.svg
> >
> >> and jams an unconditional jump IP into the fetch unit,
> >> which jams an "I'm an exception" uOp into the pipeline,
> >> and starts fetching from the new address.
> >
> > just like any other "trap" or "illegal instruction": store some
> > state (at least the PC) and go.
> >
> >> In short, most of the logic is already present to handle
> >> indirect branches so the initial cost is a few gates and a long wire.
> >
> > wires plural. unless you are happy to stall after the first possible
> > instruction that could throw an exception.
<
> Yes, 1 wire per different exception IP vector to be stuffed into Fetch.
> A priority selector in Fetch is hard wired to choose the signal
> from the oldest source, so for example WB detected exceptions
> take precedence over Decode detected exceptions.
> The chosen wire is used to generate the vector IP.
<
This selection process needs to occur the cycle before the FETCH of the
exception vector is performed. Sometimes this is easier orchestrated
in the DECODE stage than in the fetch stage (because DECODE has the
branch target adder whereas the FETCH stage only has an incrementer).
<
> > do you want to have the instruction that *causes* the exception
> > to be cancelled, but the ones that were issued after it be allowed
> > to proceed and thus "damage" memory and regfiles just as badly
> > as if the exception itself was unnoticed? if so, use just one wire.
> > if not, it has to be one long wire per instruction that's permitted
> > to run ahead.
> I'm talking about normal exceptions in a scalar processor
> so all the subsequent instructions are cancelled.
> (Vector and register-SIMD or real-SIMD (multiple PE's) have to
> sort out reasonable error semantics for each of their own situations.)
>
> There are two kinds of exceptions, faults and traps.
>
> Faults roll back leaving the IP pointing at the faulting
> instruction and (mostly) leave registers and memory values unchanged.
> I say "mostly" because as noted above, the FpStatus register is
> defined as updated before the exception is checked for.
>
> Traps complete the instruction updating the IP and registers and/or memory,
> then trigger the exception. Single Step is an example of a trap.
<
My 66000 integrated these into a single concept. In both cases the IP is
left pointing at the offending instruction. One can return from exception
and replay the excepting instruction or one can return from trap and skip
over the instruction. Leaving the IP pointing at the instruction allows
the trap handler to look at the instruction for work qualification. Both
IP and the actual instruction-specifier are available to the handler, as
are operands to the instruction.
<
> > it's also how you can do Precise Exceptions on LD/ST, Write-after-Write
> > Hazard avoidance, Multi-issue, Predication, and also as you say
> > Branch speculation: it's all the same logic.
> >
> > why is it all the same logic?
> >
> > because all of those can create "damage" if allowed to proceed, therefore
> > the "writing" phase has to be held back, and that hold-back has to be
> > "cascaded"
> >
> > l.
<
> Yes, which is part of what the Load Store Queue does -
> synchronize instruction Retire with release of its pending store.
> An exception cancels all subsequent instructions thus preventing
> future stores from reaching Retire.

On Wednesday, July 21, 2021 at 8:35:40 AM UTC-6, John Dallman wrote:
> In article <sd9a9h$ro6$1...@dont-email.me>, m.de...@this.bitsnbites.eu
> (Marcus) wrote:

> > In our software we do the same thing (even disabling subnormals)
> > in order to normalize on the least common denominator, so to say
> > (as soon as one target platform lacks a feature, it needs to be
> > disabled on _all_ platforms).

> We're willing to try to make use of useful features of particular
> platforms.

What he is doing may make perfect sense if his firm is engaged in
supporting a wide variety of platforms, and in order to do this at a
manageable cost, needs to ensure that its software is highly
portable.

So I can't criticize him for doing it that way, even if this might not
be a way of doing things that would ever occur to me in my
situation.

My habits were formed in the good old days, when software was
written for one particular platform, with no thought that anybody
would ever want to use it anywhere else.

John Savard

On Thursday, July 22, 2021 at 4:59:34 PM UTC-5, Quadibloc wrote:
> On Wednesday, July 21, 2021 at 8:35:40 AM UTC-6, John Dallman wrote:
> > In article <sd9a9h$ro6$1...@dont-email.me>, m.de...@this.bitsnbites.eu
> > (Marcus) wrote:
>
> > > In our software we do the same thing (even disabling subnormals)
> > > in order to normalize on the least common denominator, so to say
> > > (as soon as one target platform lacks a feature, it needs to be
> > > disabled on _all_ platforms).
<
The intent expressed here is the contrapositive of what IEEE 754 intended.
<
> > We're willing to try to make use of useful features of particular
> > platforms.
<
Do all platforms have a way of converting denorm operands into zero ?
Do all platforms have a way to suppress the creation of denorm results ?
......and return zero instead ?
<
> What he is doing may make perfect sense if his firm is engaged in
> supporting a wide variety of platforms, and in order to do this at a
> manageable cost, needs to ensure that its software is highly
> portable.
>
> So I can't criticize him for doing it that way, even if this might not
> be a way of doing things that would ever occur to me in my
> situation.
>
> My habits were formed in the good old days, when software was
> written for one particular platform, with no thought that anybody
> would ever want to use it anywhere else.
<
Your age is showing...........
>
> John Savard

On 2021-07-23 01:14, MitchAlsup wrote:
> On Thursday, July 22, 2021 at 4:59:34 PM UTC-5, Quadibloc wrote:
>> On Wednesday, July 21, 2021 at 8:35:40 AM UTC-6, John Dallman wrote:
>>> In article <sd9a9h$ro6$1...@dont-email.me>, m.de...@this.bitsnbites.eu
>>> (Marcus) wrote:
>>
>>>> In our software we do the same thing (even disabling subnormals)
>>>> in order to normalize on the least common denominator, so to say
>>>> (as soon as one target platform lacks a feature, it needs to be
>>>> disabled on _all_ platforms).
> <
> The intent expressed here is the contrapositive of what IEEE 754 intended.

I agree. I tried approaching the IEEE 754 working group [1] with a
suggestion to standardize a leaner subset of the current standard that
would better acknowledge the current reality (i.e. that many floating-
point implementations lack some of the mandatory IEEE 754 features),
and to analyze the effects of such implementations w.r.t. the numerical
and operational guarantees that the standard aims to provide. At least
to preempt an explosion of fragmented, non-conforming implementations.

To no avail...

> <
>>> We're willing to try to make use of useful features of particular
>>> platforms.
> <
> Do all platforms have a way of converting denorm operands into zero ?
> Do all platforms have a way to suppress the creation of denorm results ?
> .....and return zero instead ?
> <

Based on the platforms that I have worked with: Yes & yes (possibly
excluding x87, which is a different story altogether). Some implicitly
do this as the only way of operation (e.g. ARMv7 NEON, TI C66x), while
others provide a configuration or two (e.g. x86 SSE/AVX, ARMv8 NEON,
POWER).

There are surely platforms where you can't enforce that behavior, but I
have not yet used/programmed such CPU:s (IIRC RISC-V has no such
option, for instance).

The most dodgy ISA specification in this regard that I have come across
is actually the POWER ISA. It has a "non-IEEE mode"-flag in the FPSCR
register that essentially activates unpredictable behavior (e.g. "in
non-IEEE mode an implementation _may_ return 0 instead of a
denormalized number").

You may be surprised by how much of the currently running software in
the world runs with denorms-are-zero & flush-to-zero semantics. For
instance the Intel C/Fortran compilers disable subnormals as soon as
you turn on optimizations. GCC and Clang do the same when you use
-ffast-math (_lots_ of performance sensitive programs do this! [2]).
D3D11 single precision has this as the specified behavior. The GLSL
and OpenCL specifications leave it as an implementation detail. Etc...

/Marcus

[1]
https://listserv.ieee.org/cgi-bin/wa?A1=ind20&L=STDS-754&X=O049A572CEC0474BAF0&Y=m%40bitsnbites.eu#23
[2] https://github.com/search?q=%22-ffast-math%22&type=code

On 7/23/2021 3:46 AM, Marcus wrote:
> On 2021-07-23 01:14, MitchAlsup wrote:
>> On Thursday, July 22, 2021 at 4:59:34 PM UTC-5, Quadibloc wrote:
>>> On Wednesday, July 21, 2021 at 8:35:40 AM UTC-6, John Dallman wrote:
>>>> In article <sd9a9h$ro6$1...@dont-email.me>, m.de...@this.bitsnbites.eu
>>>> (Marcus) wrote:
>>>
>>>>> In our software we do the same thing (even disabling subnormals)
>>>>> in order to normalize on the least common denominator, so to say
>>>>> (as soon as one target platform lacks a feature, it needs to be
>>>>> disabled on _all_ platforms).
>> <
>> The intent expressed here is the contrapositive of what IEEE 754
>> intended.
>
> I agree. I tried approaching the IEEE 754 working group [1] with a
> suggestion to standardize a leaner subset of the current standard that
> would better acknowledge the current reality (i.e. that many floating-
> point implementations lack some of the mandatory IEEE 754 features),
> and to analyze the effects of such implementations w.r.t. the numerical
> and operational guarantees that the standard aims to provide. At least
> to preempt an explosion of fragmented, non-conforming implementations.
>
> To no avail...
>
>> <
>>>> We're willing to try to make use of useful features of particular
>>>> platforms.
>> <
>> Do all platforms have a way of converting denorm operands into zero ?
>> Do all platforms have a way to suppress the creation of denorm results ?
>> .....and return zero instead ?
>> <
>
> Based on the platforms that I have worked with: Yes & yes (possibly
> excluding x87, which is a different story altogether). Some implicitly
> do this as the only way of operation (e.g. ARMv7 NEON, TI C66x), while
> others provide a configuration or two (e.g. x86 SSE/AVX, ARMv8 NEON,
> POWER).
>
> There are surely platforms where you can't enforce that behavior, but I
> have not yet used/programmed such CPU:s (IIRC RISC-V has no such
> option, for instance).
>
> The most dodgy ISA specification in this regard that I have come across
> is actually the POWER ISA. It has a "non-IEEE mode"-flag in the FPSCR
> register that essentially activates unpredictable behavior (e.g. "in
> non-IEEE mode an implementation _may_ return 0 instead of a
> denormalized number").
>
> You may be surprised by how much of the currently running software in
> the world runs with denorms-are-zero & flush-to-zero semantics. For
> instance the Intel C/Fortran compilers disable subnormals as soon as
> you turn on optimizations. GCC and Clang do the same when you use
> -ffast-math (_lots_ of performance sensitive programs do this! [2]).
> D3D11 single precision has this as the specified behavior. The GLSL
> and OpenCL specifications leave it as an implementation detail. Etc...
>
> /Marcus
>
> [1]
> https://listserv.ieee.org/cgi-bin/wa?A1=ind20&L=STDS-754&X=O049A572CEC0474BAF0&Y=m%40bitsnbites.eu#23
>
> [2] https://github.com/search?q=%22-ffast-math%22&type=code

Denorms, rounding modes, exceptions, and other IEEE features are there
to support algorithms for which stability is an issue. Rotating a view
in a game is not concerned with algorithmic stability; N-body
gravitational modeling is concerned. Some people care if the moon lander
lands on the moon surface, or ten meters above or below it.

On Thursday, July 22, 2021 at 5:14:22 PM UTC-6, MitchAlsup wrote:

> Do all platforms have a way of converting denorm operands into zero ?
> Do all platforms have a way to suppress the creation of denorm results ?
> .....and return zero instead ?

If not, then there's no practical way to "disable" gradual underflow on
those platforms to make them compatible with those that aren't.

Of course, why _that_ level of compatibility is important is unclear.

After all, FORTRAN programs were regarded as 'transportable' if
they would run without error on platforms with wildly differing
floating-point formats; that they might yield slightly different numerical
results was not seen as an issue.

John Savard

On Friday, July 23, 2021 at 4:46:33 AM UTC-6, Marcus wrote:

> I agree. I tried approaching the IEEE 754 working group [1] with a
> suggestion to standardize a leaner subset of the current standard that
> would better acknowledge the current reality (i.e. that many floating-
> point implementations lack some of the mandatory IEEE 754 features),
> and to analyze the effects of such implementations w.r.t. the numerical
> and operational guarantees that the standard aims to provide. At least
> to preempt an explosion of fragmented, non-conforming implementations.

> To no avail...

I can see why there would be issues.

The characteristics of the "leaner subset" would depend *strongly* on
the level of the implementation.

Thus, for the kind of floating-point arithmetic unit I might prefer, the
leaner subset would have these characteristics:

- Denormals would work. What would not guarantee is that they
would *fail* when they were supposed to.

- Accurate rounding would be guaranteed for addition, subtraction,
and multiplication, but *not* division, which would instead be accurate
to something like 0.6 or 0.51 units in the last place.

That's because I would want to implement division using one of the
fast algorithms which require significant additional overhead to get
accurate rounding...

and I intend to support denormals with no loss in speed by converting
floats to a format with no hidden bit inside registers, so it would be
extra work to reproduce the exact numerical range and precision of
the IEEE 754 floating-point format. Instead, the denormals - and some
numeric range beyond them - would still have full precision, and only
get rounded down when it came time to store values in memory.

People implementing floating-point in a *different* manner would have
entirely different choices for what parts of the IEEE 754 standard they
would want omitted from a 'leaner subset'. An implementation with
significantly less hardware would omit the entire denormal range, but
support exact rounding for division, for example.

So there's a 'lightweight' leaner subset, and there's a 'high-performance'
leaner subset, at the very least. Which are disjoint rather than one being
a subset of the other.

John Savard

On Friday, July 23, 2021 at 4:54:17 AM UTC-6, Ivan Godard wrote:
> Some people care if the moon lander
> lands on the moon surface, or ten meters above or below it.

That's definitely a good thing to care about.

Does the fancy stuff in IEEE 754 really help with that?

Or would doing everything in double precision, even if one
were using something like the old System/360 floating
format, do a better job?

Accurate and reliable calculations by computers are a very
important thing. How much the approach taken by IEEE 754
contributes to that goal, let alone the more elaborate notions
presented by people like John Gustavson, is, however, an open
question, I would think.

John Savard

On 7/23/2021 5:19 AM, Quadibloc wrote:
> On Friday, July 23, 2021 at 4:54:17 AM UTC-6, Ivan Godard wrote:
>> Some people care if the moon lander
>> lands on the moon surface, or ten meters above or below it.
>
> That's definitely a good thing to care about.
>
> Does the fancy stuff in IEEE 754 really help with that?
>
> Or would doing everything in double precision, even if one
> were using something like the old System/360 floating
> format, do a better job?
>
> Accurate and reliable calculations by computers are a very
> important thing. How much the approach taken by IEEE 754
> contributes to that goal, let alone the more elaborate notions
> presented by people like John Gustavson, is, however, an open
> question, I would think.
>
> John Savard
>

Back when I was active on the IEEE committee, I once asked Kahan
whether, if quad (128-bit) were as fast as double, would he still have
denorms. He answered an unequivocal "No!".

On Friday, July 23, 2021 at 7:19:30 AM UTC-5, Quadibloc wrote:
> On Friday, July 23, 2021 at 4:54:17 AM UTC-6, Ivan Godard wrote:
> > Some people care if the moon lander
> > lands on the moon surface, or ten meters above or below it.
> That's definitely a good thing to care about.
>
> Does the fancy stuff in IEEE 754 really help with that?
<
Numerical stability has a LOT more to do with algorithm choice than
the underlying FP arithmetic.
>
> Or would doing everything in double precision, even if one
> were using something like the old System/360 floating
> format, do a better job?
<
No, doubling the widths just hides the problem and makes the actual
problem harder to find. You can take the point of view that that is
enough, but it is not in reality.
>
> Accurate and reliable calculations by computers are a very
> important thing. How much the approach taken by IEEE 754
> contributes to that goal, let alone the more elaborate notions
> presented by people like John Gustavson, is, however, an open
> question, I would think.
<
IEEE 754 was put together by people who really understood FP arithmetic
but HW not so much.
>
> John Savard

On Friday, July 23, 2021 at 9:30:20 AM UTC-6, MitchAlsup wrote:

> IEEE 754 was put together by people who really understood FP arithmetic
> but HW not so much.

My own very limited understanding of hardware was put to use
in my reply to Marcus' comment about the need for a "leaner
subset" of IEEE 754; I noted that if one were designing a large
system aiming at the fastest possible speed, one would want
to leave _certain_ features of IEEE 754 out, whereas if one were
designing a really tiny system, one would want to leave *different*
features out... which was probably too much to ask, thus
skewering any hopes of adding such a subset to the standard.

Since IEEE 754, in its original form, simply ratified what Intel
had planned to include in its forthcoming (but then secret)
8087, though, a knowledge of hardware certainly was...
applied... to its contents, even if the committee that signed
off on it did not include hardware experts.

And what I see, then, as the issue would be...

The fact that IEEE 754 derived from Intel's 8087 work meant that
the standard was capable of being implemented in hardware once.

Of course, that meant that it was implementable many times in
other systems *of comparable size*.

But denormals were a pain in very small systems... and the
requirement for perfect rounding was a pain in larger systems
that aimed at the highest possible speed using either Goldschmidt
or Newton-Raphson for division.

So that's where I see that having HW knowleldge on the IEEE
754 committee would have helped. With your much greater
knowledge of hardware, you may see other things which are
more important than what I thought of.

John Savard

On Friday, July 23, 2021 at 9:30:20 AM UTC-6, MitchAlsup wrote:

> No, doubling the widths just hides the problem and makes the actual
> problem harder to find. You can take the point of view that that is
> enough, but it is not in reality.

It's enough to get one Moon lander on the surface. But solving the
real problem is still better - but it's nice if there's a way to meet
deadlines and the like.

John Savard

On Friday, July 23, 2021 at 12:43:25 PM UTC-5, Quadibloc wrote:
> On Friday, July 23, 2021 at 9:30:20 AM UTC-6, MitchAlsup wrote:
>
> > IEEE 754 was put together by people who really understood FP arithmetic
> > but HW not so much.
<
> My own very limited understanding of hardware was put to use
> in my reply to Marcus' comment about the need for a "leaner
> subset" of IEEE 754; I noted that if one were designing a large
> system aiming at the fastest possible speed, one would want
> to leave _certain_ features of IEEE 754 out, whereas if one were
> designing a really tiny system, one would want to leave *different*
> features out... which was probably too much to ask, thus
> skewering any hopes of adding such a subset to the standard.
>
> Since IEEE 754, in its original form, simply ratified what Intel
> had planned to include in its forthcoming (but then secret)
> 8087, though, a knowledge of hardware certainly was...
> applied... to its contents, even if the committee that signed
> off on it did not include hardware experts.
<
IEEE 754 had to compromise between x87 and 881 the intel
and Moto chips both nearing tapeout, one maybe as far along
as having seen silicon. This is the part about when rounding versus
normalization transpires.
>
> And what I see, then, as the issue would be...
>
> The fact that IEEE 754 derived from Intel's 8087 work meant that
> the standard was capable of being implemented in hardware once.
<
Remember that an FADD was 84-240 cycles..........but I digress......
>
> Of course, that meant that it was implementable many times in
> other systems *of comparable size*.
>
> But denormals were a pain in very small systems... and the
> requirement for perfect rounding was a pain in larger systems
> that aimed at the highest possible speed using either Goldschmidt
> or Newton-Raphson for division.
<
Having watched this from inside:
a) HW designers know a lot more about this today than in 1980
b) even systems that started out as IEEE-format gradually went
closer and closer to full IEEE-compliant (GPUs) until there is no
useful difference in the quality of the arithmetic.
c) once 754-2009 came out the overhead to do denorms went to
zero, and there is no reason to avoid full speed denorms in practice.
(BGB's small FPGA prototyping environment aside.)
d) HW designers have learned how to perform all of the rounding
modes at no overhead compared to RNE.
>
> So that's where I see that having HW knowleldge on the IEEE
> 754 committee would have helped. With your much greater
> knowledge of hardware, you may see other things which are
> more important than what I thought of.
>
> John Savard

Ivan Godard <ivan@millcomputing.com> writes:
>Back when I was active on the IEEE committee, I once asked Kahan
>whether, if quad (128-bit) were as fast as double, would he still have
>denorms. He answered an unequivocal "No!".

That is hard to believe, given that a major argument for denormal
numbers is that

a-b=0

should give the same result as

a=b

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