On Tuesday, July 27, 2021 at 4:10:53 PM UTC-6, Quadibloc wrote:
> On Tuesday, July 27, 2021 at 12:14:36 PM UTC-6, Ivan Godard wrote:
> > On 7/27/2021 10:32 AM, MitchAlsup wrote:

> > > Do you still pick 3 if the average instruction went from 32-bits in size to
> > > 37 bits in size ?

> > Come on, no straw men please. If adding 3 bits to a dozen opcodes pushes
> > the average of the whole ISA from 32 to 37 bits then you have bigger
> > encoding problems than FP rounding.

> Well, I'm going to assume that a typical architecture doesn't have bit
> addressing.
> So if one makes a few instructions longer to specify the FP rounding
> mode, they're going to be 8 bits longer or 16 bits longer or even 32
> bits longer - not 3 bits longer.
> Would that make the average instruction 5 bits longer?
> If you're doing a lot of floating-point arithmetic, at least in the third
> case, it _could_.

In previous iterations of the Concertina II architecture, I used a few
bits in my block headers to indicate that the FP instructions used an
alternate set of lengths for floating-point operands. Now I might bring
a similar feature back, but to indicate the *rounding mode*.

That would avoid problems due to 16-bit instruction granularity - three
otherwise unused bits would specify the same rounding mode for
all the FP instructions in a block, which would work if one wants an
entire routine to use a consistent but non-default rounding mode.

John Savard

On Tuesday, July 27, 2021 at 1:14:36 PM UTC-5, Ivan Godard wrote:
> On 7/27/2021 10:32 AM, MitchAlsup wrote:
> > On Tuesday, July 27, 2021 at 4:54:15 AM UTC-5, Marcus wrote:
> >> On 2021-07-26 18:19, MitchAlsup wrote:
> >>> On Monday, July 26, 2021 at 2:27:54 AM UTC-5, Marcus 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.
> >>> <
> >>> Given that they cannot be in a GPR or an FPR, Oh wise one,
> >>> Where would you put them ?
> >>> <
> >> At the same place that we specify the floating-point precision: in the
> >> instruction.
> >>>> 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
> >>> <
> >>> But does not cross thread or task boundaries. So its not "like memory" either.
> >>> <
> >>>> (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).
> >>> <
> >>> So you discount libraries that may contain interval arithmetic or properly
> >>> rounded transcendentals ?
> >> You might have misunderstood my point. As a software developer, if I
> >> have a choice between:
> >>
> >> 1. Rounding mode is configured in a thread global register.
> >> 2. Rounding mode is always RNE.
> >>
> >> ...then I pick 2, because that gives me 100% predictable results,
> >> whereas with 1 all bets are off (read my other examples as to why this
> >> is the case).
> >>
> >> *However*, if there is also the option:
> >>
> >> 3. Rounding mode is part of the instruction.
> >>
> >> ...then I pick 3.
> > <
> > Do you still pick 3 if the average instruction went from 32-bits in size to
> > 37 bits in size ?
<
> Come on, no straw men please. If adding 3 bits to a dozen opcodes pushes
> the average of the whole ISA from 32 to 37 bits then you have bigger
> encoding problems than FP rounding.
<
You may work in a space where the instruction container size is a free
variable; almost nobody else does. So if a few percent of your instruction
stream needs feature x and feature x requires another whole 32-bit container,
then it is not just the 3-bits that get counted it is also the overhead of the
delivery mechanism.
>
> Five modes times 12 opcodes adds 60 models to an existing ~1500, or
> something like 2% of a bit to the entropy. If you can't do it in under a
> bit then you should change your encoding to fix the crappy entropy
> utilization.
<
I am acutely aware of entropy................

On Tuesday, July 27, 2021 at 1:05:33 PM UTC-5, Ivan Godard wrote:
> On 7/27/2021 10:30 AM, MitchAlsup wrote:

> > Not said but I believe you mean::
> > <
> > withMode<RNA>{ doSomething(); }
> > <
> > to be::
> > {setRoundingMode(dyn); { doSomething(); } setRoundingMode(RNE);}
<
> No, I don't mean that. I mean a true scope, like with
> constructor/destructors, so that the mode is restored even if you goto
> out of the {}, or throw/longjmp out of it. You are not forcing the mode
> at the "}" to RNE, you are restoring it to whatever it was in the
> surrounding scope.
<
So you mean::
<
{oldRM=getRoundingMode();setRoundingMode(dyn); { doSomething(); } setRoundingMode(oldRM);}
<
>
> A macro paint job on a global variable won't do.
> > <
> > In any event, when the RM part of your FP control register is passed as
> > an operand to the FP units, it can be changed without pipeline flushes
> > with either simply interlocks (boo) or as another operand in the Reservation
> > stations (a lot less of a boo).
> > <
> > In any event::
> > How does one without a RM field in some control register obey 9.3.1 ?
> > and 9.3.2 ?
> >

On Tuesday, July 27, 2021 at 1:29:22 PM UTC-5, BGB wrote:
> On 7/27/2021 4:54 AM, Marcus wrote:

