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

Groups > comp.arch > #114813 > unrolled thread

Combining Practicality with Perfection

Back to article view | Back to comp.arch

Contents

  Combining Practicality with Perfection John Savard <quadibloc@invalid.invalid> - 2026-01-31 18:28 +0000
    Re: Combining Practicality with Perfection jgd@cix.co.uk (John Dallman) - 2026-01-31 22:36 +0000
    Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-05 01:57 +0000
      Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-05 06:06 +0000
        Re: Combining Practicality with Perfection Robert Finch <robfi680@gmail.com> - 2026-02-05 08:10 -0500
        Re: Combining Practicality with Perfection scott@slp53.sl.home (Scott Lurndal) - 2026-02-05 14:50 +0000
        Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-05 23:58 +0000
          Re: Combining Practicality with Perfection jgd@cix.co.uk (John Dallman) - 2026-02-06 16:37 +0000
            Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-06 22:32 +0000
              Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-06 22:34 +0000
              Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-07 00:57 +0000
                Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-07 02:45 +0000
            Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-06 22:40 +0000
          Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-09 22:46 +0000
            Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-10 03:49 +0000
              Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-10 19:10 +0000
                Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-11 23:04 +0000
                  Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-11 23:55 +0000
                    Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-12 06:04 +0000
                    Re: Combining Practicality with Perfection quadibloc@invalid.com (John Savard) - 2026-10-24 00:22 +0000
                      Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-24 19:32 +0000
                      Re: Combining Practicality with Perfection jgd@cix.co.uk (John Dallman) - 2026-10-25 06:00 +0000
                        Re: Combining Practicality with Perfection quadibloc@invalid.com (John Savard) - 2026-10-25 17:38 +0000
                          Re: Combining Practicality with Perfection Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-10-25 22:43 -0700
                          Re: Combining Practicality with Perfection jgd@cix.co.uk (John Dallman) - 2026-10-26 09:35 +0000
                            Re: Combining Practicality with Perfection John Levine <johnl@taugh.com> - 2026-10-26 19:53 +0000
                          Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-26 13:40 +0000
                            Re: Combining Practicality with Perfection quadibloc@invalid.com (John Savard) - 2026-10-26 22:05 +0000
                              Re: Combining Practicality with Perfection quadibloc@invalid.com (John Savard) - 2026-10-26 22:12 +0000
                              Re: Combining Practicality with Perfection Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-10-26 20:13 -0700
                                Re: Combining Practicality with Perfection quadibloc@invalid.com (John Savard) - 2026-10-27 14:30 +0000
                            Re: Combining Practicality with Perfection quadibloc@invalid.com (John Savard) - 2026-10-26 22:09 +0000
                              Re: Combining Practicality with Perfection EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-26 18:20 -0400
                                Re: Combining Practicality with Perfection quadibloc@invalid.com (John Savard) - 2026-10-27 03:00 +0000
                          Re: Combining Practicality with Perfection antispam@fricas.org (Waldek Hebisch) - 2026-10-26 22:51 +0000
                        Re: Combining Practicality with Perfection John Levine <johnl@taugh.com> - 2026-10-25 18:47 +0000
                  Re: Combining Practicality with Perfection David Schultz <david.schultz@earthlink.net> - 2026-02-11 17:57 -0600
                    Re: Combining Practicality with Perfection John Levine <johnl@taugh.com> - 2026-02-12 00:04 +0000
                      Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-12 02:04 +0000
                        Re: Combining Practicality with Perfection John Levine <johnl@taugh.com> - 2026-02-12 03:31 +0000
                          Hex floating point (was: Combining Practicality with Perfection) Thomas Koenig <tkoenig@netcologne.de> - 2026-02-15 16:53 +0000
                        Re: Combining Practicality with Perfection anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-12 08:45 +0000
                          Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-12 17:09 +0000
                            Re: Combining Practicality with Perfection Terje Mathisen <terje.mathisen@tmsw.no> - 2026-02-14 18:03 +0100
                            Re: Combining Practicality with Perfection BGB <cr88192@gmail.com> - 2026-02-19 02:10 -0600
                              Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-19 17:30 +0000
                                Re: Combining Practicality with Perfection Michael S <already5chosen@yahoo.com> - 2026-02-19 20:15 +0200
                                  Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-19 19:55 +0000
                                Re: Combining Practicality with Perfection BGB <cr88192@gmail.com> - 2026-02-20 05:08 -0600
                                  Re: Combining Practicality with Perfection Terje Mathisen <terje.mathisen@tmsw.no> - 2026-02-20 15:22 +0100
                                    Re: Combining Practicality with Perfection BGB <cr88192@gmail.com> - 2026-02-20 15:26 -0600
                                Re: Combining Practicality with Perfection Paul Clayton <paaronclayton@gmail.com> - 2026-02-21 20:27 -0500
                        Re: Combining Practicality with Perfection Michael S <already5chosen@yahoo.com> - 2026-02-12 10:49 +0200
                          Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-12 17:10 +0000
                            Re: Combining Practicality with Perfection Michael S <already5chosen@yahoo.com> - 2026-02-12 23:38 +0200
                        Re: Combining Practicality with Perfection Terje Mathisen <terje.mathisen@tmsw.no> - 2026-02-12 14:28 +0100
                    Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-12 05:51 +0000
                    Re: Combining Practicality with Perfection Michael S <already5chosen@yahoo.com> - 2026-02-12 10:53 +0200
                      Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-12 18:40 +0000
                        Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-12 20:02 +0000
                        Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-12 20:33 +0000
                  Re: Combining Practicality with Perfection Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-02-11 19:50 -0800
                    Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-12 05:55 +0000
                      Re: Combining Practicality with Perfection Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-02-12 08:40 -0800
                        Re: Combining Practicality with Perfection scott@slp53.sl.home (Scott Lurndal) - 2026-02-12 16:51 +0000
                        Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-12 18:49 +0000
                    Re: Combining Practicality with Perfection scott@slp53.sl.home (Scott Lurndal) - 2026-02-12 15:54 +0000
                      Re: Combining Practicality with Perfection Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-02-12 08:52 -0800
                        Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-12 18:37 +0000
                  Re: Combining Practicality with Perfection antispam@fricas.org (Waldek Hebisch) - 2026-02-14 16:33 +0000
                    Re: floating pain, Combining Practicality with Perfection John Levine <johnl@taugh.com> - 2026-02-14 18:12 +0000
                      Re: floating pain, Combining Practicality with Perfection antispam@fricas.org (Waldek Hebisch) - 2026-02-17 01:16 +0000
                        Re: floating pain, Combining Practicality with Perfection John Levine <johnl@taugh.com> - 2026-02-17 01:24 +0000
                          Re: floating pain, Combining Practicality with Perfection antispam@fricas.org (Waldek Hebisch) - 2026-02-17 16:21 +0000
                            Re: floating pain, Combining Practicality with Perfection John Levine <johnl@taugh.com> - 2026-02-17 19:20 +0000
                              Re: floating pain, Combining Practicality with Perfection antispam@fricas.org (Waldek Hebisch) - 2026-02-17 19:52 +0000
                          Re: floating pain, Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-17 19:09 +0000
                    Re: Combining Practicality with Perfection jgd@cix.co.uk (John Dallman) - 2026-02-15 14:37 +0000
                      Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-17 18:57 +0000
                        Re: Combining Practicality with Perfection antispam@fricas.org (Waldek Hebisch) - 2026-02-17 20:43 +0000
                          Re: Combining Practicality with Perfection MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-02-18 00:50 +0000
                          Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-18 08:52 +0000
                            Re: Combining Practicality with Perfection Robert Finch <robfi680@gmail.com> - 2026-02-18 08:40 -0500
                              Re: Combining Practicality with Perfection quadi <quadibloc@ca.invalid> - 2026-02-20 08:14 +0000
                      Re: Combining Practicality with Perfection Thomas Koenig <tkoenig@netcologne.de> - 2026-02-19 18:49 +0000

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

