MitchAlsup wrote:
> On Sunday, August 8, 2021 at 11:59:22 AM UTC-5, Tim Rentsch wrote:
>> which makes me wonder what IEEE-754 behaviors you think would
>> not be observed in such an implementation.
> <
> There is stuff in IEEE 754-2008 and -2019 that is not in -1985.
> <
> FMAC for example.
> <
> List of transcendental functions which must be "accurately" implemented
> --more about the various boundary conditions and resultant values than
> properly rounded.
> <
> 5th rounding mode (Round away from zero == round nearest magnitude.)
> <
> Return to -1985 MAX() and MIN() {which -2009 totally blew}
>
We did fix min/max in 2019, specifically because 2008 did in fact mess
it up horribly. :-(

We did not manage to reach consensus on fixing all the other ways NaNs
can silently disappear, but you can at least mostly avoid those situations.

Converting a FP value to int is a typical example: If you have
suppressed floating point traps, then there is no way to propagate the
NaN-ness of the input.

Terje

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

On 8/9/2021 1:39 AM, Terje Mathisen wrote:
> MitchAlsup wrote:
>> On Sunday, August 8, 2021 at 11:59:22 AM UTC-5, Tim Rentsch wrote:
>>> which makes me wonder what IEEE-754 behaviors you think would
>>> not be observed in such an implementation.
>> <
>> There is stuff in IEEE 754-2008 and -2019 that is not in -1985.
>> <
>> FMAC for example.
>> <
>> List of transcendental functions which must be "accurately" implemented
>> --more about the various boundary conditions and resultant values than
>> properly rounded.
>> <
>> 5th rounding mode (Round away from zero == round nearest magnitude.)
>> <
>> Return to -1985 MAX() and MIN() {which -2009 totally blew}
>>
> We did fix min/max in 2019, specifically because 2008 did in fact mess
> it up horribly. :-(
>
> We did not manage to reach consensus on fixing all the other ways NaNs
> can silently disappear, but you can at least mostly avoid those situations.
>
> Converting a FP value to int is a typical example: If you have
> suppressed floating point traps, then there is no way to propagate the
> NaN-ness of the input.

On most machines, but not all.

BGB <cr88192@gmail.com> writes:

> On 8/8/2021 11:59 AM, Tim Rentsch wrote:
>
>> BGB <cr88192@gmail.com> writes:
>>
>>> On 8/2/2021 3:26 AM, Tim Rentsch wrote:
>>>
>>>> Quadibloc <jsavard@ecn.ab.ca> writes:
>>>>
>>>>> On Sunday, August 1, 2021 at 10:14:16 AM UTC-6, Tim Rentsch
>>>>> quoted, in part:
>>>>>
>>>>>> There was strong agreement in the C89 Committee that
>>>>>> floating values should truncate toward zero when converted
>>>>>> to an integer type,
>>>>>
>>>>> I have no problem with that. Of course the integer part of a
>>>>> float would be what you get from round towards zero.
>>>>>
>>>>> Where I think round-to-nearest is preferable is after an
>>>>> arithmetic operation, where the result is rounded to go back
>>>>> in the same floating-point type.
>>>>
>>>> Then you are in luck - the C standard allows C implementations
>>>> to use that rule.
>>>
>>> Yeah. If one directly follows the C standard, they are can use
>>> hard-wired truncate-towards-zero for integer, and round-to-nearest for
>>> floating point.
>>>
>>> While IEEE-754 asks a bit more, the stuff it asks doesn't map exactly
>>> to C, and many traditional sorts of compiler optimizations are likely
>>> to break any sort of bit-exactness one could otherwise expect from it.
>>
>> I am curious to know what you think these might be. The C standard
>> does include the conditional feature macro __STDC_IEC_559__ :
>>
>> The integer constant 1, intended to indicate conformance to
>> the specifications in annex F (IEC 60559 floating-point
>> arithmetic).
>>
>> which references the normative annex F, which says in its introduction
>>
>> This annex specifies C language support for the IEC 60559
>> floating-point standard. The IEC 60559 floating-point
>> standard is specifically Binary floating-point arithmetic for
>> microprocessor systems, second edition (IEC 60559:1989),
>> previously designated IEC 559:1989 and as IEEE Standard for
>> Binary Floating-Point Arithmetic (ANSI/IEEE 754.1985). IEEE
>> Standard for Radix-Independent Floating-Point Arithmetic
>> (ANSI/IEEE 854.1987) generalizes the binary standard to
>> remove dependencies on radix and word length. IEC 60559
>> generally refers to the floating-point standard, as in IEC
>> 60559 operation, IEC 60559 format, etc. An implementation
>> that defines __STDC_IEC_559__ shall conform to the
>> specifications in this annex. Where a binding between the C
>> language and IEC 60559 is indicated, the IEC 60559-specified
>> behavior is adopted by reference, unless stated otherwise.
>> Since negative and positive infinity are representable in IEC
>> 60559 formats, all real numbers lie within the range of
>> representable values.
>>
>> Annex F is quite detailed, occupying 25 pages in the C standard.
>> An example requirement:
>>
>> The +, -, *, and / operators provide the IEC 60559 add,
>> subtract, multiply, and divide operations.
>>
>> which makes me wonder what IEEE-754 behaviors you think would
>> not be observed in such an implementation.
>
> Hmm...
>
> Was going to note the lack of any standard way to specify the rounding
> mode, ...
>
> But, then went and looked at it and noted that it seems to be that I
> had failed to notice that "fenv.h" was a thing, which does provide a
> means to specify this.
>
>
> So, it appears that a function is used to get/set the rounding mode,
> but a pragma may be required to tell the compiler to actually use the
> rounding mode and similar (and also disable some types of
> optimizations):
> #pragma STDC FENV_ACCESS ON //enable FPU magic
> fesetround(FE_TOWARDZERO); //set to truncate
> ...
>
> With:
> #pragma fenv_access(on) //apparent alternate notation
>
>
> I guess I could maybe look into this some more...

If you do I expect you will find that C implementations can
be completely in line with IEEE-754, including later versions
of that, if they choose to be. Heaven knows I'm not an
expert on floating point, but there are such experts around,
with at least one serving on the C standards committee for
quite a long time.

MitchAlsup <MitchAlsup@aol.com> writes:

> On Sunday, August 8, 2021 at 11:59:22 AM UTC-5, Tim Rentsch wrote:
>
>> BGB <cr8...@gmail.com> writes:
>>
>>> On 8/2/2021 3:26 AM, Tim Rentsch wrote:
>>>
>>>> Quadibloc <jsa...@ecn.ab.ca> writes:
>>>>
>>>>> On Sunday, August 1, 2021 at 10:14:16 AM UTC-6, Tim Rentsch
>>>>> quoted, in part:
>>>>>
>>>>>> There was strong agreement in the C89 Committee that
>>>>>> floating values should truncate toward zero when converted
>>>>>> to an integer type,
>>>>>
>>>>> I have no problem with that. Of course the integer part of a
>>>>> float would be what you get from round towards zero.
>>>>>
>>>>> Where I think round-to-nearest is preferable is after an
>>>>> arithmetic operation, where the result is rounded to go back
>>>>> in the same floating-point type.
>>>>
>>>> Then you are in luck - the C standard allows C implementations
>>>> to use that rule.
>>>
>>> Yeah. If one directly follows the C standard, they are can use
>>> hard-wired truncate-towards-zero for integer, and round-to-nearest for
>>> floating point.
>>>
>>> While IEEE-754 asks a bit more, the stuff it asks doesn't map exactly
>>> to C, and many traditional sorts of compiler optimizations are likely
>>> to break any sort of bit-exactness one could otherwise expect from it.
>>
>> I am curious to know what you think these might be. The C standard
>> does include the conditional feature macro __STDC_IEC_559__ :
>>
>> The integer constant 1, intended to indicate conformance to
>> the specifications in annex F (IEC 60559 floating-point
>> arithmetic).
>>
>> which references the normative annex F, which says in its introduction
>>
>> This annex specifies C language support for the IEC 60559
>> floating-point standard. The IEC 60559 floating-point
>> standard is specifically Binary floating-point arithmetic for
>> microprocessor systems, second edition (IEC 60559:1989),
>> previously designated IEC 559:1989 and as IEEE Standard for
>> Binary Floating-Point Arithmetic (ANSI/IEEE 754.1985). IEEE
>> Standard for Radix-Independent Floating-Point Arithmetic
>> (ANSI/IEEE 854.1987) generalizes the binary standard to
>> remove dependencies on radix and word length. IEC 60559
>> generally refers to the floating-point standard, as in IEC
>> 60559 operation, IEC 60559 format, etc. An implementation
>> that defines __STDC_IEC_559__ shall conform to the
>> specifications in this annex. Where a binding between the C
>> language and IEC 60559 is indicated, the IEC 60559-specified
>> behavior is adopted by reference, unless stated otherwise.
>> Since negative and positive infinity are representable in IEC
>> 60559 formats, all real numbers lie within the range of
>> representable values.
>>
>> Annex F is quite detailed, occupying 25 pages in the C standard.
>> An example requirement:
>>
>> The +, -, *, and / operators provide the IEC 60559 add,
>> subtract, multiply, and divide operations.
>>
>> which makes me wonder what IEEE-754 behaviors you think would
>> not be observed in such an implementation.
>
> There is stuff in IEEE 754-2008 and -2019 that is not in -1985.
> FMAC for example.
> List of transcendental functions which must be "accurately" implemented
> --more about the various boundary conditions and resultant values than
> properly rounded.
> 5th rounding mode (Round away from zero == round nearest magnitude.)
> Return to -1985 MAX() and MIN() {which -2009 totally blew}

I'm not familiar with the details of differences between different
versions of IEEE 754. Also I haven't looked closely at any
version of the C standard since the C11 standard. So I don't know
to what extent these added functionalities may have been added to
Annex F following the IEEE 754 changes.

In any case my point is not that C must be IEEE 754 compliant, and
indeed any particular C implementation might not be. Rather what
I am saying is that AFAIK a C implementation may be completely
compliant with IEEE 754, including the later versions, if it
chooses to be. Some of that conformance is guaranteed by the
C standards for implementations that define __STDC_IEC_559__.

Incidentally, as far as multiply-add goes, since C99 there has
been a standard C function to do this. Section 7.12.13.1
describes the fma functions

The fma functions compute (x*y)+z, rounded as one ternary
operation: they compute the value (as if) to infinite
precision and round once to the result format, according to
the current rounding mode. A range error may occur.

and fma is listed in Annex F as part of support for IEEE 754
floating point.

On Sunday, July 25, 2021 at 11:25:49 PM UTC-6, Quadibloc wrote:
> On Saturday, July 24, 2021 at 9:40:14 PM UTC-6, Quadibloc wrote:
> > On Saturday, July 24, 2021 at 3:24:21 PM UTC-6, Quadibloc wrote:
>
> > And the SS format instructions would be a mess:
> >
> > opcode: 8 bits
> > source base register: 1 bit
> > length: 8 bits
> > destination base register: 4 bits
> > destination address: 15 bits
> > source base register (continued): 3 bits
> > source address: 15 bits
>
> Silly me. Just move the destination address constant to an *odd*
> byte position, and everything is fine.
>
> opcode: 8 bits
> destination base register: 4 bits
> destination address: 15 bits
> length: 8 bits
> source base register: 4 bits
> source address: 15 bits
>
> So all I have to do is accept that the order of fields will be
> different from that in the System/360, and I get a reasonable
> 36-bit version of the System/360.

On my web page at

http://www.quadibloc.com/comp/cardint.htm

I now show, at the bottom of the page, a proposal for what the card
code for a 9-bit version of EBCDIC for such a computer could have
looked like.

John Savard

On Monday, July 26, 2021 at 5:21:42 AM UTC-6, Quadibloc wrote:
> or ARM
> or RISC-V even...

And, of course, just before Ryzen came out, AMD was working on
ARM-based server chips, using some of the same technology that
Ryzen was based on.

John Savard

On Tuesday, September 7, 2021 at 12:28:22 AM UTC-6, Quadibloc wrote:
> On my web page at
>
> http://www.quadibloc.com/comp/cardint.htm
>
> I now show, at the bottom of the page, a proposal for what the card
> code for a 9-bit version of EBCDIC for such a computer could have
> looked like.

And now, seeing as on the page

http://www.quadibloc.com/arch/perint.htm

I had already placed an illustration of the instruction set for another 36-bit
version of the System/360, I added a diagram of the form I described here
there as well (with an additional modification).

John Savard

On Tuesday, September 7, 2021 at 7:02:32 PM UTC-5, Quadibloc wrote:
> On Tuesday, September 7, 2021 at 12:28:22 AM UTC-6, Quadibloc wrote:
>
> > On my web page at
> >
> > http://www.quadibloc.com/comp/cardint.htm
> >
> > I now show, at the bottom of the page, a proposal for what the card
> > code for a 9-bit version of EBCDIC for such a computer could have
> > looked like.
> And now, seeing as on the page
>
> http://www.quadibloc.com/arch/perint.htm
>
> I had already placed an illustration of the instruction set for another 36-bit
> version of the System/360, I added a diagram of the form I described here
> there as well (with an additional modification).
>
> John Savard
<
John, by now you should have both learned and taken to heart we use DADDA
trees to build multipliers, not Wallace trees.
<
Also note: 754 chose the exponent bias such that the largest denormal number
could be reciprocated and not overflow. I suggest you follow.
<
It also seems to follow that if you have 36-bit single, you should have a 72-bit double.
{Not complaining about the others in the middle, just the lack of a true double.}

On Tuesday, September 7, 2021 at 6:16:47 PM UTC-6, MitchAlsup wrote:

> John, by now you should have both learned and taken to heart we use DADDA
> trees to build multipliers, not Wallace trees.

I mention Dadda trees on my site.

http://www.quadibloc.com/comp/cp0202.htm

is the page where I get into this level of detail. The Dadda Tree is a modified form of the Wallace
tree, invented one year later, in which some of the carry save additions take place latelr as an
additional optimization. That page even mentions a DEC patent which takes the Dadda Tree and
improves on it further.

By using the generic term, I don't exclude the 360/91, the Stretch, and several other early machines.

> It also seems to follow that if you have 36-bit single, you should have a 72-bit double.
> {Not complaining about the others in the middle, just the lack of a true double.}

Some designs do have a 72-bit double, because they're built around a 36-bit word, so anything
shorter would be inconvenient.

Basically, though, I'm going on the premise that 64 bit floats provide more precision than is actually
needed for almost all scientific work - 60 bits, as used in the 6600, is as much as almost anyone
would need. But the howls of outrage when the 360 replaced the 7090 indicates that 36 bits is the
minimum.

Maybe there are applications in which a "true double" is needed; I'm thinking in terms of programs that
only use *one* floating-point precision, the one suited to whatever it is they're calculating. While I see
36, 48, and 60 bits as being lengths with something to recommend them, of course there would also
be a 'temporary real'; that might be 96 bits on an architecture built around a 12 bit basic unit, and thus
24, 48, and 96 bit words. And since a temporary real doesn't have a hidden first bit, it can be unnormalized,
and so one can have a 'true double' made of two floats with one blank or offset exponent field - like on the
7090, or 128 bit floats on a 360.

So for the case where one precision that's a 'true double' of another is needed, something would be present;
48 and 96, or 96 and 192, but those would play a relatively minor role, which is why they didn't lead off
the discussion.

John Savard

On Tuesday, September 7, 2021 at 8:40:14 PM UTC-5, Quadibloc wrote:
> On Tuesday, September 7, 2021 at 6:16:47 PM UTC-6, MitchAlsup wrote:
>
> > John, by now you should have both learned and taken to heart we use DADDA
> > trees to build multipliers, not Wallace trees.
> I mention Dadda trees on my site.
>
> http://www.quadibloc.com/comp/cp0202.htm
>
> is the page where I get into this level of detail. The Dadda Tree is a modified form of the Wallace
> tree, invented one year later, in which some of the carry save additions take place latelr as an
> additional optimization. That page even mentions a DEC patent which takes the Dadda Tree and
> improves on it further.
>
> By using the generic term, I don't exclude the 360/91, the Stretch, and several other early machines.
<
A Wallace tree is a member of the family of multipliers annotated by Dadda.
It happens to be a not very good multiplier tree, but as used in /91 and Stretch is not harmful.
But they are ALL Dadda trees.
<
> > It also seems to follow that if you have 36-bit single, you should have a 72-bit double.
> > {Not complaining about the others in the middle, just the lack of a true double.}
<
> Some designs do have a 72-bit double, because they're built around a 36-bit word, so anything
> shorter would be inconvenient.
<
I am designing a machine with ½ cache line data transfers (256-bits) yet I still support signed
and unsigned Bytes !
>
> Basically, though, I'm going on the premise that 64 bit floats provide more precision than is actually
> needed for almost all scientific work - 60 bits, as used in the 6600, is as much as almost anyone
> would need. But the howls of outrage when the 360 replaced the 7090 indicates that 36 bits is the
> minimum.
<
I remember the howls, and how IBM had to field upgrade all the early deliveries with FP
that used a guard digit.
<
But 60-bits may have been enough in the days of 1 Gflop, it is no longer in the days of 1 PFlops;
or so I have been advised by some people running codes that take server farms months to run.
>
> Maybe there are applications in which a "true double" is needed; I'm thinking in terms of programs that
> only use *one* floating-point precision, the one suited to whatever it is they're calculating. While I see
> 36, 48, and 60 bits as being lengths with something to recommend them, of course there would also
> be a 'temporary real'; that might be 96 bits on an architecture built around a 12 bit basic unit, and thus
> 24, 48, and 96 bit words. And since a temporary real doesn't have a hidden first bit, it can be unnormalized,
> and so one can have a 'true double' made of two floats with one blank or offset exponent field - like on the
> 7090, or 128 bit floats on a 360.
>
> So for the case where one precision that's a 'true double' of another is needed, something would be present;
> 48 and 96, or 96 and 192, but those would play a relatively minor role, which is why they didn't lead off
> the discussion.
>
> John Savard

On Tuesday, September 7, 2021 at 7:48:08 PM UTC-6, MitchAlsup wrote:

> But 60-bits may have been enough in the days of 1 Gflop, it is no longer in the days of 1 PFlops;
> or so I have been advised by some people running codes that take server farms months to run.

I am going to have to look into that further.

I didn't address your point about reciprocals - I will have to check closely, but there is one
thing about my pages that may be confusing.

To allow consistency between IEEE 754 and "classic" floating-point formats, I refer to
the exponent as "excess-n" for a different valule of n: I put the binary point before the
hidden first bit, instead of at the start of the significand field. That way, the significand
is in the range [-0,1) for all formats.

John Savard

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> But the howls of outrage when the 360 replaced the 7090 indicates that 36 bits is the
> minimum.

One main reason for the howls of outrage was the choice of
hexadecimal base. Read Hacker's Delight for a rationale of the
criticism from an IBM insider; this choice basically reduced
accuracy to 21 bits.

Quadibloc wrote:
> Some designs do have a 72-bit double, because they're built around a
> 36-bit word, so anything shorter would be inconvenient.
>
> Basically, though, I'm going on the premise that 64 bit floats
> provide more precision than is actually needed for almost all
> scientific work - 60 bits, as used in the 6600, is as much as almost
> anyone would need. But the howls of outrage when the 360 replaced the
> 7090 indicates that 36 bits is the minimum.

John, you write a lot of interesting stuff, but please get rid of that idea!

We are rapidly running out of room even in double, so we are getting hw
support both for quad (1:15:112) and double-double (via
AugmentedAddition/AugmentedMultiplication), the latter are useful
building blocks for extended/arbitrary precision as long as the fixed
exponent range doesn't become a problem.

Terje

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

On Tuesday, September 7, 2021 at 11:56:42 PM UTC-6, Thomas Koenig wrote:

> One main reason for the howls of outrage was the choice of
> hexadecimal base.

Yes, I'm aware that this loses an additional three bits of precision, although
it's offset slightly by allowing the exponent field to be smaller.

John Savard

On Wednesday, September 8, 2021 at 12:17:22 AM UTC-6, Terje Mathisen wrote:
> Quadibloc wrote:
> > Some designs do have a 72-bit double, because they're built around a
> > 36-bit word, so anything shorter would be inconvenient.
> >
> > Basically, though, I'm going on the premise that 64 bit floats
> > provide more precision than is actually needed for almost all
> > scientific work - 60 bits, as used in the 6600, is as much as almost
> > anyone would need. But the howls of outrage when the 360 replaced the
> > 7090 indicates that 36 bits is the minimum.

> John, you write a lot of interesting stuff, but please get rid of that idea!
>
> We are rapidly running out of room even in double, so we are getting hw
> support both for quad (1:15:112) and double-double (via
> AugmentedAddition/AugmentedMultiplication), the latter are useful
> building blocks for extended/arbitrary precision as long as the fixed
> exponent range doesn't become a problem.

After a post by Mitch, I started a search for information about this issue.

At first, the references concerning longer precisions were mostly for
mathematical research. And I don't have anything against having support
for 128-bit floats, although I thought their use would be limited.

But I finally did come across one paper about implementing 128-bit
floating-point in an FPGA because it was needed for *computational
fluid dynamics*. While it took some digging to find even one source,
and I would have liked to see several, given that this is apparently
claimed to be a well-known common situation, still, it is confirmation.

John Savard

Quadibloc <jsavard@ecn.ab.ca> schrieb:

> But I finally did come across one paper about implementing 128-bit
> floating-point in an FPGA because it was needed for *computational
> fluid dynamics*.

CFD solves the "equations of change" (lovelty name that, from Bird,
Steward and Lightfoot) by discretizing them into finite <elements,
volumes, whatever>. Cells or elements or ... are coupled to their
neighboring cells, add boundary conditions, and you get a nonlinear
system of equations (Navier-Stokes with added turbulende or...).
The number of equations may well be in the tens of millions for
an intermediate-sized problem.

How do you usually solve a set of nonlinear equations?
You linearize it, and use Newton-Raphson, so you end up with a
set of (let's say) ten million (10**7) linear equations.

Because the discretization only couples values in your cell
with those of the neighbors, the overwhelming majority of the
coefficient matrix is filled with zeros - instead of (10**7)**3 =
10**21 coefficients, you only have a small multiple of the number
of your equations. This sort of system is called "sparse".

How do you solve such a system? Gaussian elimination, which you
may have learned at school, would quickly populate the empty
coefficient matrix, so you would end up needing doing a small
mutiple of 10**21 of storage for your coefficient matrix, and the
same for the number your calculations. Clearly not practiable,
and I did say "intermediate-sized" above.

What to do? Mathematicians have been _very_ busy and successfull
designing solvers tailored to sparse linear systems. They are
usually built on Krylov subspace methods. What these methods do,
in a nutshell, is to calculate a lots of vector-matrix products
with a few dot products thrown in and iterate this. (Look up
the GMRES method as an example if you want details).

All people reading this group should know that dot products (and,
as an extension, vector-matrix products) are susceptible to roundoff
errors. If your dot products on which the whole iteration scheme
depends are calculated with a large error, then the whole scheme
may converge much more slowly or even diverge although it would
converge for real numbers.

Hence, the need for high precision (or the whole IEEE precision
range) that we recently discussed here, which was actually
implemented once on an IBM 4381, IIRC, in coopration with the
group of Ulrich Kulisch of the University of Karlsruhe (now KIT).

Computers are getting bigger and faster, problems that you can
attack with CFD are getting bigger, rounding errors become worse
with an increasing number of additions (a triviality), so the need
for a more precise dot product becomes more pressing.

On Wednesday, September 8, 2021 at 9:39:24 AM UTC-6, Thomas Koenig wrote:

> Hence, the need for high precision (or the whole IEEE precision
> range) that we recently discussed here, which was actually
> implemented once on an IBM 4381, IIRC, in coopration with the
> group of Ulrich Kulisch of the University of Karlsruhe (now KIT).

I think you may be referring to the RFQ in which IBM implemented the
features associated with IEEE 754 for their own floating-point format.
The manual for that is on Bitsavers (and the Internet Archive, therefore):

https://archive.org/details/bitsavers_ibm370princuracyArithmeticJan84_2035458

John Savard

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> On Wednesday, September 8, 2021 at 9:39:24 AM UTC-6, Thomas Koenig wrote:
>
>> Hence, the need for high precision (or the whole IEEE precision
>> range) that we recently discussed here, which was actually
>> implemented once on an IBM 4381, IIRC, in coopration with the
>> group of Ulrich Kulisch of the University of Karlsruhe (now KIT).
>
> I think you may be referring to the RFQ in which IBM implemented the
> features associated with IEEE 754 for their own floating-point format.
> The manual for that is on Bitsavers (and the Internet Archive, therefore):
>
> https://archive.org/details/bitsavers_ibm370princuracyArithmeticJan84_2035458

It was

https://www.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP4361.html

(so the 4361, not the 4381 as I wrote above).

He also developed the XPA 3233 coprocessor, which some people at Berkley
(where else?) have extended and added to a RISC-V core (onto what else?)
https://pdfs.semanticscholar.org/5086/3205cbc73de1db985482018b79bd664dd181.pdf
has some details.

And "Jack Koenig" is not a relative as far as I know :-)

On Wednesday, September 8, 2021 at 1:47:40 PM UTC-6, Thomas Koenig wrote:

> https://pdfs.semanticscholar.org/5086/3205cbc73de1db985482018b79bd664dd181.pdf
> has some details.

The slide on page 6 has an area on the chip labelled "Wallace Tree" instead of "Dadda Tree"!

According to Mitch, this must be my fault!

John Savard

On Wednesday, September 8, 2021 at 6:40:48 PM UTC-5, Quadibloc wrote:
> On Wednesday, September 8, 2021 at 1:47:40 PM UTC-6, Thomas Koenig wrote:
>
> > https://pdfs.semanticscholar.org/5086/3205cbc73de1db985482018b79bd664dd181.pdf
> > has some details.
> The slide on page 6 has an area on the chip labelled "Wallace Tree" instead of "Dadda Tree"!
<
Note: It actually COULD be a Wallace tree--doubtful but possible.
<
Dadda is a superset of Wallace, you cannot connect a set of gates that operate
like a Wallace tree that is not also a Dadda tree.
<
Also Note: Most of the time a Dadda tree has either fewer gates of fewer gates of
delay than a Wallace tree. The converse is never true.
>
> According to Mitch, this must be my fault!
<
No the fault is that too many people have heard of Wallace, and too few have heard
of Dadda.
>
> John Savard

On Wednesday, September 8, 2021 at 12:17:22 AM UTC-6, Terje Mathisen wrote:

> We are rapidly running out of room even in double, so we are getting hw
> support both for quad (1:15:112) and double-double (via
> AugmentedAddition/AugmentedMultiplication), the latter are useful
> building blocks for extended/arbitrary precision as long as the fixed
> exponent range doesn't become a problem.

I finally looked up quad-double and double-double.

While I knew that with special instructions, floating-point formats that
allowed unnormalized numbers could be used to perform addition,
subtraction, and multiplication in extended precision (and division
therefore by Newton-Raphson or Goldschmidt), I didn't think it was
even *possible* to use ordinary floating-point instructions which didn't
provide additional information to do floating-point at higher precision
(except through very slow methods involving using floating-point
instructions to do arithmetic at half their precision).

John Savard

On Wednesday, September 8, 2021 at 9:47:56 PM UTC-5, Quadibloc wrote:
> On Wednesday, September 8, 2021 at 12:17:22 AM UTC-6, Terje Mathisen wrote:
> > We are rapidly running out of room even in double, so we are getting hw
> > support both for quad (1:15:112) and double-double (via
> > AugmentedAddition/AugmentedMultiplication), the latter are useful
> > building blocks for extended/arbitrary precision as long as the fixed
> > exponent range doesn't become a problem.
> I finally looked up quad-double and double-double.
>
> While I knew that with special instructions, floating-point formats that
> allowed unnormalized numbers could be used to perform addition,
> subtraction, and multiplication in extended precision (and division
> therefore by Newton-Raphson or Goldschmidt), I didn't think it was
> even *possible* to use ordinary floating-point instructions which didn't
> provide additional information to do floating-point at higher precision
> (except through very slow methods involving using floating-point
> instructions to do arithmetic at half their precision).
<
There is a whole subtopic of exact FP arithmetics, that use several FP
instructions in a row to perform FP arithmetic without error. Without error
means:: all of the bits that didn't make it into the first result got into the
second result.
<
The odd thing about IEEE 754 here is that 754 mandates the inexact bit
gets set on any of these sequences of instructions. My 66000 accesses
this functionality through the CARRY instruction, and when so used, does
not set the inexact bit!
>
> John Savard

MitchAlsup wrote:
> On Wednesday, September 8, 2021 at 9:47:56 PM UTC-5, Quadibloc wrote:
>> On Wednesday, September 8, 2021 at 12:17:22 AM UTC-6, Terje Mathisen wrote:
>>> We are rapidly running out of room even in double, so we are getting hw
>>> support both for quad (1:15:112) and double-double (via
>>> AugmentedAddition/AugmentedMultiplication), the latter are useful
>>> building blocks for extended/arbitrary precision as long as the fixed
>>> exponent range doesn't become a problem.
>> I finally looked up quad-double and double-double.
>>
>> While I knew that with special instructions, floating-point formats that
>> allowed unnormalized numbers could be used to perform addition,
>> subtraction, and multiplication in extended precision (and division
>> therefore by Newton-Raphson or Goldschmidt), I didn't think it was
>> even *possible* to use ordinary floating-point instructions which didn't
>> provide additional information to do floating-point at higher precision
>> (except through very slow methods involving using floating-point
>> instructions to do arithmetic at half their precision).
> <
> There is a whole subtopic of exact FP arithmetics, that use several FP
> instructions in a row to perform FP arithmetic without error. Without error
> means:: all of the bits that didn't make it into the first result got into the
> second result.
> <
> The odd thing about IEEE 754 here is that 754 mandates the inexact bit
> gets set on any of these sequences of instructions. My 66000 accesses
> this functionality through the CARRY instruction, and when so used, does
> not set the inexact bit!

The Augmented* pair operations really should not set inexact unless you
get into borderline operations due to exponent range limits.

I don't remember if this got in as a requirement or just a
recommendation, i.e. there might be implementations actually using
Kahan-style adds internally which do result in inexact on pretty much
all operations.

Terje

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

On Friday, September 10, 2021 at 5:49:51 AM UTC-5, Terje Mathisen wrote:
> MitchAlsup wrote:
> > On Wednesday, September 8, 2021 at 9:47:56 PM UTC-5, Quadibloc wrote:
> >> On Wednesday, September 8, 2021 at 12:17:22 AM UTC-6, Terje Mathisen wrote:
> >>> We are rapidly running out of room even in double, so we are getting hw
> >>> support both for quad (1:15:112) and double-double (via
> >>> AugmentedAddition/AugmentedMultiplication), the latter are useful
> >>> building blocks for extended/arbitrary precision as long as the fixed
> >>> exponent range doesn't become a problem.
> >> I finally looked up quad-double and double-double.
> >>
> >> While I knew that with special instructions, floating-point formats that
> >> allowed unnormalized numbers could be used to perform addition,
> >> subtraction, and multiplication in extended precision (and division
> >> therefore by Newton-Raphson or Goldschmidt), I didn't think it was
> >> even *possible* to use ordinary floating-point instructions which didn't
> >> provide additional information to do floating-point at higher precision
> >> (except through very slow methods involving using floating-point
> >> instructions to do arithmetic at half their precision).
> > <
> > There is a whole subtopic of exact FP arithmetics, that use several FP
> > instructions in a row to perform FP arithmetic without error. Without error
> > means:: all of the bits that didn't make it into the first result got into the
> > second result.
> > <
> > The odd thing about IEEE 754 here is that 754 mandates the inexact bit
> > gets set on any of these sequences of instructions. My 66000 accesses
> > this functionality through the CARRY instruction, and when so used, does
> > not set the inexact bit!
> The Augmented* pair operations really should not set inexact unless you
> get into borderline operations due to exponent range limits.
>
> I don't remember if this got in as a requirement or just a
> recommendation, i.e. there might be implementations actually using
> Kahan-style adds internally which do result in inexact on pretty much
> all operations.
<
Getting the inexact bit correct did not get in as either (require or recommend).
<
> Terje
>
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

MitchAlsup wrote:
> On Friday, September 10, 2021 at 5:49:51 AM UTC-5, Terje Mathisen wrote:
>> MitchAlsup wrote:
>>> On Wednesday, September 8, 2021 at 9:47:56 PM UTC-5, Quadibloc wrote:
>>>> On Wednesday, September 8, 2021 at 12:17:22 AM UTC-6, Terje Mathisen wrote:
>>>>> We are rapidly running out of room even in double, so we are getting hw
>>>>> support both for quad (1:15:112) and double-double (via
>>>>> AugmentedAddition/AugmentedMultiplication), the latter are useful
>>>>> building blocks for extended/arbitrary precision as long as the fixed
>>>>> exponent range doesn't become a problem.
>>>> I finally looked up quad-double and double-double.
>>>>
>>>> While I knew that with special instructions, floating-point formats that
>>>> allowed unnormalized numbers could be used to perform addition,
>>>> subtraction, and multiplication in extended precision (and division
>>>> therefore by Newton-Raphson or Goldschmidt), I didn't think it was
>>>> even *possible* to use ordinary floating-point instructions which didn't
>>>> provide additional information to do floating-point at higher precision
>>>> (except through very slow methods involving using floating-point
>>>> instructions to do arithmetic at half their precision).
>>> <
>>> There is a whole subtopic of exact FP arithmetics, that use several FP
>>> instructions in a row to perform FP arithmetic without error. Without error
>>> means:: all of the bits that didn't make it into the first result got into the
>>> second result.
>>> <
>>> The odd thing about IEEE 754 here is that 754 mandates the inexact bit
>>> gets set on any of these sequences of instructions. My 66000 accesses
>>> this functionality through the CARRY instruction, and when so used, does
>>> not set the inexact bit!
>> The Augmented* pair operations really should not set inexact unless you
>> get into borderline operations due to exponent range limits.
>>
>> I don't remember if this got in as a requirement or just a
>> recommendation, i.e. there might be implementations actually using
>> Kahan-style adds internally which do result in inexact on pretty much
>> all operations.
> <
> Getting the inexact bit correct did not get in as either (require or recommend).

Ouch, sorry!

I'll write this up on the 754 mailing list so that it gets noted for the
next iteration.

Terje

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