> > Does the compiler have to generate code for foo() in binary16, binary32,
> > binary64 and binary128? No. The developer selects the precision and
> > rounding mode(s). The developer knows what rounding mode to use for a
> > particular algorithm.
> >
> Agreed.
>
> Though, one could imagine a situation where ABI-level register handling
> gets messed up (say, because the official ABI and GCC disagreed as to
> whose responsibility it is to save/restore the register), and the
> decoded FPU instructions effectively get turned into confetti.
> >>>
> >>> Perhaps your prefix instruction paradigm could be used for this (e.g.
> >>> like "CARRY")?
> >> <
> >> If I wanted 'per instruction RMs' this would be how I did it. A
> >> CARRY-like
> >> RM-instruction-modifier could cast RM over 5-ish subsequent instructions.
> >
> > Sounds reasonable.
> >
<snip>
> >
> > The use case given here sounds like it has more to do with experimenting
> > with different settings than to actually generate production code. As
> > such it would be easy to just re-compile the source code with different
> > rounding mode settings. I occasionally do this when experimenting with
> > different floating-point precisions (usually single precision vs
> > double-precision), e.g. using a C DEFINE.
> >
> Bigger question is what is the best way to go about telling the C
> compiler to use a non-default rounding.
<
IEEE 754-2019 says to use::
<
binaryRoundingDirection oldRM = getBinaryRoundingDirection(void)
and
void setBinaryRoundingDirection(binaryRoundingDirection)
<
What has not yet happened is for C (and many other languages) to decide
if this feature is static/threadLocal/global or whether it is embedded in scope:
<
withMode<RNA>{ doSomething(); }
<

On 7/27/2021 4:09 PM, MitchAlsup wrote:
> On Tuesday, July 27, 2021 at 1:05:33 PM UTC-5, Ivan Godard wrote:
>> On 7/27/2021 10:30 AM, MitchAlsup wrote:
>
>>> Not said but I believe you mean::
>>> <
>>> withMode<RNA>{ doSomething(); }
>>> <
>>> to be::
>>> {setRoundingMode(dyn); { doSomething(); } setRoundingMode(RNE);}
> <
>> No, I don't mean that. I mean a true scope, like with
>> constructor/destructors, so that the mode is restored even if you goto
>> out of the {}, or throw/longjmp out of it. You are not forcing the mode
>> at the "}" to RNE, you are restoring it to whatever it was in the
>> surrounding scope.
> <
> So you mean::
> <
> {oldRM=getRoundingMode();setRoundingMode(dyn); { doSomething(); } setRoundingMode(oldRM);}

No. that would leave the mode in a random state if doSomething threw or
longjmp'd out of the outer "{}".

You cannot turn a global variable into a scoped region. In C++ you could
code it as:
class modeSaver {
roundingMode old;
modeSaver(roundingMode rm) : old(getRoundingMode()){
setRoundingMode(rm);}
~modeSaver() { setRoundingMode(rold); }
}

{ modeSaver save(RNA); doSomething(); }

But that piggybacks on a scoped notion that the language already has.

On 7/27/2021 3:10 PM, Quadibloc wrote:
> On Tuesday, July 27, 2021 at 12:14:36 PM UTC-6, Ivan Godard wrote:
>> On 7/27/2021 10:32 AM, MitchAlsup wrote:
>
>>> Do you still pick 3 if the average instruction went from 32-bits in size to
>>> 37 bits in size ?
>
>> Come on, no straw men please. If adding 3 bits to a dozen opcodes pushes
>> the average of the whole ISA from 32 to 37 bits then you have bigger
>> encoding problems than FP rounding.
>
> Well, I'm going to assume that a typical architecture doesn't have bit
> addressing.
> So if one makes a few instructions longer to specify the FP rounding
> mode, they're going to be 8 bits longer or 16 bits longer or even 32
> bits longer - not 3 bits longer.

Typical architectures have broken and wasteful encoding.

> Would that make the average instruction 5 bits longer?
> If you're doing a lot of floating-point arithmetic, at least in the third
> case, it _could_.

Only if you insist on encoding bits instead of entropy. But that's not a
fault of rounding modes.