#114996 — Hex floating point (was: Combining Practicality with Perfection)

John Levine <johnl@taugh.com> schrieb:

> Oh I forgot that using hex exponents meant there was no hidden bit, so
> in practice it lost three bits of precision on every operation.  There was
> a great deal of grumbling that people with 709x Fortran codes had to
> make everything double precision to keep getting reasonably good results.

Hacker's Delight phrases this as

"When IBM introduced the System/360 computer in 1964, numerical
analysts were horrified at the loss of precision of single-precision
arithmetic."

and then goes on to show how the distribution of floating point
values effectively reduces the precision of one quarter of floating
point values to 21.  (There's a name for, somebody's law, but it escapes
me at the moment).
-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

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

#114934

MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>{{One can STILL argue whether
>deNormals were a plus or a minus in IEEE}}

I am surprised to read that from you, who has always written that
denormals can be implemented cheaply and efficiently in hardware.  The
additional hardware cost (or the cost of trapping and software
emulation) has been the only argument against denormals that I ever
encountered.

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

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

#114945

anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:

> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> >{{One can STILL argue whether
> >deNormals were a plus or a minus in IEEE}}
> 
> I am surprised to read that from you, who has always written that
> denormals can be implemented cheaply and efficiently in hardware.  The
> additional hardware cost (or the cost of trapping and software
> emulation) has been the only argument against denormals that I ever
> encountered.

It is only after IEEE 754-2008 came with FMAC that deNormals became 
a low cost addition. {And that has been my point--you seem to have
forgotten the -2008 part or the argument}
> 
> - anton

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

#114967

MitchAlsup wrote:
> 
> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> 
>> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>>> {{One can STILL argue whether
>>> deNormals were a plus or a minus in IEEE}}
>>
>> I am surprised to read that from you, who has always written that
>> denormals can be implemented cheaply and efficiently in hardware.  The
>> additional hardware cost (or the cost of trapping and software
>> emulation) has been the only argument against denormals that I ever
>> encountered.
> 
> It is only after IEEE 754-2008 came with FMAC that deNormals became
> a low cost addition. {And that has been my point--you seem to have
> forgotten the -2008 part or the argument}

Not at all forgotten, I just didn't notice that caveat in the current 
discussion. Mea Culpa!

Terje

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

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

#115040

On 2/12/2026 11:09 AM, MitchAlsup wrote:
> 
> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> 
>> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>>> {{One can STILL argue whether
>>> deNormals were a plus or a minus in IEEE}}
>>
>> I am surprised to read that from you, who has always written that
>> denormals can be implemented cheaply and efficiently in hardware.  The
>> additional hardware cost (or the cost of trapping and software
>> emulation) has been the only argument against denormals that I ever
>> encountered.
> 
> It is only after IEEE 754-2008 came with FMAC that deNormals became
> a low cost addition. {And that has been my point--you seem to have
> forgotten the -2008 part or the argument}

And, can note, this is assuming that one actually pays the cost of 
native hardware FMAC.


Well, and the secondary irony that it is mainly cost-added for FMUL, 
whereas FADD almost invariably has the necessary support hardware already.

But:
   FMUL is expensive operation + cheap normalizer (if no denormals);
   FADD is cheap operation with expensive normalizer.

FMAC then is gluing the costs of the two units together, but:
   With roughly the latency of both;
   The need to be significantly wider internally to deal with some cases.

