MitchAlsup wrote:
> On Wednesday, July 28, 2021 at 2:32:16 PM UTC-5, Michael S wrote:
>> On Wednesday, July 28, 2021 at 8:45:42 PM UTC+3, Anton Ertl wrote:
>>> Marcus <m.de...@this.bitsnbites.eu> writes:
>>>> On 2021-07-27 20:05, Ivan Godard wrote:
>
>>>
>> Out of memory, another difference apart from mixed endianness is that exponent bias differs by one.
>> I don't remember which one is bigger.
> <
> 754 choose an exponent whereby the largest denormal binade does not
> cause overflow when reciprocated.

Right: For any 754 FP format the bias is 0b1111..., i.e. 127/1023 for
float/double, with 1 for the smallest normal number and 254/2046 for the
largest possible exponent before Inf. I.e. an identical exponent range
above and below 1.0

It still means that any sub-normal value can/will overflow to Inf if you
do a reciprocal:

y = 1/x

Terje

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

Marcus <m.delete@this.bitsnbites.eu> wrote:
> On 2021-07-25 19:22, MitchAlsup wrote:
> > On Sunday, July 25, 2021 at 11:14:08 AM UTC-5, BGB wrote:
> >> On 7/25/2021 6:05 AM, Terje Mathisen wrote:
> >>> MitchAlsup wrote:
> >>>> 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.)
> >>>
> >>> I agree.
> >>>
> >>>> d) HW designers have learned how to perform all of the rounding
> >>>> modes at no overhead compared to RNE.
> >>>
> >>> This is actually dead easy since all the other modes are easier than
> >>> RNE: As soon as you have all four bits required for RNE (i.e.
> >>> sign/ulp/guard/sticky) then the remaining rounding modes only need
> >>> various subsets of these, so you use the rounding mode to route one of 5
> >>> or 6 possible 16-entry one-bit lookup tables into the rounding circuit
> >>> where it becomes the input to be added into the ulp position of the
> >>> final packed (sign/exp/mantissa) fp result.
> >>>
> >> Oddly enough, the extra cost to rounding itself is not the main issue
> >> with multiple rounding modes, but more the question of how the bits get
> >> there (if one doesn't already have an FPU status register or similar).
> >>
> >> Granted, could in theory put these bits in SR or similar, but, yeah...
> >>
> >> It would be better IMO if it were part of the instruction, but there
> >> isn't really any good / non-annoying way to encode this.
> > <
> > And this is why they are put in control/status registers.
> > <
>
> There are several problems with this, but the *main* problem is that the
> rounding mode setting becomes a super-global variable. If one subroutine
> touches the register, it affects all code in the same thread. And it's
> "super-global" because it crosses source code and language barriers
> (e.g. consider a program written in Go that has a Python scripting back
> end that calls out to a DLL that is written in C++ that changes the
> floating-point rounding mode...).
>
> As I have accounted for elsewhere, this is a real problem. As a SW
> developer I therefore prefer to work with architectures that do not have
> an FPU control register - /even/ if that means that I can only use RNE
> (because let's face it - that's the only rounding mode I'm ever going
> to use anyway).

Do you use C? On x86 convertion from floating point to integers
were implemented by setting rouding mode and store. Due to C
rules mode was "round towards zero".

> Having the rounding modes as part of the instruction is *much* better
> from a SW developer's perspective - but that blows up opcode space for
> a feature that is never used.

At least for store it may be quite important: on Pentium my FP program
spent about 50% (or more) of time changing rounding modes for convertion
from floats to integers. There was something like 20 FP operations
and the result was converted to integer (this was inside a loop
that iterated many times).

--
Waldek Hebisch

On 7/29/2021 8:22 AM, antispam@math.uni.wroc.pl wrote:
> Marcus <m.delete@this.bitsnbites.eu> wrote:
>> On 2021-07-25 19:22, MitchAlsup wrote:
>>> On Sunday, July 25, 2021 at 11:14:08 AM UTC-5, BGB wrote:
>>>> On 7/25/2021 6:05 AM, Terje Mathisen wrote:
>>>>> MitchAlsup wrote:
>>>>>> 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.)
>>>>>
>>>>> I agree.
>>>>>
>>>>>> d) HW designers have learned how to perform all of the rounding
>>>>>> modes at no overhead compared to RNE.
>>>>>
>>>>> This is actually dead easy since all the other modes are easier than
>>>>> RNE: As soon as you have all four bits required for RNE (i.e.
>>>>> sign/ulp/guard/sticky) then the remaining rounding modes only need
>>>>> various subsets of these, so you use the rounding mode to route one of 5
>>>>> or 6 possible 16-entry one-bit lookup tables into the rounding circuit
>>>>> where it becomes the input to be added into the ulp position of the
>>>>> final packed (sign/exp/mantissa) fp result.
>>>>>
>>>> Oddly enough, the extra cost to rounding itself is not the main issue
>>>> with multiple rounding modes, but more the question of how the bits get
>>>> there (if one doesn't already have an FPU status register or similar).
>>>>
>>>> Granted, could in theory put these bits in SR or similar, but, yeah...
>>>>
>>>> It would be better IMO if it were part of the instruction, but there
>>>> isn't really any good / non-annoying way to encode this.
>>> <
>>> And this is why they are put in control/status registers.
>>> <
>>
>> There are several problems with this, but the *main* problem is that the
>> rounding mode setting becomes a super-global variable. If one subroutine
>> touches the register, it affects all code in the same thread. And it's
>> "super-global" because it crosses source code and language barriers
>> (e.g. consider a program written in Go that has a Python scripting back
>> end that calls out to a DLL that is written in C++ that changes the
>> floating-point rounding mode...).
>>
>> As I have accounted for elsewhere, this is a real problem. As a SW
>> developer I therefore prefer to work with architectures that do not have
>> an FPU control register - /even/ if that means that I can only use RNE
>> (because let's face it - that's the only rounding mode I'm ever going
>> to use anyway).
>
> Do you use C? On x86 convertion from floating point to integers
> were implemented by setting rouding mode and store. Due to C
> rules mode was "round towards zero".
>

If one has an ISA with hard-coded rounding modes, then the instruction
for converting to integer can itself be defined as either
truncate-towards-zero or round towards negative infinity.

Though, FWIW, the rounding the conversions towards negative infinity
might have made more sense and been less annoying:
0.5 -> 0
-0.5 -> -1
...

But, alas, this is one of those "if you poke this, software will break"
areas...

Sort of stuck with it in much the same way as integer promotions
favoring promotion to unsigned types rather than to signed types.

Though, seemingly as absurd as it is, the promotion to unsigned
typically makes more sense in the contexts where it comes up than
promotion to signed would have.

>> Having the rounding modes as part of the instruction is *much* better
>> from a SW developer's perspective - but that blows up opcode space for
>> a feature that is never used.
>
> At least for store it may be quite important: on Pentium my FP program
> spent about 50% (or more) of time changing rounding modes for convertion
> from floats to integers. There was something like 20 FP operations
> and the result was converted to integer (this was inside a loop
> that iterated many times).
>

I have vague memories of one time where a loop was doing conversions of
this sort. The compiler resorted to doing autovectorization which
produced something sufficiently awful (some gigantic mess of vector
operations) that it was actually faster to do the type conversion via a
function call which did the conversion via manual bit twiddling (which
at least defeated the vectorization).

There were pragmas that were supposed to turn the autovectorization off,
but they were not working...

This sort of thing has led me to have a negative position towards
autovectorization, as sometimes it helps, but often it makes things a
lot worse. If it were up to me, things like vectorization and loop
unrolling would have explicit attributes, say:
[[unroll]] for(i=0; i<10; i++) { do_something; }
[[no_unroll]] for(i=0; i<10; i++) { do_something; }

Where, the former requests that the compiler do this, and the latter
forbids it (by extension, it would also forbid things like
autovectorization).

On 2021-07-28 21:53, Quadibloc wrote:
> On Wednesday, July 28, 2021 at 8:03:21 AM UTC-6, Marcus wrote:
>
>> My interpretation of the situation is that IEEE 754 was largely inspired
>> by x87 (and similar architectures), and later IEEE 754 conformant
>> implementations mimicked that design (in order to be standard
>> compliant, if nothing else).
>
> As this is _basically_ true, I saw no need to correct you, but since
> other people have, but their corrections are... in my view, somewhat
> incomplete... I now think I need to speak up.

Thanks for the clarifications! I was mostly extrapolating...

But I think that my point still stands: Back when the original IEEE 754
standard was written, using an RM register was in line with contemporary
hardware designs (and their constraints & goals).

However, I claim that such an approach is outdated, if not from a
hardware perspective, at least from a software development perspective.

While an RM register /can/ be used in a way that guarantees predictable
behavior, /if/ you add stringent mechanisms in programming languages and
ABI:s (which is unfortunately largely missing ATM), it is still a very
large and loaded gun aiming at your feet [1].

On the other hand, if you encode the rounding mode as part of the
instruction you are 100% guaranteed to get predictable and intended
behavior.

>
> Intel's 8087 did not pre-date the IEEE 754 standard.
>
> But Intel was working on the 8087 at the time that the IEEE 754
> standard was being drawn up. And what it presented to the committee
> drawing it up was basically the *specification* for the 8087.
>
> Which they adopted, minus a few of the rounding modes that the
> original 8087 provided.
>
> This was despite the fact that until Intel got their patents in hand,
> Kahan wasn't able to reveal that, yes, it was actually possible to
> achieve the perfect rounding that it was desired to include in the
> standard. But eventually the secret of guard, round, and sticky
> did get revealed in time.
>
> John Savard
>

[1]
https://blog.aopa.org/aopa/wp-content/uploads/2016/06/how_to_shoot_yourself_in_the_foot.jpg

antispam@math.uni.wroc.pl wrote:
> Marcus <m.delete@this.bitsnbites.eu> wrote:
>> As I have accounted for elsewhere, this is a real problem. As a SW
>> developer I therefore prefer to work with architectures that do not have
>> an FPU control register - /even/ if that means that I can only use RNE
>> (because let's face it - that's the only rounding mode I'm ever going
>> to use anyway).
>
> Do you use C? On x86 convertion from floating point to integers
> were implemented by setting rouding mode and store. Due to C
> rules mode was "round towards zero".
>
>> Having the rounding modes as part of the instruction is *much* better
>> from a SW developer's perspective - but that blows up opcode space for
>> a feature that is never used.
>
> At least for store it may be quite important: on Pentium my FP program
> spent about 50% (or more) of time changing rounding modes for convertion
> from floats to integers. There was something like 20 FP operations
> and the result was converted to integer (this was inside a loop
> that iterated many times).

At this point you should consider using an old hack: Assuming your input
values does not need the full 53-bit range, you can add a FP bias value
(typically 2^53 or a binary power larger than the maximum input), store
to memory and extract the integer part from the FP mantissa with shift &
mask.

Terje

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

In article <sdua2r$avt$1@z-news.wcss.wroc.pl>, antispam@math.uni.wroc.pl
() wrote:

> Do you use C? On x86 convertion from floating point to integers
> were implemented by setting rouding mode and store. Due to C
> rules mode was "round towards zero".

> At least for store it may be quite important: on Pentium my FP
> program spent about 50% (or more) of time changing rounding modes
> for convertion from floats to integers.

This was fixed with the SSE2 instruction set extension, in 2001. SSE2 has
conversion instructions specifically for C. Even Microsoft have changed
the default floating-point instruction set to SSE2, as of Visual Studio
2015.

John

On Thursday, July 29, 2021 at 12:16:45 PM UTC-5, Marcus wrote:
> On 2021-07-28 21:53, Quadibloc wrote:
> > On Wednesday, July 28, 2021 at 8:03:21 AM UTC-6, Marcus wrote:
> >
> >> My interpretation of the situation is that IEEE 754 was largely inspired
> >> by x87 (and similar architectures), and later IEEE 754 conformant
> >> implementations mimicked that design (in order to be standard
> >> compliant, if nothing else).
> >
> > As this is _basically_ true, I saw no need to correct you, but since
> > other people have, but their corrections are... in my view, somewhat
> > incomplete... I now think I need to speak up.
<
> Thanks for the clarifications! I was mostly extrapolating...
>
> But I think that my point still stands: Back when the original IEEE 754
> standard was written, using an RM register was in line with contemporary
> hardware designs (and their constraints & goals).
>
> However, I claim that such an approach is outdated, if not from a
> hardware perspective, at least from a software development perspective.
>
> While an RM register /can/ be used in a way that guarantees predictable
> behavior, /if/ you add stringent mechanisms in programming languages and
> ABI:s (which is unfortunately largely missing ATM), it is still a very
> large and loaded gun aiming at your feet [1].
>
> On the other hand, if you encode the rounding mode as part of the
> instruction you are 100% guaranteed to get predictable and intended
> behavior.
<
How do you compile::
<
for( i = 0 i < max i+=4 )
{ setRoundingMode(rm[i]);
a = b + c;
setRoundingMode(rm[i+1]);
d = a * f;
setRoundingMode(rm[i+2]);
b = d / g;
setRoundingMode(rm[i+4]);
c = sqrt( d*b );
} using instruction only rounding modes ?
> >
> > Intel's 8087 did not pre-date the IEEE 754 standard.
> >
> > But Intel was working on the 8087 at the time that the IEEE 754
> > standard was being drawn up. And what it presented to the committee
> > drawing it up was basically the *specification* for the 8087.
> >
> > Which they adopted, minus a few of the rounding modes that the
> > original 8087 provided.
> >
> > This was despite the fact that until Intel got their patents in hand,
> > Kahan wasn't able to reveal that, yes, it was actually possible to
> > achieve the perfect rounding that it was desired to include in the
> > standard. But eventually the secret of guard, round, and sticky
> > did get revealed in time.
> >
> > John Savard
> >
> [1]
> https://blog.aopa.org/aopa/wp-content/uploads/2016/06/how_to_shoot_yourself_in_the_foot.jpg

On 2021-07-29 20:35, MitchAlsup wrote:
> On Thursday, July 29, 2021 at 12:16:45 PM UTC-5, Marcus wrote:
>> On 2021-07-28 21:53, Quadibloc wrote:
>>> On Wednesday, July 28, 2021 at 8:03:21 AM UTC-6, Marcus wrote:
>>>
>>>> My interpretation of the situation is that IEEE 754 was largely inspired
>>>> by x87 (and similar architectures), and later IEEE 754 conformant
>>>> implementations mimicked that design (in order to be standard
>>>> compliant, if nothing else).
>>>
>>> As this is _basically_ true, I saw no need to correct you, but since
>>> other people have, but their corrections are... in my view, somewhat
>>> incomplete... I now think I need to speak up.
> <
>> Thanks for the clarifications! I was mostly extrapolating...
>>
>> But I think that my point still stands: Back when the original IEEE 754
>> standard was written, using an RM register was in line with contemporary
>> hardware designs (and their constraints & goals).
>>
>> However, I claim that such an approach is outdated, if not from a
>> hardware perspective, at least from a software development perspective.
>>
>> While an RM register /can/ be used in a way that guarantees predictable
>> behavior, /if/ you add stringent mechanisms in programming languages and
>> ABI:s (which is unfortunately largely missing ATM), it is still a very
>> large and loaded gun aiming at your feet [1].
>>
>> On the other hand, if you encode the rounding mode as part of the
>> instruction you are 100% guaranteed to get predictable and intended
>> behavior.
> <
> How do you compile::
> <
> for( i = 0 i < max i+=4 )
> {
> setRoundingMode(rm[i]);
> a = b + c;
> setRoundingMode(rm[i+1]);
> d = a * f;
> setRoundingMode(rm[i+2]);
> b = d / g;
> setRoundingMode(rm[i+4]);
> c = sqrt( d*b );
> }
> using instruction only rounding modes ?

You don't (at least not in that exact form). You would have to
explicitly code the dynamic part using a switch/case statement or such,
same as you would do if you wanted to dynamically select single
precision or double-precision.

....and forgive me for saying so, but the example feels kind of silly. I
doubt that it would ever end up in production code (if someone would
need to do something similar in a performant manner, JIT would probably
be a more suitable solution). In experimental code (e.g. to explore
rounding & precision influences on an algorithm), I might have used a
more flexible solution like Fabrice Bellard's SoftFP [1] or LibBF [2].

/Marcus

[1] https://bellard.org/softfp/
[2] https://bellard.org/libbf/

>>>
>>> Intel's 8087 did not pre-date the IEEE 754 standard.
>>>
>>> But Intel was working on the 8087 at the time that the IEEE 754
>>> standard was being drawn up. And what it presented to the committee
>>> drawing it up was basically the *specification* for the 8087.
>>>
>>> Which they adopted, minus a few of the rounding modes that the
>>> original 8087 provided.
>>>
>>> This was despite the fact that until Intel got their patents in hand,
>>> Kahan wasn't able to reveal that, yes, it was actually possible to
>>> achieve the perfect rounding that it was desired to include in the
>>> standard. But eventually the secret of guard, round, and sticky
>>> did get revealed in time.
>>>
>>> John Savard
>>>
>> [1]
>> https://blog.aopa.org/aopa/wp-content/uploads/2016/06/how_to_shoot_yourself_in_the_foot.jpg

On 7/29/2021 12:17 PM, Terje Mathisen wrote:
> antispam@math.uni.wroc.pl wrote:
>> Marcus <m.delete@this.bitsnbites.eu> wrote:
>>> As I have accounted for elsewhere, this is a real problem. As a SW
>>> developer I therefore prefer to work with architectures that do not have
>>> an FPU control register - /even/ if that means that I can only use RNE
>>> (because let's face it - that's the only rounding mode I'm ever going
>>> to use anyway).
>>
>> Do you use C?  On x86 convertion from floating point to integers
>> were implemented by setting rouding mode and store.  Due to C
>> rules mode was "round towards zero".
>>
>>> Having the rounding modes as part of the instruction is *much* better
>>> from a SW developer's perspective - but that blows up opcode space for
>>> a feature that is never used.
>>
>> At least for store it may be quite important: on Pentium my FP program
>> spent about 50% (or more) of time changing rounding modes for convertion
>> from floats to integers.  There was something like 20 FP operations
>> and the result was converted to integer (this was inside a loop
>> that iterated many times).
>
> At this point you should consider using an old hack: Assuming your input
> values does not need the full 53-bit range, you can add a FP bias value
> (typically 2^53 or a binary power larger than the maximum input), store
> to memory and extract the integer part from the FP mantissa with shift &
> mask.
>

FWIW...

This is actually more or less how my FPU itself implements Float->Int
conversion. It adds a large synthetic value and then extracts the value
from the mantissa, though its value is a little bigger as it can make
use of the intermediate mantissa being large enough to hold a 64-bit
integer value.

It can then extract the output value from the mantissa.
Of course, this mechanism breaks down if the value goes sufficiently far
outside the 64-bit integer range.

A similar process can also be used for Int->Float, just it is an FADD
between a synthetic large denormal value (hidden bit is 0) and a zero.
The FADD's renormalizer then fixes it up on the output side.

In a few edge cases like this, it could be useful to be able to encode
such large denormals as inputs to other operations, but alas. No real
way to do this within the IEEE formats.

> Terje
>

Terje Mathisen <terje.mathisen@tmsw.no> wrote:
> antispam@math.uni.wroc.pl wrote:
> > Marcus <m.delete@this.bitsnbites.eu> wrote:
> >> As I have accounted for elsewhere, this is a real problem. As a SW
> >> developer I therefore prefer to work with architectures that do not have
> >> an FPU control register - /even/ if that means that I can only use RNE
> >> (because let's face it - that's the only rounding mode I'm ever going
> >> to use anyway).
> >
> > Do you use C? On x86 convertion from floating point to integers
> > were implemented by setting rouding mode and store. Due to C
> > rules mode was "round towards zero".
> >
> >> Having the rounding modes as part of the instruction is *much* better
> >> from a SW developer's perspective - but that blows up opcode space for
> >> a feature that is never used.
> >
> > At least for store it may be quite important: on Pentium my FP program
> > spent about 50% (or more) of time changing rounding modes for convertion
> > from floats to integers. There was something like 20 FP operations
> > and the result was converted to integer (this was inside a loop
> > that iterated many times).
>
> At this point you should consider using an old hack: Assuming your input
> values does not need the full 53-bit range, you can add a FP bias value
> (typically 2^53 or a binary power larger than the maximum input), store
> to memory and extract the integer part from the FP mantissa with shift &
> mask.

For me rounding to nearest was preferable compared to C rule. Various
C rounding functions came later, so at first I used pure C with C
rule. When I identified the problem I replaced assignment in C
by gcc inline assemby doing the store in default round to nearest
mode...

--
Waldek Hebisch

On Thursday, July 29, 2021 at 1:59:56 PM UTC-5, Marcus wrote:
> On 2021-07-29 20:35, MitchAlsup wrote:
> > On Thursday, July 29, 2021 at 12:16:45 PM UTC-5, Marcus wrote:
> >> On 2021-07-28 21:53, Quadibloc wrote:
> >>> On Wednesday, July 28, 2021 at 8:03:21 AM UTC-6, Marcus wrote:
> >>>
> >>>> My interpretation of the situation is that IEEE 754 was largely inspired
> >>>> by x87 (and similar architectures), and later IEEE 754 conformant
> >>>> implementations mimicked that design (in order to be standard
> >>>> compliant, if nothing else).
> >>>
> >>> As this is _basically_ true, I saw no need to correct you, but since
> >>> other people have, but their corrections are... in my view, somewhat
> >>> incomplete... I now think I need to speak up.
> > <
> >> Thanks for the clarifications! I was mostly extrapolating...
> >>
> >> But I think that my point still stands: Back when the original IEEE 754
> >> standard was written, using an RM register was in line with contemporary
> >> hardware designs (and their constraints & goals).
> >>
> >> However, I claim that such an approach is outdated, if not from a
> >> hardware perspective, at least from a software development perspective.
> >>
> >> While an RM register /can/ be used in a way that guarantees predictable
> >> behavior, /if/ you add stringent mechanisms in programming languages and
> >> ABI:s (which is unfortunately largely missing ATM), it is still a very
> >> large and loaded gun aiming at your feet [1].
> >>
> >> On the other hand, if you encode the rounding mode as part of the
> >> instruction you are 100% guaranteed to get predictable and intended
> >> behavior.
> > <
> > How do you compile::
> > <
> > for( i = 0 i < max i+=4 )
> > {
> > setRoundingMode(rm[i]);
> > a = b + c;
> > setRoundingMode(rm[i+1]);
> > d = a * f;
> > setRoundingMode(rm[i+2]);
> > b = d / g;
> > setRoundingMode(rm[i+4]);
> > c = sqrt( d*b );
> > }
> > using instruction only rounding modes ?
> You don't (at least not in that exact form). You would have to
> explicitly code the dynamic part using a switch/case statement or such,
> same as you would do if you wanted to dynamically select single
> precision or double-precision.
>
> ...and forgive me for saying so, but the example feels kind of silly. I
> doubt that it would ever end up in production code
<
As noted above this is not for production code it is a test over the
algorithm to see if the algorithm is sufficiently stable to make it into
production code.
<
< (if someone would
> need to do something similar in a performant manner, JIT would probably
> be a more suitable solution). In experimental code (e.g. to explore
> rounding & precision influences on an algorithm), I might have used a
> more flexible solution like Fabrice Bellard's SoftFP [1] or LibBF [2].
>
> /Marcus
>
> [1] https://bellard.org/softfp/
> [2] https://bellard.org/libbf/
> >>>
> >>> Intel's 8087 did not pre-date the IEEE 754 standard.
> >>>
> >>> But Intel was working on the 8087 at the time that the IEEE 754
> >>> standard was being drawn up. And what it presented to the committee
> >>> drawing it up was basically the *specification* for the 8087.
> >>>
> >>> Which they adopted, minus a few of the rounding modes that the
> >>> original 8087 provided.
> >>>
> >>> This was despite the fact that until Intel got their patents in hand,
> >>> Kahan wasn't able to reveal that, yes, it was actually possible to
> >>> achieve the perfect rounding that it was desired to include in the
> >>> standard. But eventually the secret of guard, round, and sticky
> >>> did get revealed in time.
> >>>
> >>> John Savard
> >>>
> >> [1]
> >> https://blog.aopa.org/aopa/wp-content/uploads/2016/06/how_to_shoot_yourself_in_the_foot.jpg

On Thursday, July 29, 2021 at 1:58:39 PM UTC-6, anti...@math.uni.wroc.pl wrote:

> For me rounding to nearest was preferable compared to C rule.

I should think that it would be for *anyone*. Certainly it would be
for Fortran programmers, some of whom have to make do with
C instead due to availability issues.

What on Earth possessed them to make such a rule for C?

Of course, the System/360's rounding mode was truncation,
similar or equivalent to round towards zero (given that floating-point
was sign-magnitude) and I suppose that it may avoid some issues
in converting to integer or something like that, though I thought it
was just ease of implementation.

And, of course, the C language long predates the 8087 and the
IEEE 754 standard, and so what would be the point of specifying
a rounding mode, when at the time most computers did not _have_
a choice of rounding modes?

I suppose they could have added that part of the C standard
after the Kernaghan and Ritchie days, though, since they
definitely made _other_ changes to C since then.

John Savard

Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Thursday, July 29, 2021 at 1:58:39 PM UTC-6, anti...@math.uni.wroc.pl wrote:
>
> > For me rounding to nearest was preferable compared to C rule.
>
> I should think that it would be for *anyone*. Certainly it would be
> for Fortran programmers, some of whom have to make do with
> C instead due to availability issues.
>
> What on Earth possessed them to make such a rule for C?
>
> Of course, the System/360's rounding mode was truncation,
> similar or equivalent to round towards zero (given that floating-point
> was sign-magnitude) and I suppose that it may avoid some issues
> in converting to integer or something like that, though I thought it
> was just ease of implementation.
>
> And, of course, the C language long predates the 8087 and the
> IEEE 754 standard, and so what would be the point of specifying
> a rounding mode, when at the time most computers did not _have_
> a choice of rounding modes?

Anybody knows what PDP-11 did?

> I suppose they could have added that part of the C standard
> after the Kernaghan and Ritchie days, though, since they
> definitely made _other_ changes to C since then.

The rule is in my copy of (translation of) orignal K&R book.

--
Waldek Hebisch

On Thursday, July 29, 2021 at 4:49:00 PM UTC-5, Quadibloc wrote:
> On Thursday, July 29, 2021 at 1:58:39 PM UTC-6, anti...@math.uni.wroc.pl wrote:
>
> > For me rounding to nearest was preferable compared to C rule.
> I should think that it would be for *anyone*. Certainly it would be
> for Fortran programmers, some of whom have to make do with
> C instead due to availability issues.
<
FORTRAN programmers have had INT, CEIL, FLOOR, TRUNC, and NINT since
I learned FORTRAN in 1969.
>
> What on Earth possessed them to make such a rule for C?
<
principle of least surprise creates greater average surprise !
>
> Of course, the System/360's rounding mode was truncation,
> similar or equivalent to round towards zero (given that floating-point
> was sign-magnitude) and I suppose that it may avoid some issues
> in converting to integer or something like that, though I thought it
> was just ease of implementation.
<
Yes S/360 had no problem in implementing INT, CEIL, FLOOR, TRUNC, and NINT
>
> And, of course, the C language long predates the 8087 and the
> IEEE 754 standard, and so what would be the point of specifying
> a rounding mode, when at the time most computers did not _have_
> a choice of rounding modes?
<
While choice of rounding mode is new-ish, the ability to specify the
kind of rounding in FP->integer conversions goes WAY BACK.
>
> I suppose they could have added that part of the C standard
> after the Kernaghan and Ritchie days, though, since they
> definitely made _other_ changes to C since then.
>
> John Savard

On Thursday, July 29, 2021 at 5:18:16 PM UTC-5, anti...@math.uni.wroc.pl wrote:
> Quadibloc <jsa...@ecn.ab.ca> wrote:
> > On Thursday, July 29, 2021 at 1:58:39 PM UTC-6, anti...@math.uni.wroc.pl wrote:
> >
> > > For me rounding to nearest was preferable compared to C rule.
> >
> > I should think that it would be for *anyone*. Certainly it would be
> > for Fortran programmers, some of whom have to make do with
> > C instead due to availability issues.
> >
> > What on Earth possessed them to make such a rule for C?
> >
> > Of course, the System/360's rounding mode was truncation,
> > similar or equivalent to round towards zero (given that floating-point
> > was sign-magnitude) and I suppose that it may avoid some issues
> > in converting to integer or something like that, though I thought it
> > was just ease of implementation.
> >
> > And, of course, the C language long predates the 8087 and the
> > IEEE 754 standard, and so what would be the point of specifying
> > a rounding mode, when at the time most computers did not _have_
> > a choice of rounding modes?
<
> Anybody knows what PDP-11 did?
<
DPD-11 had a control/status register, and a bit in that status register
when 0 indicated round and when 1 indicated truncate.
<
Other bits were generally for interrupt enables and the FP condition codes.
<
> > I suppose they could have added that part of the C standard
> > after the Kernaghan and Ritchie days, though, since they
> > definitely made _other_ changes to C since then.
<
> The rule is in my copy of (translation of) orignal K&R book.
>
> --
> Waldek Hebisch

On Thursday, July 29, 2021 at 4:28:25 PM UTC-6, MitchAlsup wrote:

> Yes S/360 had no problem in implementing INT, CEIL, FLOOR, TRUNC, and NINT

Are we talking about two different things here?

Of course there were functions in FORTRAN to produce the nearest
integer to a floating-point number... but rounding modes that applied
to every calculation? I did not think the S/360 had any such feature -
it was strictly truncation, even after they at least put in a guard digit.

John Savard

On Thursday, July 29, 2021 at 4:28:25 PM UTC-6, MitchAlsup wrote:

> While choice of rounding mode is new-ish, the ability to specify the
> kind of rounding in FP->integer conversions goes WAY BACK.

Well, of course, but that is something entirely different, and doesn't
affect how lengthy floating-point computations preserve accuracy.

John Savard

MitchAlsup <MitchAlsup@aol.com> writes:

> On Thursday, July 29, 2021 at 4:49:00 PM UTC-5, Quadibloc wrote:
>
>> On Thursday, July 29, 2021 at 1:58:39 PM UTC-6,
>> anti...@math.uni.wroc.pl wrote:
>>
>>> For me rounding to nearest was preferable compared to C rule.
>>
>> I should think that it would be for *anyone*. Certainly it would be
>> for Fortran programmers, some of whom have to make do with
>> C instead due to availability issues.
>
> FORTRAN programmers have had INT, CEIL, FLOOR, TRUNC, and NINT since
> I learned FORTRAN in 1969.
>
>> What on Earth possessed them to make such a rule for C?
>
> principle of least surprise creates greater average surprise !

The C Rationale document says this:

There was strong agreement in the C89 Committee that
floating values should truncate toward zero when converted
to an integer type, the specification adopted in the
Standard. Although K&R permitted negative floating values
to truncate away from zero, no C89 Committee member knew of
an implementation that functioned in such a manner.

Since the purpose of the C standardization effort was to describe
the language as it then currently existed, and not to define a
new language, C89/C90 kept this rule.

C99 added functions in <math.h> for converting floating values to
integer values that do various kinds of rounding, including some
that do rounding according to the current rounding direction.

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.

John Savard

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.

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.

More people are more likely to care that everything looks as it should
from C, than they are about rarely-used edge cases in the IEEE standard.

Granted, if I were to try for a bit-exact FPU design, it would more
likely focus on making everything truncate-towards-zero, as it is a
little easier to achieve bit-exact results with truncation than with
Round-Nearest-Even or similar.

Though, there are limits:
Partial width FMUL is still subject to long chains of ones in the result
changing the result of the FMUL if low-order multipliers are omitted.

In theory, one could hack around this by checking for some special cases
and predicting whether low-order results could produce results which
result in a carry (via lookup tables).

One possibility for lookup tables would be two or three levels of 3*3 ->
2, which figure out whether the MSB is 0, 1, or depends on the next
lower result. These would in-turn be fed into a lookup table to produce
an answer.

2-bit outputs:
00 = MSB is Clear (eg: 4*5)
01 = A&B has MSB Set, A*B Depends on next lower result
10 = A&B has MSB Set, A*B does Not
11 = Both A&B and A*B have MSB Set

And, further reductions:
00,zz = 00
01,00 = 01
01,01 = 11
01,10 = 11
01,11 = 11
10,zz = 10
11,zz = 11
01,00,00 = 10
01,00,01 = 11
01,00,10 = 01
01,00,11 = 11
....

With another LUT answering whether or not the adders would produce a
carry, ...

This would still be inexact though (reduces the probability of an
inexact result, but does not eliminate it; given this is, at best, an
approximation).

On Monday, July 26, 2021 at 11:13:34 PM UTC-6, Quadibloc wrote:

> A while back, there was a discussion of base-3 logic. While
> I didn't think that would ever fly, I thought that using base 3
> for the pins of memory modules - so that two wires could carry
> 3 bits, with one of the 9 combinations unused - might be a
> good idea.

> That would be simpler than GDDR6x, which almost requires
> a mini-A/D converter on each data pin!

> The trouble is, though, that memory modules that contain
> 96-bit memory lines are less easily used in our power-of-two
> world.

> But now I've figured out how DDR4w, as we might call it,
> w because it's one less than x, 3 instead of 4 signal levels...
> could be useful.

> Have a three-channel memory built up of DDR4w modules.

> Now we have a factor of 3 due to the memory, and another
> factor of 3 due to the number of channels. So one could
> build a computer built around a 36-bit word, and yet it could
> use ordinary sockets for ordinary-looking memory modules!

> And use five-channel memory if you want a computer with a
> 60-bit word, or single, double, or quad channel for a 48-bit
> word!!

> Suddenly, diversity is returned to the world of the computer,
> and the tyranny of the 8-bit byte is ended!!

Of course, this is a crazy idea.

But in the *real* world, a recent leak has revealed that
Intel's forthcoming Thunderbolt 5 standard will indeed
use PAM-3 modulation, with three signal states per
baud, in order to increase bandwidth!

So ternary does live...

John Savard

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.

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

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}