On 7/27/2021 4:07 PM, MitchAlsup wrote:
> On Tuesday, July 27, 2021 at 1:14:36 PM UTC-5, Ivan Godard wrote:
>> On 7/27/2021 10:32 AM, MitchAlsup wrote:
>>> On Tuesday, July 27, 2021 at 4:54:15 AM UTC-5, Marcus wrote:
>>>> On 2021-07-26 18:19, MitchAlsup wrote:
>>>>> On Monday, July 26, 2021 at 2:27:54 AM UTC-5, Marcus 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.
>>>>> <
>>>>> Given that they cannot be in a GPR or an FPR, Oh wise one,
>>>>> Where would you put them ?
>>>>> <
>>>> At the same place that we specify the floating-point precision: in the
>>>> instruction.
>>>>>> 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
>>>>> <
>>>>> But does not cross thread or task boundaries. So its not "like memory" either.
>>>>> <
>>>>>> (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).
>>>>> <
>>>>> So you discount libraries that may contain interval arithmetic or properly
>>>>> rounded transcendentals ?
>>>> You might have misunderstood my point. As a software developer, if I
>>>> have a choice between:
>>>>
>>>> 1. Rounding mode is configured in a thread global register.
>>>> 2. Rounding mode is always RNE.
>>>>
>>>> ...then I pick 2, because that gives me 100% predictable results,
>>>> whereas with 1 all bets are off (read my other examples as to why this
>>>> is the case).
>>>>
>>>> *However*, if there is also the option:
>>>>
>>>> 3. Rounding mode is part of the instruction.
>>>>
>>>> ...then I pick 3.
>>> <
>>> Do you still pick 3 if the average instruction went from 32-bits in size to
>>> 37 bits in size ?
> <
>> Come on, no straw men please. If adding 3 bits to a dozen opcodes pushes
>> the average of the whole ISA from 32 to 37 bits then you have bigger
>> encoding problems than FP rounding.
> <
> You may work in a space where the instruction container size is a free
> variable; almost nobody else does. So if a few percent of your instruction
> stream needs feature x and feature x requires another whole 32-bit container,
> then it is not just the 3-bits that get counted it is also the overhead of the
> delivery mechanism.

Then work in a space where instruction container size *is* a free
variable; we don't have a patent on entropy-dense encoding.

>>
>> Five modes times 12 opcodes adds 60 models to an existing ~1500, or
>> something like 2% of a bit to the entropy. If you can't do it in under a
>> bit then you should change your encoding to fix the crappy entropy
>> utilization.
> <
> I am acutely aware of entropy................
>

Why not use it then?

On Tuesday, July 27, 2021 at 5:41:56 PM UTC-6, Ivan Godard wrote:

> Typical architectures have broken and wasteful encoding.

Wasteful, yes, but the waste is a side-effect of the encoding
being kept very simple.

John Savard

On Tuesday, July 27, 2021 at 5:44:44 PM UTC-6, Ivan Godard wrote:

> Then work in a space where instruction container size *is* a free
> variable; we don't have a patent on entropy-dense encoding.

Concertina II, despite being apparently in the same straitjacket as all
the other conventional architectures out there, actually achieves this.

By organizing instructions into 256-bit blocks, in order to use something
similar to heads-and-tails for Mitch Alsup's immediates, in a previous
incarnation I used 1111 as a header for a block built from 18-bit and
36-bit instructions, even if the _default_ instruction encoding was
plain old 32 bit.

And I had extra space in the headers to indicate stuff like the FP
rounding mode - if it stays the same for an entire subroutine,
that would be adequate, instead of doing it per instruction. But it's
the easiest thing in the world to stipulate a mode that says 'you've
got six instead of seven instructions in a block so you can add an
extra five bits to each instruction'... with a field in the _first_ 32-bit
slot that gives _hundreds_ of choices for what those extra five bits
are used for.

Don't tempt me.

But it's better to build an FPGA into a processor than to try and
anticipate every possible special feature someone might want and
then build them all in. For obvious reasons.

John Savard

On Tuesday, July 27, 2021 at 7:41:05 PM UTC-6, Quadibloc wrote:

> And I had extra space in the headers to indicate stuff like the FP
> rounding mode - if it stays the same for an entire subroutine,
> that would be adequate, instead of doing it per instruction. But it's
> the easiest thing in the world to stipulate a mode that says 'you've
> got six instead of seven instructions in a block so you can add an
> extra five bits to each instruction'... with a field in the _first_ 32-bit
> slot that gives _hundreds_ of choices for what those extra five bits
> are used for.

> Don't tempt me.

That would be one way of getting rid of the competition. :)

But, of course, I am no competition to you, because even if I
resist temptation in one area, I will gleefully fall into it in another.

However, this discussion has inspired me to come up with an
invention! Which I now give freely to the world...

You've heard of the present-day supercomputer, which
connects together thousands of microprocessors working
in parallel to solve gigantic problems!

I give you... the super-_silly_-computer!

How do you implement an ISA that is so complicated
that Moore's law has not yet run for long enough to permit
it to be implemented on a single die?

Well, you could go back to implementing it across multiple
dies, and having its cycle time be measured in megahertz
instead of gigahertz. But that would make it useless!

Instead...

Let us assume that said complex ISA consists of
a conventional ISA, plus thousands of extensions to
support special data types like sexagesimal floating-point
that will be very rarely used.

So:

Instead of building chips with sixteen cores on them,
let us build chips consisting of eight cores, each of which
includes a co-processor for *one* of the many rarely-used
extensions to the instruction set.

And let that chip come in, oh, say, 128 different variations,
each containing eight _different_ extensions to the instruction
set in its cores, for a total of 1,024 extensions.

So one builds a computer with 128 chips, and when a
program uses one of those extensions, it is sent to one
of the chips that has a core capable of executing that
kind of instruction!!!

Voila - a computer capable of efficiently executing programs
written in an ISA so complicated that no single chip can
hold it!

John Savard