So, FMAC is a single unit that costs more than both units taken 
separately, and with a higher latency.



FMAC does suddenly get a bit cheaper if its scope is limited to 
FP8*FP8+FP16, but this operation is a bit niche.


This one makes a lot of sense for NN's, but haven't gotten my NN tech 
working good enough to make a strong use-case for it.

Where, in terms of algorithmic or behavioral complexity relative to 
computational efficiency, NN's are significantly behind what is possible 
with genetic algorithms or genetic programming.


So, for computational efficiency of the result:
   Hand-written native code, best efficiency;
   Genetic algorithm, moderate efficiency;
   Neural Net, very inefficient.

The merit of NNs could then be if one could make them adaptive in some 
practical way:
   Native code: No adaptation apart from specific algos;
   Genetic algorithms: Only when running the evolver, static otherwise;
   NN's: Could be made adaptable in theory, usually fixed in practice.

And, adaptation process:
   Native: None, maybe manual fiddling by programmer;
   Genetic algo: Initially very slow, gradually converges on answer;
   NNs, via generic algorithm: Slow, but converges toward an answer;
   NNs, via backprop: Rapid adaptation initially, then hits a plateau.

Backprop is seemingly prone to get stuck at a non-optimal solution, and 
then is hard pressed to make any further progress. Seemingly isn't 
really able to "fix" any obvious structural defects once it hits a 
plateau, but can sometimes jump up or down between various nearby 
options (when obvious suboptimal patterns persist).

Some tricks that work with GA-NN's don't really work with backprop, and 
my initial attempts to glue GA handling onto backprop have not been 
effective. Also it seems to need at least FP16 weights for training to 
work effectively (though, one other option being FP8 with a bias 
counter; but this is effectively analogous to using a non-standard 
S.E4.M11 format).


Seemingly, my own efforts are getting stuck at the level of very 
inefficiently solving very mundane issues, nowhere near the success 
being seen by more mainstream efforts.

Nor, as of yet, even anything particularly interesting...



Had started making some progress in other types of areas though, for 
example:
Figured out a practical way to get below 16kbps for audio...

By using 8kHz ADPCM and then using lookup table and reversed LZ search 
trickery to make the audio more LZ compressible (without changing the 
storage format).

Or, basically, ADPCM encoding strategy like:
   Lookup a match for the last 4 bytes;
   Look for the longest backwards match (last N bytes);
   Evaluate if the next byte for pattern is within an error limit;
   Select based on combination of error and length
     Longer matches permit more error than shorter ones.
   Check a pattern table,
     seeing if anything is within an acceptable error limit;
     Use pattern if so.
   Else:
     Figure out best-match for next 6 samples,
     using this to encode next 4 samples (1 byte).

Was able to get around a 20-30% reduction in bitrate, or around 12 kbps 
typical, before loss of audio quality becomes unacceptable (starts 
breaking down in obvious ways).


Did version for 4-bit ADPCM, which can get a roughly similar reduction, 
or around 24 kbps, though trying to push it much lower makes 2-bit ADPCM 
preferable.

A slightly higher reduction rate is possible if the baseline sample-rate 
is increased to 16kHz, but still doesn't get as low as when using 8 kHz.



Note that it is possible to just use a pattern table directly to give an 
equivalent of 8 kbps ADPCM (each byte encoding an index into an 8-sample 
table, which is then decoded as 2-bit ADPCM), but the audio quality is 
unacceptably poor (for much of any use-case).


Though, all this was mostly dusting off an experiment from last year, 
and putting it to use in my packaging tool (inside BGBCC).

Mostly it is a case of:
It is "good enough" to at least allow for optional super-compression of 
ADPCM without breaking the existing decoders.


...



>>
>> - anton

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

#115044

BGB <cr88192@gmail.com> posted:

> On 2/12/2026 11:09 AM, MitchAlsup wrote:
> > 
> > anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> > 
> >> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> >>> {{One can STILL argue whether
> >>> deNormals were a plus or a minus in IEEE}}
> >>
> >> I am surprised to read that from you, who has always written that
> >> denormals can be implemented cheaply and efficiently in hardware.  The
> >> additional hardware cost (or the cost of trapping and software
> >> emulation) has been the only argument against denormals that I ever
> >> encountered.
> > 
> > It is only after IEEE 754-2008 came with FMAC that deNormals became
> > a low cost addition. {And that has been my point--you seem to have
> > forgotten the -2008 part or the argument}
> 
> And, can note, this is assuming that one actually pays the cost of 
> native hardware FMAC.
> 
It is exceedingly difficult to get an IEEE quality rounded result if
not done in HW.
> 
> Well, and the secondary irony that it is mainly cost-added for FMUL, 
> whereas FADD almost invariably has the necessary support hardware already.
> 
> But:
>    FMUL is expensive operation + cheap normalizer (if no denormals);
>    FADD is cheap operation with expensive normalizer.
> 
> FMAC then is gluing the costs of the two units together, but:
>    With roughly the latency of both;
>    The need to be significantly wider internally to deal with some cases.

The add stage after the multiplication tree is <essentially> 2× as wide.
FMUL needs a 108-bit 2-input adder
FMAC needs a 160-bit 3-input adder and a 52-bit incrementor.
The multiplication tree is the same, normalizer is larger.

> 
> So, FMAC is a single unit that costs more than both units taken 
> separately, and with a higher latency.

Prior RISC processors did FMUL in 3-4 cycles (mostly 4).
Later RISC processors and x86 did FMAC in 4-cycles (occasionally 5).

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

#115045