On Tuesday, July 27, 2021 at 9:13:45 PM UTC-6, Quadibloc wrote:

> Instead of building chips with sixteen cores on them,
> let us build chips consisting of eight cores, each of which
> includes a co-processor for *one* of the many rarely-used
> extensions to the instruction set.
>
> And let that chip come in, oh, say, 128 different variations,
> each containing eight _different_ extensions to the instruction
> set in its cores, for a total of 1,024 extensions.

Think of it as a natural extension to what AMD did with
the floating-point unit in Bulldozer...

John Savard

On 7/27/2021 6:14 PM, MitchAlsup wrote:
> On Tuesday, July 27, 2021 at 1:29:22 PM UTC-5, BGB wrote:
>> On 7/27/2021 4:54 AM, Marcus wrote:
>
>>> Does the compiler have to generate code for foo() in binary16, binary32,
>>> binary64 and binary128? No. The developer selects the precision and
>>> rounding mode(s). The developer knows what rounding mode to use for a
>>> particular algorithm.
>>>
>> Agreed.
>>
>> Though, one could imagine a situation where ABI-level register handling
>> gets messed up (say, because the official ABI and GCC disagreed as to
>> whose responsibility it is to save/restore the register), and the
>> decoded FPU instructions effectively get turned into confetti.
>>>>>
>>>>> Perhaps your prefix instruction paradigm could be used for this (e.g.
>>>>> like "CARRY")?
>>>> <
>>>> If I wanted 'per instruction RMs' this would be how I did it. A
>>>> CARRY-like
>>>> RM-instruction-modifier could cast RM over 5-ish subsequent instructions.
>>>
>>> Sounds reasonable.
>>>
> <snip>
>>>
>>> The use case given here sounds like it has more to do with experimenting
>>> with different settings than to actually generate production code. As
>>> such it would be easy to just re-compile the source code with different
>>> rounding mode settings. I occasionally do this when experimenting with
>>> different floating-point precisions (usually single precision vs
>>> double-precision), e.g. using a C DEFINE.
>>>
>> Bigger question is what is the best way to go about telling the C
>> compiler to use a non-default rounding.
> <
> IEEE 754-2019 says to use::
> <
> binaryRoundingDirection oldRM = getBinaryRoundingDirection(void)
> and
> void setBinaryRoundingDirection(binaryRoundingDirection)
> <
> What has not yet happened is for C (and many other languages) to decide
> if this feature is static/threadLocal/global or whether it is embedded in scope:
> <
> withMode<RNA>{ doSomething(); }
> <
>

Not aware of any compilers doing it that way...

FWIW:
MSVC uses _controlfp and _controlfp_s.
OpenCL uses:
#pragma OPENCL SELECT_ROUNDING_MODE mode

I had considered:
#pragma rounding_mode(mode)
Or:
[[rounding_mode(mode)]]

Where the latter could be used like, say:

[[rounding_mode(truncate)]] double func(double x, double y)
{ ...
}

Or maybe:
double func(double x, double y)
{ [[rounding_mode(truncate)]] {
...
}
}

Where in the latter case, the rounding mode attribute would apply to a
particular block. I would need to figure out how to express this in the
IR stages though (per-function would be easier in this case).

As can be noted, my compiler is a bit mix-and-match regarding its use of
C standards, more following a pattern of implementing whatever I feel is
useful at a given time, rather than trying to implement everything in
the order they were added to the standards.

As, is:
C89:
Should be more-or-less good;
Well, excluding some stuff that is "mostly irrelevant", ...
C99:
A few edge-cases involving designated initializers;
_Imaginary is treated as analogous to _Complex;
VLAs exist, sorta, but they "kinda suck";
...
C11:
Various misc features supported;
Things like _Generic, still unsupported;
(Could add, I don't really "get it" though.)
...
C17:
Nothing notable was added vs C11.
C23:
Still proposal stage.
Had been cherry picking some of the features I liked.

There is a higher priority in my case for features that overlap with
BS2, some of which exist as extensions. Some of this stuff may also end
up being used indirectly via stuff happening in the runtime (analogous
to how crashes in MSVCRT may land on a bunch of C++ and/or C++/CLI stuff
in an otherwise C program).

I put a lower priority on C++ because I don't feel like C++ support is
terribly realistic at this stage.

On 2021-07-27 19:34, MitchAlsup wrote:
> On Tuesday, July 27, 2021 at 5:29:45 AM UTC-5, Marcus wrote:
>> On 2021-07-27 00:12, MitchAlsup wrote:
>>> On Monday, July 26, 2021 at 1:16:36 PM UTC-5, Ivan Godard wrote:
>>>> On 7/26/2021 10:46 AM, EricP wrote:
>>>>> Ivan Godard wrote:
>> [snip]
>>>>>> And then there's save/restore of the mode across calls.
>>>>>>
>>>>>> Status reg and ignoring the software is a good hardware solution. :-(
>>>>>
>>>>> Most of this problem is caused because x86 _only_ has dynamic precision
>>>>> and rounding modes, forcing almost every FP instruction to be
>>>>> dependent on FpControl's current setting.
>>>>>
>>>>> Everyone expects FpControl to be set their way but doesn't
>>>>> want to pay the price of saving, setting and restoring it
>>>>> on every FP using routine. So the setting of FpControl
>>>>> becomes an invisible ABI register that no one talks about.
>>> <
>>> Why is the cost of saving and restoring something other than on the
>>> order of 4 instructions:: ReadCR-STstack.......LDstack-WriteCR.
>>> That is:: without requiring pipeline flushes and crap like that.
>> The real problem is that neither developers nor compilers do this. To
>> make it work (with rounding mode in a control register) I think that the
>> control register needs to be an explicit part of the ABI as a callee-
>> saved register (not just at the language level).
>>
>> In other words, any function that *uses* the RM register (i.e. any
>> function that uses floating-point instructions) needs to:
>>
>> 1) Push the current RM state.
>> 2) Set the requested RM state.
>> 3) Do FP ops, call subroutines etc...
>> 4) Pop the old RM state and exit.
> <
> <
> where *uses* means *modifies*