On Thu, 19 Feb 2026 17:30:50 GMT
MitchAlsup <user5857@newsgrouper.org.invalid> wrote:

> BGB <cr88192@gmail.com> posted:
> 
> > On 2/12/2026 11:09 AM, MitchAlsup wrote:  
> > > 
> > > anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> > >   
> > >> MitchAlsup <user5857@newsgrouper.org.invalid> writes:  
> > >>> {{One can STILL argue whether
> > >>> deNormals were a plus or a minus in IEEE}}  
> > >>
> > >> I am surprised to read that from you, who has always written that
> > >> denormals can be implemented cheaply and efficiently in
> > >> hardware.  The additional hardware cost (or the cost of trapping
> > >> and software emulation) has been the only argument against
> > >> denormals that I ever encountered.  
> > > 
> > > It is only after IEEE 754-2008 came with FMAC that deNormals
> > > became a low cost addition. {And that has been my point--you seem
> > > to have forgotten the -2008 part or the argument}  
> > 
> > And, can note, this is assuming that one actually pays the cost of 
> > native hardware FMAC.
> >   
> It is exceedingly difficult to get an IEEE quality rounded result if
> not done in HW.
> > 
> > Well, and the secondary irony that it is mainly cost-added for
> > FMUL, whereas FADD almost invariably has the necessary support
> > hardware already.
> > 
> > But:
> >    FMUL is expensive operation + cheap normalizer (if no denormals);
> >    FADD is cheap operation with expensive normalizer.
> > 
> > FMAC then is gluing the costs of the two units together, but:
> >    With roughly the latency of both;
> >    The need to be significantly wider internally to deal with some
> > cases.  
> 
> The add stage after the multiplication tree is <essentially> 2× as
> wide. FMUL needs a 108-bit 2-input adder
> FMAC needs a 160-bit 3-input adder and a 52-bit incrementor.
> The multiplication tree is the same, normalizer is larger.
> 
> > 
> > So, FMAC is a single unit that costs more than both units taken 
> > separately, and with a higher latency.  
> 
> Prior RISC processors did FMUL in 3-4 cycles (mostly 4).
> Later RISC processors and x86 did FMAC in 4-cycles (occasionally 5).
> 

Arm Inc. application processors cores have FMAC latency=4 for
multiplicands, but 2 for accumulator.

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

#115047

Michael S <already5chosen@yahoo.com> posted:

> On Thu, 19 Feb 2026 17:30:50 GMT
> MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
> 
> > BGB <cr88192@gmail.com> posted:
> > 
> > > On 2/12/2026 11:09 AM, MitchAlsup wrote:  
> > > > 
> > > > anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> > > >   
> > > >> MitchAlsup <user5857@newsgrouper.org.invalid> writes:  
> > > >>> {{One can STILL argue whether
> > > >>> deNormals were a plus or a minus in IEEE}}  
> > > >>
> > > >> I am surprised to read that from you, who has always written that
> > > >> denormals can be implemented cheaply and efficiently in
> > > >> hardware.  The additional hardware cost (or the cost of trapping
> > > >> and software emulation) has been the only argument against
> > > >> denormals that I ever encountered.  
> > > > 
> > > > It is only after IEEE 754-2008 came with FMAC that deNormals
> > > > became a low cost addition. {And that has been my point--you seem
> > > > to have forgotten the -2008 part or the argument}  
> > > 
> > > And, can note, this is assuming that one actually pays the cost of 
> > > native hardware FMAC.
> > >   
> > It is exceedingly difficult to get an IEEE quality rounded result if
> > not done in HW.
> > > 
> > > Well, and the secondary irony that it is mainly cost-added for
> > > FMUL, whereas FADD almost invariably has the necessary support
> > > hardware already.
> > > 
> > > But:
> > >    FMUL is expensive operation + cheap normalizer (if no denormals);
> > >    FADD is cheap operation with expensive normalizer.
> > > 
> > > FMAC then is gluing the costs of the two units together, but:
> > >    With roughly the latency of both;
> > >    The need to be significantly wider internally to deal with some
> > > cases.  
> > 
> > The add stage after the multiplication tree is <essentially> 2× as
> > wide. FMUL needs a 108-bit 2-input adder
> > FMAC needs a 160-bit 3-input adder and a 52-bit incrementor.
> > The multiplication tree is the same, normalizer is larger.
> > 
> > > 
> > > So, FMAC is a single unit that costs more than both units taken 
> > > separately, and with a higher latency.  
> > 
> > Prior RISC processors did FMUL in 3-4 cycles (mostly 4).
> > Later RISC processors and x86 did FMAC in 4-cycles (occasionally 5).
> > 
> 
> Arm Inc. application processors cores have FMAC latency=4 for
> multiplicands, but 2 for accumulator.
> 
Thank you for that tid-bit of information.
> 

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

#115058

On 2/19/2026 11:30 AM, MitchAlsup wrote:
> 
> BGB <cr88192@gmail.com> posted:
> 
>> On 2/12/2026 11:09 AM, MitchAlsup wrote:
>>>
>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>>>
>>>> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>>>>> {{One can STILL argue whether
>>>>> deNormals were a plus or a minus in IEEE}}
>>>>
>>>> I am surprised to read that from you, who has always written that
>>>> denormals can be implemented cheaply and efficiently in hardware.  The
>>>> additional hardware cost (or the cost of trapping and software
>>>> emulation) has been the only argument against denormals that I ever
>>>> encountered.
>>>
>>> It is only after IEEE 754-2008 came with FMAC that deNormals became
>>> a low cost addition. {And that has been my point--you seem to have
>>> forgotten the -2008 part or the argument}
>>
>> And, can note, this is assuming that one actually pays the cost of
>> native hardware FMAC.
>>
> It is exceedingly difficult to get an IEEE quality rounded result if
> not done in HW.