That also works, as long as the default / parent RM state is restored
before any subroutine call (and reset to the requested RM state when
then subroutine returns).

>>
>> Maybe you can do less work, but I can't think of a simpler solution
>> that would actually work in all situations.
>>
>> Since programmers make errors, this code must be generated by the
>> compiler (just as is done for regular callee-saved GPR:s).
>>
>> All programming languages and ABI:s that I have come across so far
>> are broken in this regard.
>>
>> /Marcus

On 2021-07-27 20:05, Ivan Godard wrote:
> On 7/27/2021 10:30 AM, MitchAlsup wrote:
>> On Tuesday, July 27, 2021 at 3:27:53 AM UTC-5, Ivan Godard wrote:
>>> On 7/26/2021 5:39 PM, MitchAlsup wrote:
>>>> On Monday, July 26, 2021 at 5:56:13 PM UTC-5, Quadibloc wrote:
>>>>> On Monday, July 26, 2021 at 10:19:32 AM UTC-6, MitchAlsup wrote:
>>>>>
>>>>>> Given that they cannot be in a GPR or an FPR, Oh wise one,
>>>>>> Where would you put them ?
>>>> <
>>>>> Given the nature of his complaints, obviously there is no other choice
>>>>> but to put the rounding mode in the instruction. If that is annoying,
>>>>> then only have the rounding mode specified in a special longer form of
>>>>> the instructions, with the normal form of the instruction always
>>>>> using the
>>>>> default rounding mode (usually round to nearest, presumably in a
>>>>> status
>>>>> register, _but only alterable there by a privileged instruction_).
>>>> <
>>>> Imagine Kahan wanting to do something like the following to test the
>>>> sensitivity to rounding::
>>>> <
>>>> 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 );
>>>> }
>>>> Where rm is originally read in from a file. Show me how you put the
>>>> rounding
>>>> mode exclusively in the instruction and have no other place in the
>>>> machine
>>>> holding RM state ?
>> <
>>> That's why "from specReg" is one of our available static choices; the
>>> user who chooses that is accepting the SIMD/call/task/etc issues, thinks
>>> he knows what he is doing, and deserves it. The default for the less
>>> witting is static RNE.
>>>
>>> But the real problem with your example is linguistic: the notation
>>> itself implies that the mode is a variable, even if the argument to
>>> setRoundingMode is a literal. Change the notation to:
>>> withMode<RNA>{ doSomething(); }
>>> or even:
>>> mode dyn; f >> dyn;
>>> withMode<dynamic(dyn)>{ doSomething(); }
>>> and most of the issues go away, even if you really want dynamic.
>> <
>> Not said but I believe you mean::
>> <
>> withMode<RNA>{ doSomething(); }
>> <
>> to be::
>> {setRoundingMode(dyn); { doSomething(); } setRoundingMode(RNE);}
>
> No, I don't mean that. I mean a true scope, like with
> constructor/destructors, so that the mode is restored even if you goto
> out of the {}, or throw/longjmp out of it. You are not forcing the mode
> at the "}" to RNE, you are restoring it to whatever it was in the
> surrounding scope.
>
> A macro paint job on a global variable won't do.

Exactly. Scoped FP configuration is probably the sanest language
construct (it should be simple and natural to scope it down to a single
instruction, e.g. if you need a special rounding mode in some step in
a transcendental function implementation for instance).

>
>> <
>> In any event, when the RM part of your FP control register is passed as
>> an operand to the FP units, it can be changed without pipeline flushes
>> with either simply interlocks (boo) or as another operand in the
>> Reservation
>> stations (a lot less of a boo).
>> <
>> In any event::
>> How does one without a RM field in some control register obey 9.3.1 ?
>> and 9.3.2 ?

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

Does that mean that we need to make the same mistakes. I don't see why
9.3.1 & 9.3.2 need to be mandated.

/Marcus