Likely depends.


Can use the trick of bumping to the next size up and use that for 
computation.

So, for Binary32 compute it as Binary64, and for Binary64 compute it as 
Binary128.

Can special case the "Binary64 * Binary64 => Binary128" case to save 
cost over using a native Binary128 multiply.

For Binary128 multiply, can also make sense to detect and special-case 
the "low order bits are zero" case:
If low-order bits are zero, can use a multiply that only produces the 
high 128 bits;
Vs a transient 128*128=>256 bit, and then needing to round.



Relative cost is lower if one is already paying the cost of a trap 
handler or similar (except that if the ISA supports it, you really don't 
want the compiler to combine these operations).

So, one can maybe document if using a compiler like GCC to use 
"-fp-contract=off -fno-fdiv", ...


>>
>> Well, and the secondary irony that it is mainly cost-added for FMUL,
>> whereas FADD almost invariably has the necessary support hardware already.
>>
>> But:
>>     FMUL is expensive operation + cheap normalizer (if no denormals);
>>     FADD is cheap operation with expensive normalizer.
>>
>> FMAC then is gluing the costs of the two units together, but:
>>     With roughly the latency of both;
>>     The need to be significantly wider internally to deal with some cases.
> 
> The add stage after the multiplication tree is <essentially> 2× as wide.
> FMUL needs a 108-bit 2-input adder
> FMAC needs a 160-bit 3-input adder and a 52-bit incrementor.
> The multiplication tree is the same, normalizer is larger.
> 

A 160-bit 3-way adder happening "quickly" is still kinda asking a lot 
though...


Though, granted, the first step is deciding to decide full-width 
multiply, and not discard the low order results.

Granted discarding the low results reduces rounding accuracy, but a way 
to fake full IEEE rounding was to detect this case and have the FMUL 
raise a fault (similar to denormal/underflow handling). Though, does 
mean there is a performance penalty if multiplying numbers where the 
low-order bits in both values are non-zero.


In my ISA, the exact behavior depends on instruction an rounding mode.
In the RISC-V mode, partly based on instruction rounding mode and and 
flags settings.

For reasons though, can't safely enable full IEEE emulation until after 
setting up virtual memory and similar though.