On 2021-07-27 20:43, BGB wrote:
> On 7/27/2021 1:14 PM, Ivan Godard wrote:
>> On 7/27/2021 10:32 AM, MitchAlsup wrote:
>>> On Tuesday, July 27, 2021 at 4:54:15 AM UTC-5, Marcus wrote:
>>>> On 2021-07-26 18:19, MitchAlsup wrote:
>>>>> On Monday, July 26, 2021 at 2:27:54 AM UTC-5, Marcus 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.
>>>>> <
>>>>> Given that they cannot be in a GPR or an FPR, Oh wise one,
>>>>> Where would you put them ?
>>>>> <
>>>> At the same place that we specify the floating-point precision: in the
>>>> instruction.
>>>>>> 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
>>>>> <
>>>>> But does not cross thread or task boundaries. So its not "like
>>>>> memory" either.
>>>>> <
>>>>>> (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).
>>>>> <
>>>>> So you discount libraries that may contain interval arithmetic or
>>>>> properly
>>>>> rounded transcendentals ?
>>>> You might have misunderstood my point. As a software developer, if I
>>>> have a choice between:
>>>>
>>>> 1. Rounding mode is configured in a thread global register.
>>>> 2. Rounding mode is always RNE.
>>>>
>>>> ...then I pick 2, because that gives me 100% predictable results,
>>>> whereas with 1 all bets are off (read my other examples as to why this
>>>> is the case).
>>>>
>>>> *However*, if there is also the option:
>>>>
>>>> 3. Rounding mode is part of the instruction.
>>>>
>>>> ...then I pick 3.
>>> <
>>> Do you still pick 3 if the average instruction went from 32-bits in
>>> size to
>>> 37 bits in size ?
>>
>> Come on, no straw men please. If adding 3 bits to a dozen opcodes
>> pushes the average of the whole ISA from 32 to 37 bits then you have
>> bigger encoding problems than FP rounding.
>>
>> Five modes times 12 opcodes adds 60 models to an existing ~1500, or
>> something like 2% of a bit to the entropy. If you can't do it in under
>> a bit then you should change your encoding to fix the crappy entropy
>> utilization.
>
> I agree.
>
> In my case, while this option effectively doubles the size of the
> instructions in question, I expect that the average case impact will be
> much smaller than this, given:
> FPU instructions are statistically infrequent (vs memory or ALU ops);
> One is only likely to need specialized rounding modes in obscure edge
> cases (if at all).
>
> I could have done it within the existing 32-bit encoding, but was not
> feeling inclined to do so (not common enough to be worth the cost in
> encoding space).

I agree too. Using up some 50 opcodes for FP instructions would be
doable, but given how rare non-RNE rounding modes are, I think I'll just
punt the problem and add a prefix mechanism at a later time (I have
spared some encoding pages for things like that, and I'm already
thinking about adding something like Mitch's CARRY prefix for multi-
precision arithmetic).

That would increase the size of FP instructions that use non-default
rounding modes from 32 bits to 64 bits (worst case), which is
acceptable in my book.

/Marcus

On Wednesday, July 28, 2021 at 8:03:21 AM UTC-6, Marcus wrote:

> Does that mean that we need to make the same mistakes. I don't see why
> 9.3.1 & 9.3.2 need to be mandated.

Since these sections only apply to implementations that support
dynamic modes, if only static modes specified in the instruction
are present, they aren't required for compliance.

John Savard

Marcus <m.delete@this.bitsnbites.eu> writes:
>On 2021-07-27 20:05, Ivan Godard wrote:
>> No, I don't mean that. I mean a true scope, like with
>> constructor/destructors, so that the mode is restored even if you goto
>> out of the {}, or throw/longjmp out of it. You are not forcing the mode
>> at the "}" to RNE, you are restoring it to whatever it was in the
>> surrounding scope.

You want the old rounding mode restored whenever you leave the scope,
by whatever means. That's just proper scoping. Lisp has
unwind-protect for that, Java has finally, other languages have
similar mechanisms.

Programming languages can implement this based on the architectural
(global) dynamic rounding mode, just like they implement local
variables based on (global) registers. Do those who think that the
dynamic rounding mode bits are a bad architectural feature have a
better alternative?

>My interpretation of the situation is that IEEE 754 was largely inspired
>by x87 (and similar architectures)

The story that I read (and you can find it in various places on the
net) is that Kahan advised Intel on the 8087 at around the same time
when he and others worked on IEEE 754. And Intel wanted to be
compatible with the upcoming standard.

If IEEE 754 just had wanted to standardize an existing implementation,
the highly successful VAX would have been a more likely target than
the newcomer 8087. And actually, I think that IEEE single and double
are the VAX F and G formats for normal numbers (minus the byte order
perversity of the VAX); but IEEE also added denormal numbers,
infinities, and NaNs, and defined the FP operations appropriately to
deal with that.

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

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:
> >> No, I don't mean that. I mean a true scope, like with
> >> constructor/destructors, so that the mode is restored even if you goto
> >> out of the {}, or throw/longjmp out of it. You are not forcing the mode
> >> at the "}" to RNE, you are restoring it to whatever it was in the
> >> surrounding scope.
> You want the old rounding mode restored whenever you leave the scope,
> by whatever means. That's just proper scoping. Lisp has
> unwind-protect for that, Java has finally, other languages have
> similar mechanisms.
>
> Programming languages can implement this based on the architectural
> (global) dynamic rounding mode, just like they implement local
> variables based on (global) registers. Do those who think that the
> dynamic rounding mode bits are a bad architectural feature have a
> better alternative?
> >My interpretation of the situation is that IEEE 754 was largely inspired
> >by x87 (and similar architectures)
> The story that I read (and you can find it in various places on the
> net) is that Kahan advised Intel on the 8087 at around the same time
> when he and others worked on IEEE 754. And Intel wanted to be
> compatible with the upcoming standard.
>
> If IEEE 754 just had wanted to standardize an existing implementation,
> the highly successful VAX would have been a more likely target than
> the newcomer 8087. And actually, I think that IEEE single and double
> are the VAX F and G formats for normal numbers (minus the byte order
> perversity of the VAX); but IEEE also added denormal numbers,
> infinities, and NaNs, and defined the FP operations appropriately to
> deal with that.
>

Out of memory, another difference apart from mixed endianness is that exponent bias differs by one.
I don't remember which one is bigger.
Also, I don't think you are correct about infinities. IIRC, VAX floating point formats have no NaN or subnormals but Inf is here.

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

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.

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

On Wednesday, July 28, 2021 at 1:53:17 PM UTC-6, Quadibloc wrote:

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

While the IEEE 754 standard wasn't finalized and published until 1985,
and the 8087 was announced in 1980, the main part of the discussions
leading to its adoption took place earlier.

> Which they adopted, minus a few of the rounding modes that the
> original 8087 provided.

It was projective infinity that they dropped.

John Savard

On Tuesday, July 27, 2021 at 9:13:45 PM UTC-6, Quadibloc wrote:
> Let us assume that said complex ISA consists of
> a conventional ISA, plus thousands of extensions to
> support special data types like sexagesimal floating-point
> that will be very rarely used.

And of course sexagesimal fixed point would be supported
as well.

After all, unless a computer could efficiently generate invoices
in Babylonian cuneiform, how could it possibly be considered
the very model of a modern micro-computer?

John Savard

On 7/28/2021 10:57 AM, Marcus wrote:
> On 2021-07-27 20:43, BGB wrote:
>> On 7/27/2021 1:14 PM, Ivan Godard wrote:
>>> On 7/27/2021 10:32 AM, MitchAlsup wrote:
>>>> On Tuesday, July 27, 2021 at 4:54:15 AM UTC-5, Marcus wrote:
>>>>> On 2021-07-26 18:19, MitchAlsup wrote:
>>>>>> On Monday, July 26, 2021 at 2:27:54 AM UTC-5, Marcus 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.
>>>>>> <
>>>>>> Given that they cannot be in a GPR or an FPR, Oh wise one,
>>>>>> Where would you put them ?
>>>>>> <
>>>>> At the same place that we specify the floating-point precision: in the
>>>>> instruction.
>>>>>>> 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
>>>>>> <
>>>>>> But does not cross thread or task boundaries. So its not "like
>>>>>> memory" either.
>>>>>> <
>>>>>>> (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).
>>>>>> <
>>>>>> So you discount libraries that may contain interval arithmetic or
>>>>>> properly
>>>>>> rounded transcendentals ?
>>>>> You might have misunderstood my point. As a software developer, if I
>>>>> have a choice between:
>>>>>
>>>>> 1. Rounding mode is configured in a thread global register.
>>>>> 2. Rounding mode is always RNE.
>>>>>
>>>>> ...then I pick 2, because that gives me 100% predictable results,
>>>>> whereas with 1 all bets are off (read my other examples as to why this
>>>>> is the case).
>>>>>
>>>>> *However*, if there is also the option:
>>>>>
>>>>> 3. Rounding mode is part of the instruction.
>>>>>
>>>>> ...then I pick 3.
>>>> <
>>>> Do you still pick 3 if the average instruction went from 32-bits in
>>>> size to
>>>> 37 bits in size ?
>>>
>>> Come on, no straw men please. If adding 3 bits to a dozen opcodes
>>> pushes the average of the whole ISA from 32 to 37 bits then you have
>>> bigger encoding problems than FP rounding.
>>>
>>> Five modes times 12 opcodes adds 60 models to an existing ~1500, or
>>> something like 2% of a bit to the entropy. If you can't do it in
>>> under a bit then you should change your encoding to fix the crappy
>>> entropy utilization.
>>
>> I agree.
>>
>> In my case, while this option effectively doubles the size of the
>> instructions in question, I expect that the average case impact will
>> be much smaller than this, given:
>> FPU instructions are statistically infrequent (vs memory or ALU ops);
>> One is only likely to need specialized rounding modes in obscure edge
>> cases (if at all).
>>
>> I could have done it within the existing 32-bit encoding, but was not
>> feeling inclined to do so (not common enough to be worth the cost in
>> encoding space).
>
> I agree too. Using up some 50 opcodes for FP instructions would be
> doable, but given how rare non-RNE rounding modes are, I think I'll just
> punt the problem and add a prefix mechanism at a later time (I have
> spared some encoding pages for things like that, and I'm already
> thinking about adding something like Mitch's CARRY prefix for multi-
> precision arithmetic).
>