The handling of the RISC-V F/D extensions was non-standard in my case, 
though not in a way that effects GCC output (it seems to exclusively use 
the DYN rounding mode in instructions, assuming the rounding mode to be 
handled via CSR's). Also, ironically and contrasting with the seeming 
design of these extensions, these registers are so rarely accessed in 
practice that it seemed most sensible to use trap-and-emulate for the CSRs.


Granted, there are limits to corner cutting:
If a design does not produce exact results for cases where it is trivial 
to verify that an exact answer exists in cases that do not require 
rounding, IMO this is below the minimum limit for a usable general 
purpose FPU.


>>
>> So, FMAC is a single unit that costs more than both units taken
>> separately, and with a higher latency.
> 
> Prior RISC processors did FMUL in 3-4 cycles (mostly 4).
> Later RISC processors and x86 did FMAC in 4-cycles (occasionally 5).
> 

Trying to push the latency down would be pretty bad for timing, unless 
there is some cheaper way to implement FPUs that I am not aware of.

In my case:
   FMADD.D, RM=DYN: Trap
   FMADD.D, RM=RNE, 10-cycle, double-rounded (non-standard)
   FMADD.S, RM=DYN, 10-cycle (mimics single rounding, *)
     *: Happens internally at Binary64 precision.

It could be possible to handle FMADD.D RM=DYN the same way as RNE 
internally, but then trap if the inputs would potentially give a 
non-IEEE result. Though, for now, trapping is the cheaper solution in 
terms of HW cost.




The one exception is FP8*FP8 + FP16, but mostly because it is possible 
to do FP8*FP8 under 1 cycle.

But, still not free here; and overly niche. Ended up going with a 
cheaper option of simply having an SIMD FP8*FP8=>FP16 multiply op (which 
still ends up as a 2-cycle op, because...).

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

#115061

BGB wrote:
> On 2/19/2026 11:30 AM, MitchAlsup wrote:
>>
>> BGB <cr88192@gmail.com> posted:
>>
>>> On 2/12/2026 11:09 AM, MitchAlsup wrote:
>>>>
>>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>>>>
>>>>> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>>>>>> {{One can STILL argue whether
>>>>>> deNormals were a plus or a minus in IEEE}}
>>>>>
>>>>> I am surprised to read that from you, who has always written that
>>>>> denormals can be implemented cheaply and efficiently in hardware.  The
>>>>> additional hardware cost (or the cost of trapping and software
>>>>> emulation) has been the only argument against denormals that I ever
>>>>> encountered.
>>>>
>>>> It is only after IEEE 754-2008 came with FMAC that deNormals became
>>>> a low cost addition. {And that has been my point--you seem to have
>>>> forgotten the -2008 part or the argument}
>>>
>>> And, can note, this is assuming that one actually pays the cost of
>>> native hardware FMAC.
>>>
>> It is exceedingly difficult to get an IEEE quality rounded result if
>> not done in HW.
> 
> Likely depends.
> 
> 
> Can use the trick of bumping to the next size up and use that for 
> computation.
> 
> So, for Binary32 compute it as Binary64, and for Binary64 compute it as 
> Binary128.

Neither of those work!

I believed this to be true but I was shown the error of my thinking by 
more knowledgable people in the 754 working group. I.e. they had a very 
simple/small example where doing the calculation in the next higher 
precision would still cause double rounding errors.

Also note that Mitch have stated multiple times that you need ~160 
mantissa bits during FMAC double calculations.

Terje

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

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

#115063

On 2/20/2026 8:22 AM, Terje Mathisen wrote:
> BGB wrote:
>> On 2/19/2026 11:30 AM, MitchAlsup wrote:
>>>
>>> BGB <cr88192@gmail.com> posted:
>>>
>>>> On 2/12/2026 11:09 AM, MitchAlsup wrote:
>>>>>
>>>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>>>>>
>>>>>> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>>>>>>> {{One can STILL argue whether
>>>>>>> deNormals were a plus or a minus in IEEE}}
>>>>>>
>>>>>> I am surprised to read that from you, who has always written that
>>>>>> denormals can be implemented cheaply and efficiently in hardware.  
>>>>>> The
>>>>>> additional hardware cost (or the cost of trapping and software
>>>>>> emulation) has been the only argument against denormals that I ever
>>>>>> encountered.
>>>>>
>>>>> It is only after IEEE 754-2008 came with FMAC that deNormals became
>>>>> a low cost addition. {And that has been my point--you seem to have
>>>>> forgotten the -2008 part or the argument}
>>>>
>>>> And, can note, this is assuming that one actually pays the cost of
>>>> native hardware FMAC.
>>>>
>>> It is exceedingly difficult to get an IEEE quality rounded result if
>>> not done in HW.
>>
>> Likely depends.
>>
>>
>> Can use the trick of bumping to the next size up and use that for 
>> computation.
>>
>> So, for Binary32 compute it as Binary64, and for Binary64 compute it 
>> as Binary128.
> 
> Neither of those work!
> 
> I believed this to be true but I was shown the error of my thinking by 
> more knowledgable people in the 754 working group. I.e. they had a very 
> simple/small example where doing the calculation in the next higher 
> precision would still cause double rounding errors.
> 
> Also note that Mitch have stated multiple times that you need ~160 
> mantissa bits during FMAC double calculations.
> 

Could look into this, next option being to use a makeshift 192-bit FP 
format with a 176 bit mantissa (likely cheaper than going all the way to 
224 bits).

This is slow/annoying, but not really likely a "hard" problem (when one 
is already doing this stuff in software in a trap handler).


So, potentially:
   Binary32 -> FP96 (truncated Binary128, still stored as Binary128)
   Binary64 -> FP192 (extended Binary128)
   Binary128 -> FP384 (likewise)
     Big/ugly, but no one says this needs to be fast...


Might end up on a sort of "TODO list"...


In any case, actual native hardware support for single-rounded FMA is 
unlikely to happen in my case.


...

> Terje
> 

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

#115119

On 2/19/26 12:30 PM, MitchAlsup wrote:
[snip]
> The add stage after the multiplication tree is <essentially> 2× as wide.
> FMUL needs a 108-bit 2-input adder
> FMAC needs a 160-bit 3-input adder and a 52-bit incrementor.
> The multiplication tree is the same, normalizer is larger.

How much of that applies to a double-rounded FMADD? Double-
rounding would have the advantage of giving bit-identical
results.

While a single-rounding presents more algorithmic opportunities,
double-rounded FMADD would still save decode bandwidth (and
issue bandwidth if a pair of FMUL and FADD instructions were not
fused by idiom recognition) at the cost of supporting three-
input operations (with reduced forwarding per unit work).

Getting bit-identical results for FMUL and FADD executed
separately or as a fused operation and an ISA extension FMADD
might have some practical benefit.

(I still wonder if an FP execution model that only calculated to
the integer size precision (64-bit integer for 64-bit FP),
ignoring carry-in, might have been acceptable for 99% of uses
and saved a little bit of power and area as well as potentially
facilitated software FP — to implement FMUL without carry-in one
would have to have an integer multiply high result that did not
use carry-in (a mirror of multiply low execution) which would
probably only be useful for multiplication by reciprocal as
integer results are expected to be exact.)

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

#114935

On Thu, 12 Feb 2026 02:04:58 GMT
MitchAlsup <user5857@newsgrouper.org.invalid> wrote:

> John Levine <johnl@taugh.com> posted:
> 
> > According to David Schultz  <david.schultz@earthlink.net>:  
> > >This reminds me of when I took a numerical analysis course. (The
> > >many ways that computer calculations can go wrong and how to deal
> > >with it.) The professor said that the schools IBM (360 or 370, ca.
> > >1980) was perfect for the course because of the defects in its
> > >floating point system. Guard digits and rounding sorts of things
> > >as near as I can recall.  
> > 
> > The 360's floating point is a famous and somewhat puzzling failure,
> > considering how much else they got right.
> > 
> > It does hex normalization rather than binary. They assumed that
> > leading digits are evenly distributed so there's be on average one
> > zero bit, but in fact they're geometrically distributed, so on
> > average there's two. They got one bit back by making the exponent
> > units of 16 rather than 2, but that's still one bit gone. It
> > truncated rather than rounding, another bit gone.  They also
> > truncated rather than rounding results.
> > 
> > Originally there wre no guard digits which made the results
> > comically bad but IBM retrofitted them at great cost to all the
> > installed machines.
> > 
> > IEEE floating point can be seen as a reaction to that, how do you
> > use the same number of bits but get good results.  
> 
> VAX got this correct too (the VAX format not the one inherited from 
> PDP-11/45; PDP-11/40* FP was worse). VAX FP is arguably as good as
> IEEE 754 with the exception that more IEEE numbers have reciprocals 
> due to the change in exponent bias by 1. {{One can STILL argue whether
> deNormals were a plus or a minus in IEEE}}

From the perspective of stability of convergence of few common
algorithms denormals are significant plus.
From the perspective of minimizing surprises it is also plus. On VAX 
(a > b) does not necessarily guarantee (a-b > 0).
I wonder in which situation it can be seen as a minus?

There are several things that I don't like about IEEE-754 Standard, but
none of them related to format of binary numbers.

> 
> CMU had a PDP-11/40 with writable control store 1974. I programmed it 
> to do PDP-11/45 FP instead of PDP-11/40 FP as a Jr. project.
> >   

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

#114946

Michael S <already5chosen@yahoo.com> posted:

> On Thu, 12 Feb 2026 02:04:58 GMT
> MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
> 
> > John Levine <johnl@taugh.com> posted:
> > 
> > > According to David Schultz  <david.schultz@earthlink.net>:  
> > > >This reminds me of when I took a numerical analysis course. (The
> > > >many ways that computer calculations can go wrong and how to deal
> > > >with it.) The professor said that the schools IBM (360 or 370, ca.
> > > >1980) was perfect for the course because of the defects in its
> > > >floating point system. Guard digits and rounding sorts of things
> > > >as near as I can recall.  
> > > 
> > > The 360's floating point is a famous and somewhat puzzling failure,
> > > considering how much else they got right.
> > > 
> > > It does hex normalization rather than binary. They assumed that
> > > leading digits are evenly distributed so there's be on average one
> > > zero bit, but in fact they're geometrically distributed, so on
> > > average there's two. They got one bit back by making the exponent
> > > units of 16 rather than 2, but that's still one bit gone. It
> > > truncated rather than rounding, another bit gone.  They also
> > > truncated rather than rounding results.
> > > 
> > > Originally there wre no guard digits which made the results
> > > comically bad but IBM retrofitted them at great cost to all the
> > > installed machines.
> > > 
> > > IEEE floating point can be seen as a reaction to that, how do you
> > > use the same number of bits but get good results.  
> > 
> > VAX got this correct too (the VAX format not the one inherited from 
> > PDP-11/45; PDP-11/40* FP was worse). VAX FP is arguably as good as
> > IEEE 754 with the exception that more IEEE numbers have reciprocals 
> > due to the change in exponent bias by 1. {{One can STILL argue whether
> > deNormals were a plus or a minus in IEEE}}
> 
> From the perspective of stability of convergence of few common
> algorithms denormals are significant plus.
> From the perspective of minimizing surprises it is also plus. On VAX 
> (a > b) does not necessarily guarantee (a-b > 0).
> I wonder in which situation it can be seen as a minus?

a-b underflows and takes a trap.
 
> There are several things that I don't like about IEEE-754 Standard, but
> none of them related to format of binary numbers.
> 
> > 
> > CMU had a PDP-11/40 with writable control store 1974. I programmed it 
> > to do PDP-11/45 FP instead of PDP-11/40 FP as a Jr. project.
> > >   
> 
> 

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

#114955

On Thu, 12 Feb 2026 17:10:45 GMT
MitchAlsup <user5857@newsgrouper.org.invalid> wrote:

> Michael S <already5chosen@yahoo.com> posted:
> 
> > On Thu, 12 Feb 2026 02:04:58 GMT
> > MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
> >   
> > > John Levine <johnl@taugh.com> posted:
> > >   
> > > > According to David Schultz  <david.schultz@earthlink.net>:    
> > > > >This reminds me of when I took a numerical analysis course.
> > > > >(The many ways that computer calculations can go wrong and how
> > > > >to deal with it.) The professor said that the schools IBM (360
> > > > >or 370, ca. 1980) was perfect for the course because of the
> > > > >defects in its floating point system. Guard digits and
> > > > >rounding sorts of things as near as I can recall.    
> > > > 
> > > > The 360's floating point is a famous and somewhat puzzling
> > > > failure, considering how much else they got right.
> > > > 
> > > > It does hex normalization rather than binary. They assumed that
> > > > leading digits are evenly distributed so there's be on average
> > > > one zero bit, but in fact they're geometrically distributed, so
> > > > on average there's two. They got one bit back by making the
> > > > exponent units of 16 rather than 2, but that's still one bit
> > > > gone. It truncated rather than rounding, another bit gone.
> > > > They also truncated rather than rounding results.
> > > > 
> > > > Originally there wre no guard digits which made the results
> > > > comically bad but IBM retrofitted them at great cost to all the
> > > > installed machines.
> > > > 
> > > > IEEE floating point can be seen as a reaction to that, how do
> > > > you use the same number of bits but get good results.    
> > > 
> > > VAX got this correct too (the VAX format not the one inherited
> > > from PDP-11/45; PDP-11/40* FP was worse). VAX FP is arguably as
> > > good as IEEE 754 with the exception that more IEEE numbers have
> > > reciprocals due to the change in exponent bias by 1. {{One can
> > > STILL argue whether deNormals were a plus or a minus in IEEE}}  
> > 
> > From the perspective of stability of convergence of few common
> > algorithms denormals are significant plus.
> > From the perspective of minimizing surprises it is also plus. On
> > VAX (a > b) does not necessarily guarantee (a-b > 0).
> > I wonder in which situation it can be seen as a minus?  
> 
> a-b underflows and takes a trap.
>

Then, don't take traps on underflow. It's most certainly not a
default behavior. 
If somebody decided to enable trap then hopefully he knows what he is
doing.


> > There are several things that I don't like about IEEE-754 Standard,
> > but none of them related to format of binary numbers.
> >   
> > > 
> > > CMU had a PDP-11/40 with writable control store 1974. I
> > > programmed it to do PDP-11/45 FP instead of PDP-11/40 FP as a Jr.
> > > project.  
> > > >     
> > 
> >   

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

#114938

MitchAlsup wrote:
> 
> John Levine <johnl@taugh.com> posted:
> 
>> According to David Schultz  <david.schultz@earthlink.net>:
>>> This reminds me of when I took a numerical analysis course. (The many
>>> ways that computer calculations can go wrong and how to deal with it.)
>>> The professor said that the schools IBM (360 or 370, ca. 1980) was
>>> perfect for the course because of the defects in its floating point
>>> system. Guard digits and rounding sorts of things as near as I can recall.
>>
>> The 360's floating point is a famous and somewhat puzzling failure, considering
>> how much else they got right.
>>
>> It does hex normalization rather than binary. They assumed that
>> leading digits are evenly distributed so there's be on average one
>> zero bit, but in fact they're geometrically distributed, so on average
>> there's two. They got one bit back by making the exponent units of 16
>> rather than 2, but that's still one bit gone. It truncated rather than
>> rounding, another bit gone.  They also truncated rather than rounding
>> results.
>>
>> Originally there wre no guard digits which made the results comically
>> bad but IBM retrofitted them at great cost to all the installed machines.
>>
>> IEEE floating point can be seen as a reaction to that, how do you use
>> the same number of bits but get good results.
> 
> VAX got this correct too (the VAX format not the one inherited from
> PDP-11/45; PDP-11/40* FP was worse). VAX FP is arguably as good as
> IEEE 754 with the exception that more IEEE numbers have reciprocals
> due to the change in exponent bias by 1. {{One can STILL argue whether
> deNormals were a plus or a minus in IEEE}}

You _can_ argue about that, but as you've told us on numerous occations, 
it doesn't actually cost any clock cycles, and there are a few 
zer-seeking algorithms which would not be trivially stable without 
subnormals.

Finally, having subnormals meens that any possible bit pattern between 
negative NaN and positive NaN have a meaningful real value (or +/- Inf), 
so you can compare them, increment them etc without worry.

Terje


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

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

#114931

On Wed, 11 Feb 2026 17:57:29 -0600, David Schultz wrote:
> On 2/11/26 5:04 PM, quadi wrote:

>> I remember having read one article in a computer magazine where someone
>> mentioned that an unfortunate result of the transition from the IBM
>> 7090 to the IBM System/360 was that a lot of FORTRAN programs that were
>> able to use ordinary real nubers had to be switched over to double
>> precision to yield acceptable results.

> This reminds me of when I took a numerical analysis course. (The many
> ways that computer calculations can go wrong and how to deal with it.)
> The professor said that the schools IBM (360 or 370, ca. 1980) was
> perfect for the course because of the defects in its floating point
> system. Guard digits and rounding sorts of things as near as I can
> recall.

Mitch Alsup mentioned that there was no guard digit in the floating-point 
arithmetic units of the various IBM System/360 models when they were 
initially released. However, this was so serious an omission, as was 
quickly noted in practice, that IBM quickly modified the design, and 
refitted all the units in the field.

Even after this was done, though, since the exponent in IBM floating-point 
was a power of 16 rather than 2, and since floating-point calculations 
were truncated rather than rounded on the System/360, its floating-point 
was still considered to be less than the greatest.

There were workarounds, though, which people have mostly forgotten about 
due to the ubiquity of IEEE 754 floating-point these days. A famous 
numerical analysis textbook which explained how to cope with the problems 
caused by substandard floating point formats was _Floating-Point 
Computation_ by Pat H. Sterbenz.

John Savard

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

#114936

On Wed, 11 Feb 2026 17:57:29 -0600
David Schultz <david.schultz@earthlink.net> wrote:

> On 2/11/26 5:04 PM, quadi wrote:
> > I remember having read one article in a computer magazine where
> > someone mentioned that an unfortunate result of the transition from
> > the IBM 7090 to the IBM System/360 was that a lot of FORTRAN
> > programs that were able to use ordinary real nubers had to be
> > switched over to double precision to yield acceptable results.  
> 
> This reminds me of when I took a numerical analysis course. (The many 
> ways that computer calculations can go wrong and how to deal with
> it.) The professor said that the schools IBM (360 or 370, ca. 1980)
> was perfect for the course because of the defects in its floating
> point system. Guard digits and rounding sorts of things as near as I
> can recall.
> 

Was not quality of arithmetic of CDC machines of the 70s even worse
than that of IBM ?

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

#114948

On Thu, 12 Feb 2026 10:53:58 +0200, Michael S wrote:

> Was not quality of arithmetic of CDC machines of the 70s even worse than
> that of IBM ?

I don't know about that. But I do know that despite having a power-of-two 
exponent, quality of arithmetic on the Cray I was pretty terrible.

John Savard

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

#114952

quadi <quadibloc@ca.invalid> posted:

> On Thu, 12 Feb 2026 10:53:58 +0200, Michael S wrote:
> 
> > Was not quality of arithmetic of CDC machines of the 70s even worse than
> > that of IBM ?
> 
> I don't know about that. But I do know that despite having a power-of-two 
> exponent, quality of arithmetic on the Cray I was pretty terrible.

Unlike CDC 6600/7600, CRAY multiply did not have a full 'tree' of
multiplication logic--leading to all sorts of "headaches" for 
numerical analysists. Given a 4×4 set of multiplication gates,
cray only used 80%-odd of the required macros to get multiplication
'right'.
 
> John Savard
> 

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

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

Back to top | Article view | comp.arch

csiph-web