Yeah. As noted, I did it via an Op64 prefix:
FFwZ_ZZii

Where:
w: Extend GPR bits.
ZZZ: Extend Opcode (000 maps to the 32-bit encoding space)
ii: Extend Immed (or function as a 4th Imm8/Reg6).

Then made it so that the existing FADD/FSUB/FMUL ops will decode into a
form where the Imm8 extension serves as a rounding mode.

In terms of 3R->4R ops, one of several expansions can happen:
Rm, Ro, Rn, Rn: Default (Same as normal 3R), Imm8 is ignored.
Rm, Ro, I8, Rn: Possibility 1 (Used as Imm8)
Rm, Ro, Rp, Rn: Possibility 2 (Used as a Register)

When decoded without the Op64 prefix:
Rm, Ro, Rn, Rn: Default.
Rm, Ro, 0, Rn: Possibility 1 (Rp gets 0)
Rm, Ro, Rn, Rn: Possibility 2 (Rp gets Rn)

On 7/24/2021 12:44 PM, Chris M. Thomasson wrote:
> On 7/24/2021 12:14 AM, BGB wrote:
>> On 7/24/2021 1:05 AM, Quadibloc wrote:
>>> On Saturday, July 24, 2021 at 12:01:35 AM UTC-6, Quadibloc wrote:
>>>
>>>> I remember specifically that one particular failed Ariane launch was
>>>> held up as what bad floating-point can cause...
>>>
>>> Ah. A Google search led me to what really happened.
>>>
>>> The maiden flight of Ariane 5 failed because conversion from
>>> floating-point to 16-bit integer caused an exception, as the
>>> floating-point valule was not within the range of such integers.
>>>
>>> No doubt bad software design, but not really necessarily
>>> about the kind of numerical analysis concern that IEEE 754
>>> addresses.
>>>
>>
>> IME:
>> Inexact rounding is hardly ever the source of problems (excluding
>> integer-exact math in codecs, but this sort of stuff is typically
>> fixed-point).
>>
>>
>> However, more serious bugs, like unexpected overflow, saturation, or
>> traps, these sorts of things can ruin ones' day.
>>
>> Likewise for algorithms whose domain is "all real numbers except
>> zero", which just so happens to fail catastrophically and nuke the
>> program if the input just so happens to be zero.
>>
>>
>> Insufficient precision can also be a source of problems.
>>
>> Issues with the use of single precision coordinates in games trying to
>> deal with large worlds is a fairly common example (typically a lot of
>> workarounds are needed to make all the math work for worlds much
>> larger than a few km or so).
>
> Fwiw, I did a fractal encoding thing for pure fun where I map symbols to
> complex roots. The code only encodes/decodes data in a Julia set with a
> power of 16 to conveniently map into hexbytes. This is a pure
> experiment, but it works. Rounding errors and other floating point
> issues can make it crap out by decrypting part of the plaintext with
> some "junk" on it. So, I found an arbitrary precision lib in JavaScript,
> Decimal.js, and put it up online. Here it is:
>
> http://fractallife247.com/test/rifc_cipher
>
> A ciphertext is a single complex number. For instance here is one that
> contains my name:
>
> real:
> -0.70928383564905214400492596591643890200098992164665980782966227733203960188288097070737389345985516069300117982413622497654113697
>
>
> imag:
> 0.75006448767684071252250616852543657203512420946592887596427538863664520584158627985390890157772176873489867565028334553930789721
>

When you copy and paste there must be no errors, spaces, ect. In other
words this version is not fault tolerant at all wrt its crude bastard
parser.

So,

(-0.70928383564905214400492596591643890200098992164665980782966227733203960188288097070737389345985516069300117982413622497654113697)

Focus on the real between the parenthesis, no spaces or padding. It will
f*** up decrypting.

On 2021-07-24 9:05, Quadibloc wrote:
> On Saturday, July 24, 2021 at 12:01:35 AM UTC-6, Quadibloc wrote:
>
>> I remember specifically that one particular failed Ariane launch was
>> held up as what bad floating-point can cause...
>
> Ah. A Google search led me to what really happened.
>
> The maiden flight of Ariane 5 failed because conversion from
> floating-point to 16-bit integer caused an exception, as the
> floating-point valule was not within the range of such integers.
>
> No doubt bad software design,

The software in question was reused from the earlier Ariane 4 launchers.
It was carefully analyzed with respect to the Ariane 4 launch
trajectory, and the quantity in question was shown stay within 16-bit
integer range. Unfortunately that analysis was not repeated for Ariane
5, which has a different launch trajectory with a higher horizontal
velocity.

> but not really necessarily about the kind of numerical analysis
> concern that IEEE 754 addresses.

Yeah.

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.
<
> Also, I don't think you are correct about infinities. IIRC, VAX floating point formats have no NaN or subnormals but Inf is here.
> > - anton
> > --
> > 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> > Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>