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

That's how I'd cope with what he wants, given that you are correct that
there's no place to put the rounding mode in currently well-known architectures
that comports well with what he wants to do.

John Savard

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 how I'd cope with what he wants, given that you are correct that
> there's no place to put the rounding mode in currently well-known architectures
> that comports well with what he wants to do.
<
Using a longer version of an instruction is not as bad an idea as have been
recently expressed herein.
>
> John Savard

On Sunday, July 25, 2021 at 3:11:25 AM UTC-6, Thomas Koenig wrote:

> There are ample examples how to deal with a 36-bit words:
> The IBM 701 and following and the PDP-10, for example.

Oh, that's true.

But the IBM 360, with base registers, supported a much larger
address space - 24 bits from the beginning, 31 bits trivially, and
it was easily upgraded to go 64 bits.

And since I was responding to a comment about how the IBM
360 having 32-bit single precision floats made it unsatisfactory
compared to the existing machines with 36, 48, and 60 bit
single precision... I thought it useful to imagine how, with
_minimal_ changes, the IBM 360 architecture could be altered
to use 36 bit words and 9 bit bytes instead.

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 depends on DDR4 having at least one unused
pin, that could be put to use for the negative power supply...

John Savard

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

> Of course, this depends on DDR4 having at least one unused
> pin, that could be put to use for the negative power supply...

I see that all 288 pins are in use.

There are an enormous number of pins used for VSS, but that's
ground.

One could use half of the pins used for VPP for the negative
logic voltage, but that would be a *big* incompatibility; one
ought to at least put the notch in a different place if one
did that! And if that was done, one might as well add pins.

John Savard

On Monday, July 26, 2021 at 11:24:56 PM UTC-6, Quadibloc wrote:

> One could use half of the pins used for VPP for the negative
> logic voltage, but that would be a *big* incompatibility; one
> ought to at least put the notch in a different place if one
> did that! And if that was done, one might as well add pins.

Actually it's VDD that's the logic 1 voltage. There are 26 pins
used for that, as against only 4 pins that are marked as not
connected. (An RFU abbreviation for Reserved for Future
Use was defined, but I could see no pins so labelled.)

So going to negative voltage instead of half voltage for the
third state would require a major redesign, not a tiny
change that was almost un-noticeable.

John Savard

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.

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.

>>
>> 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.
> <
> And there are cases where this philosophy would blow up code space
> when they were used. Does the compiler have to generate code for
> foo() in RNE, and RTPI and RTNI, and RTZ, and RTMAG modes?

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.

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

>>
>>> < Probably the
>>>> "least awful" would probably be to use an Op64 encoding, which then uses
>>>> some of the Immed extension bits to encode a rounding mode.
>>> <
>>> The argument against having them in instructions is that this prevents
>>> someone from running the code several times with different rounding
>>> modes set to detect any sensitivity to the actually chosen rounding mode.
>>> Kahan said he uses this a lot.
>>
>> ......let me question the usefulness of that. If I were to do such
>> experiments I would just compile the algorithm with different rounding
>> modes set explicitly (e.g. as a C++ template argument or something).
> <
> So you would end up with 5 copies of FPPPP, one for each rounding mode
> (at the cost of 8K×sizeof(inst) per rounding mode = 32KB/mode = 165KB)
> ??!!?

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.

>>
>>>>
>>>>
>>>> * FFw0_00ii_F0nm_5eo8 FADD Rm, Ro, Rn, Imm8
>>>> * FFw0_00ii_F0nm_5eo9 FSUB Rm, Ro, Rn, Imm8
>>>> * FFw0_00ii_F0nm_5eoA FMUL Rm, Ro, Rn, Imm8
>>>>
>>>> Where the Imm8 field encodes the rounding mode, say:
>>>> 00 = Round to Nearest.
>>>> 01 = Truncate.
>>>>
>>>> Or could go the SR route, but I don't want FPU behavior to depend on SR.
>>> <
>>> When one has multi-threading and control/status register, one simply
>>> reads the RM field and delivers it to the FU as an operand. A couple
>>> of interlock checks means you don't really have to stall the pipeline
>>> because these modes don't change all that often.
>>> <
>>
>> Again, that's the HW perspective. But from a SW perspective you *don't*
>> want RM to be part of a configuration register.
>>
>> Global variables are bad. This was well established some 50 years ago
>> (e.g. Wulf, W.A., Shaw, M., "Global Variables Considered Harmful" from
>> 1973). Global configuration registers even more so.
> <
> So Root pointers are now considered Harmful ?!?
>>
>>>>> Since the hidden bit is already hidden at this point, andy rounding
>>>>> overflow of the mantissa from 0xfff.. to 0x000.. will cause the exponent
>>>>> term to be incremented, possibly all the way to Inf. In all cases, this
>>>>> is the exactly correct behaviour.
>>>>>
>>>> Yep.
>>>>
>>>> Main limiting factor though is that for bigger formats (Double or FP96),
>>>> propagating the carry that far can be an issue.
>>> <
>>> Koogie-Stone adders !
>>>>
>>>> In the vast majority of cases, the carry gets absorbed within the low 8
>>>> or 16 bits or so (or if it doesn't, leave these bits as-is).
>>>>
>>>> For narrowing conversions to Binary16 or Binary32, full width rounding
>>>> is both easier and more useful.
>>>>
>>>>
>>>>
>>>> For FADD/FSUB, the vast majority of cases where a very long stream of
>>>> 1's would have occured can be avoided by doing the math internally in
>>>> twos complement form.
>>>>
>>>> Though, in this case, one can save a little cost by implementing the
>>>> "twos complement" as essentially ones' complement with a carry bit input
>>>> to the adder (one can't arrive at a case where both inputs are negative
>>>> with FADD).
>>> <
>>> This is a standard trick that everyone should know--I first saw it in the
>>> PDP-8 in the Complement and increment instruction--but it has come in
>>> handy several times and is the way operands are negated and complemented
>>> in My 66000. The operand is conditionally complemented with a carry in
>>> conditionally asserted. IF the operand is being processed is integer there
>>> is an adder that deals with the carry in. If the operand is logical, there is
>>> no adder and the carry in is ignored.
>>>>
>>>>
>>>> Cases can occur though where the result mantissa comes up negative
>>>> though, which can itself require a sign inversion. The only alternative
>>>> is to compare mantissa input values by value if the exponents are equal,
>>>> which is also fairly expensive.
>>>>
>>>> Though, potentially one could use the rounding step to "absorb" part of
>>>> the cost of the second sign inversion.
>>>>
>>>> Another possibility here could be to have an adder which produces two
>>>> outputs, namely both ((A+B)+Cin) and (~(A+B)+(!Cin)), and then using the
>>>> second output if the first came up negative.
>>>>
>>>> ...

On 2021-07-27 02:39, 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 ?

I would do this in the exact same way as for dynamically selecting
floating-point precision. Hint: It would require spelling/rolling out
different RM versions of the different operations and do runtime
selection (e.g. via a switch statement).

> <
>>
>> That's how I'd cope with what he wants, given that you are correct that
>> there's no place to put the rounding mode in currently well-known architectures
>> that comports well with what he wants to do.
> <
> Using a longer version of an instruction is not as bad an idea as have been
> recently expressed herein.

Especially if the longer versions are only used for non-default rounding
modes.

>>
>> John Savard

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.

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

Marcus wrote:
> 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.

This is exactly how you have to treat the string direction bit on x86:

By default all the REP MOV/STOS/CMPS operations moves forward since the
direction bit is reset on power-up.

If you want to make an overlapping move where the target start address
is within the source range, then you have to detect this, move both
source and dest registers to the end of the ranges and then STD (SeT
Direction flag). At the end of this process you must either restore the
old DF value, or (much more commonly used) clear it again with CLD.
>
> Maybe you can do less work, but I can't think of a simpler solution
> that would actually work in all situations.

If you google I'm sure you can find a bunch of bugs caused by
programmers generating an STD without the follow-up CLD.

>
> Since programmers make errors, this code must be generated by the
> compiler (just as is done for regular callee-saved GPR:s).

Or only used within self-contained libraries.

BTW, the FDIV fix worked 100% due to some quirks in the x87 fp precision
handling: On the x86 FPU the FP operations are size-agnostic, with both
the rounding and precision mode controlled by the FPCW.

In our FDIV replacement code we assumed that the FPU was currently in
64-bit mode (actually, 32-bit would also be OK), with the two incoming
64-bit double arguments on the integer stack.

I grabbed the top 32 bits of the double variable, shifted them down 10
bits and masked away the sign and exponent leaving the top 10 bits of
the mantissa. These bits were then used to index a 1024-bit/128-byte
table with just 5 bits set, corresponding to the 5 missing entries in
the SRT divider lookup table.

(BTW, I did consider a 32 or 64-bit Bloom filter here to skip the table
lookup for most inputs but realized that any code which did nothing but
back-to-back FDIV operations could afford to effectively dedicate two
cache lines of table space, and for normal code which only does a few
sparse FDIVs, the speed didn't really matter.)

For the 1019 of 1024 unset entries we just did a regular FDIV and
returned since we knew that the hardware bug could not be triggered, but
when we got a hit we did a really sneaky thing (not my idea unfortunately):

We switched the FPU into long double/extended/80-bit mode (saving the
original state), then we multiplied both the divisor and the dividend by
15/16! Both of these multiplications were guaranteed to be exact since
we now had 10 more available mantissa bits and 5 extra exponent bits.

At this point we just restored the saved FPCW and fell through into the
same FDIV which was the target for those 1019/1024 normal values.

This function ran at 80 cycles/FDIV vs 40 for a correct chip, even with
input values which were selected to be bad, for pretty much all working
code the slowdown was so miniscule that it was hard to measure.

Terje

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

MitchAlsup wrote:
>> On 7/26/2021 10:46 AM, EricP wrote:
>>> 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.

Because x86/x64 and others (Alpha) put the control bits like round mode
and denorms-are-zero and exceptions mask, which are inputs,
in the same HW register as the result exception flags, which are outputs.
So reading the control bits requires synchronizing with the status bits.

This could penalizes anyone who reads the HW control register
in order to preserve the control bits setting before changing them.

The HW dependencies for these two sets of information are quite
different and they never should have been put together.

I would keep the control bits in FpControl and status bits in
FpStatus registers with separate read and write instructions.
(I don't see anything so far in IEEE-754 that requires them
to be stored together in the same HW register.)

FpControl bits are inherited from caller and are preserved across calls.

Whether FpStatus flags are preserved or accumulated across any particular
call is an application, language and/or library routine decision.

On 7/26/2021 3:55 PM, Terje Mathisen wrote:
> BGB wrote:
>> On 7/25/2021 12:36 PM, Ivan Godard wrote:
>>> However pitting them in status regs mucks up any code that actually
>>> does care about mode; interval arithmetic for example. Especially
>>> because changing the mode commonly costs a pipe flush (yes, you can
>>> put the status in the decoder and decorate the op in the pipe with
>>> it, but that adds five bits to the op state). And then there's
>>> save/restore of the mode across calls.
>>>
>>
>> Yeah, to be useful, it kinda needs to be per-instruction.
>> This means putting it in the encoding, as a register-based mode is a
>> bit too coarse grain to be particularly useful.
>
> I would like to have my cake and eat it too:
>
> a) We need a global/process/thread default Rounding Mode register which
> is saved & restored on any context switch, i.e. like pretty much all
> systems today.
>
> b) Any (short) group of FP operations can have a CARRY-like prefix op
> that specifies the exact rounding mode to be used for the corresponding
> operations. Using 3 bits per instruction makes it possible for a 32-bit
> instruction with 15 available immediate bits to encode 5 FP instructions.
>
> I.e. ROUND (TRUNC, RNE, RNA, CEIL, FLOOR)
>
> Of the 8 possible encodings, we're currently using 5 for rounding modes,
> so we can dedicate one of them (000/111 probably) to indicate "ignore
> this, use the thread control word setting here".
>
> One additional requirement is that the use of the ROUND prefix
> guarantees that there will be no change of the control word rounding
> setting until the shadow ends.
>
> Using Mitch's CARRY shadow trick means that the decoder can then figure
> out very early where the rounding mode bits will come from and dispatch
> them alongside each FP operation.
>

OK, though BJX2 is a very different ISA from Mitch's ISA...

As noted else-thread, I ended up deciding to add it via 64-bit
instruction encodings. This encoding space had been put into use as part
of the prior XGPR extension (with RegRegReg ops gaining an extra Imm8
field, which is normally ignored; previously would have been ignored in
this case as well).

Effectively, Op64 functions like a prefix (similar to Jumbo), just it
extends both the register fields and opcode fields rather than purely
extending the immediate (hence why immediate values extend to 17 bits
rather than 33).

This still leaves the immediate-extension field unused in 3R ops, but
could be used possibly either as a 4th Immed, or possible also some
encodings could use it as an additional source register field (say, for
example: Rn=Rm*Ro+Rp). In this case, the Imm8 or Rp may replace the
value which would have been read from the 'Rn' register in 3R forms (and
otherwise poses similar restrictions in terms of bundling rules; namely
that instructions which read a value from 'Rn' also implicitly eat Lane
3; which in this case also receives a copy of Lane 1's Immed field).

All this is possibly a little hacky, but oh well...

And, in this case, Non-Op64 FADD/FSUB/FMUL are fed a value 0x00 in this
case, which is defined as equivalent to the original behavior.

Though the above approach does mean that FMAC effectively doesn't get a
customizable rounding-mode as an option (FMAC would likely get a 4R form
instead; mostly as Rn=Rm*Ro+Imm8 is kinda useless for FP values).

Though, in theory a rounding-mode could still be encoded via the
remaining 2 bits for this field in 4R form (modes 0..3 only).

The rounding modes are basically those described in the prior post, eg:
00=RNE
01=Trunc
02=+Inf / Ceil
03=-Inf / Floor
04=RNE with ULP at bit 2, and Inexact status in (1:0).

Mode 4 is partly intended to address both flonum rounding and also
inexact signaling. Originally, I considered having separate modes (say,
one which merely rounded such that the low order bits were always
nonzero for inexact results). Seemed likely to be slightly cheaper to
add both as a single mode than to have two separate modes.

The inexact detection in the results is a little loose though, since it
may miss "lost bits" significantly below the ULP (it is more of a "low
order bits just below the ULP were nonzero" detector).

These are not yet supported by my emulator, it is likely that these
encodings would need to be done in software (at present, the emulator
does Binary64 ops by via the host processor's FPU).

....

On Tuesday, July 27, 2021 at 12:31:20 AM UTC-5, Quadibloc wrote:
> On Monday, July 26, 2021 at 11:24:56 PM UTC-6, Quadibloc wrote:
>
> > One could use half of the pins used for VPP for the negative
> > logic voltage, but that would be a *big* incompatibility; one
> > ought to at least put the notch in a different place if one
> > did that! And if that was done, one might as well add pins.
<
> Actually it's VDD that's the logic 1 voltage. There are 26 pins
> used for that, as against only 4 pins that are marked as not
> connected. (An RFU abbreviation for Reserved for Future
> Use was defined, but I could see no pins so labelled.)
<
Then there is the fact that while a DRAM cell can store for milliseconds
a positive voltage, it can only store a negative voltage for microseconds.
(It leaks when storing negative, whereas it does not when positive)
>
> So going to negative voltage instead of half voltage for the
> third state would require a major redesign, not a tiny
> change that was almost un-noticeable.
>
> John Savard

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);}
<
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 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 ?
> >>
> >> 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.
> > <
> > And there are cases where this philosophy would blow up code space
> > when they were used. Does the compiler have to generate code for
> > foo() in RNE, and RTPI and RTNI, and RTZ, and RTMAG modes?
<
> 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.
> >>
> >> 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.
> >>
> >>> < Probably the
> >>>> "least awful" would probably be to use an Op64 encoding, which then uses
> >>>> some of the Immed extension bits to encode a rounding mode.
> >>> <
> >>> The argument against having them in instructions is that this prevents
> >>> someone from running the code several times with different rounding
> >>> modes set to detect any sensitivity to the actually chosen rounding mode.
> >>> Kahan said he uses this a lot.
> >>
> >> ......let me question the usefulness of that. If I were to do such
> >> experiments I would just compile the algorithm with different rounding
> >> modes set explicitly (e.g. as a C++ template argument or something).
> > <
> > So you would end up with 5 copies of FPPPP, one for each rounding mode
> > (at the cost of 8K×sizeof(inst) per rounding mode = 32KB/mode = 165KB)
> > ??!!?
<
> The use case given here sounds like it has more to do with experimenting
> with different settings than to actually generate production code.
<
The use case is to determine if the code is stable enough to become 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.
> >>
> >>>>
> >>>>
> >>>> * FFw0_00ii_F0nm_5eo8 FADD Rm, Ro, Rn, Imm8
> >>>> * FFw0_00ii_F0nm_5eo9 FSUB Rm, Ro, Rn, Imm8
> >>>> * FFw0_00ii_F0nm_5eoA FMUL Rm, Ro, Rn, Imm8
> >>>>
> >>>> Where the Imm8 field encodes the rounding mode, say:
> >>>> 00 = Round to Nearest.
> >>>> 01 = Truncate.
> >>>>
> >>>> Or could go the SR route, but I don't want FPU behavior to depend on SR.
> >>> <
> >>> When one has multi-threading and control/status register, one simply
> >>> reads the RM field and delivers it to the FU as an operand. A couple
> >>> of interlock checks means you don't really have to stall the pipeline
> >>> because these modes don't change all that often.
> >>> <
> >>
> >> Again, that's the HW perspective. But from a SW perspective you *don't*
> >> want RM to be part of a configuration register.
> >>
> >> Global variables are bad. This was well established some 50 years ago
> >> (e.g. Wulf, W.A., Shaw, M., "Global Variables Considered Harmful" from
> >> 1973). Global configuration registers even more so.
> > <
> > So Root pointers are now considered Harmful ?!?
> >>
> >>>>> Since the hidden bit is already hidden at this point, andy rounding
> >>>>> overflow of the mantissa from 0xfff.. to 0x000.. will cause the exponent
> >>>>> term to be incremented, possibly all the way to Inf. In all cases, this
> >>>>> is the exactly correct behaviour.
> >>>>>
> >>>> Yep.
> >>>>
> >>>> Main limiting factor though is that for bigger formats (Double or FP96),
> >>>> propagating the carry that far can be an issue.
> >>> <
> >>> Koogie-Stone adders !
> >>>>
> >>>> In the vast majority of cases, the carry gets absorbed within the low 8
> >>>> or 16 bits or so (or if it doesn't, leave these bits as-is).
> >>>>
> >>>> For narrowing conversions to Binary16 or Binary32, full width rounding
> >>>> is both easier and more useful.
> >>>>
> >>>>
> >>>>
> >>>> For FADD/FSUB, the vast majority of cases where a very long stream of
> >>>> 1's would have occured can be avoided by doing the math internally in
> >>>> twos complement form.
> >>>>
> >>>> Though, in this case, one can save a little cost by implementing the
> >>>> "twos complement" as essentially ones' complement with a carry bit input
> >>>> to the adder (one can't arrive at a case where both inputs are negative
> >>>> with FADD).
> >>> <
> >>> This is a standard trick that everyone should know--I first saw it in the
> >>> PDP-8 in the Complement and increment instruction--but it has come in
> >>> handy several times and is the way operands are negated and complemented
> >>> in My 66000. The operand is conditionally complemented with a carry in
> >>> conditionally asserted. IF the operand is being processed is integer there
> >>> is an adder that deals with the carry in. If the operand is logical, there is
> >>> no adder and the carry in is ignored.
> >>>>
> >>>>
> >>>> Cases can occur though where the result mantissa comes up negative
> >>>> though, which can itself require a sign inversion. The only alternative
> >>>> is to compare mantissa input values by value if the exponents are equal,
> >>>> which is also fairly expensive.
> >>>>
> >>>> Though, potentially one could use the rounding step to "absorb" part of
> >>>> the cost of the second sign inversion.
> >>>>
> >>>> Another possibility here could be to have an adder which produces two
> >>>> outputs, namely both ((A+B)+Cin) and (~(A+B)+(!Cin)), and then using the
> >>>> second output if the first came up negative.
> >>>>
> >>>> ...

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*
>
> 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 Tuesday, July 27, 2021 at 10:11:44 AM UTC-5, EricP wrote:
> MitchAlsup wrote:
> >> On 7/26/2021 10:46 AM, EricP wrote:
> >>> 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.
<
> Because x86/x64 and others (Alpha) put the control bits like round mode
> and denorms-are-zero and exceptions mask, which are inputs,
> in the same HW register as the result exception flags, which are outputs.
> So reading the control bits requires synchronizing with the status bits.
<
Yes, others did it wrong, that does not mean everyone has to do it wrong.
>
> This could penalizes anyone who reads the HW control register
> in order to preserve the control bits setting before changing them.
>
> The HW dependencies for these two sets of information are quite
> different and they never should have been put together.
<
Yes, others did it wrong, that does not mean everyone has to do it wrong
in perpetuity. In My 66000 this field is part of the thread header (256-bits)
and is accessible without privilege and does not have to wait for other
latent activities upon the "regsiter", only upon that 3-bit field. The inst
that read or write (or exchange!) this field only deal with the 3-bits and
the application does not even need to know where the field is located.
>
>
> I would keep the control bits in FpControl and status bits in
> FpStatus registers with separate read and write instructions.
> (I don't see anything so far in IEEE-754 that requires them
> to be stored together in the same HW register.)
<
Only that 9.3 and 9.4 are obeyed.
>
> FpControl bits are inherited from caller and are preserved across calls.
>
> Whether FpStatus flags are preserved or accumulated across any particular
> call is an application, language and/or library routine decision.

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.

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

On 7/27/2021 4:54 AM, 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.
>

FWIW:
SH-4 also put the FPU precision/format in FPSCR. Effectively, one had to
look at the state of this register to make any sense out of what
instructions to decode.

This kinda sucked, and for BJX2, I ended up going in the opposite
direction of not having any FPSCR at all.

>>>
>>> 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.
>
>>>
>>> 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.
>> <
>> And there are cases where this philosophy would blow up code space
>> when they were used. Does the compiler have to generate code for
>> foo() in RNE, and RTPI and RTNI, and RTZ, and RTMAG modes?
>
> 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.
>
>>>
>>>> < Probably the
>>>>> "least awful" would probably be to use an Op64 encoding, which then
>>>>> uses
>>>>> some of the Immed extension bits to encode a rounding mode.
>>>> <
>>>> The argument against having them in instructions is that this prevents
>>>> someone from running the code several times with different rounding
>>>> modes set to detect any sensitivity to the actually chosen rounding
>>>> mode.
>>>> Kahan said he uses this a lot.
>>>
>>> ......let me question the usefulness of that. If I were to do such
>>> experiments I would just compile the algorithm with different rounding
>>> modes set explicitly (e.g. as a C++ template argument or something).
>> <
>> So you would end up with 5 copies of FPPPP, one for each rounding mode
>> (at the cost of 8K×sizeof(inst) per rounding mode = 32KB/mode = 165KB)
>> ??!!?
>
> 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.

I am torn partly between either a pragma, of function-scale attributes.
There is also a possible choice here between:
* __declspec(whatever)
And:
* [[whatever]]

Though, this is more aesthetic than technical, and in BGBCC they are
more or less interchangeable:
* [[dllexport]] void Foo() { ... }
Which technically works I guess...

Then again, it is sort of a similar issue to how, in the recent addition
of lambdas to BGBCC, there are now several semi-redundant notations, eg:
__var():type { ... }
__function[...](...):type { ... }
[...](...)->type { ... }
...

Though, there are some minor differences:
__function allows using a capture list;
Both __var and __function allow lambdas with an unbounded lifespan.

The C23 proposal's lambdas seem to be automatic-lifetime only, and one
doesn't want to use unbounded lifespan where automatic is specified as
this would result in a memory leak (whereas __var and __function default
to unbounded lifetime, with an option to specify automatic lifetime via
__var! or __function!, which is similar to their behavior in BS2).

On 7/27/2021 10:34 AM, 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*

I think it is somewhere between the two formulations. If a function
*cares* what the RM is, it has to at least check, that it is in the
correct (for its requirements) mode. So it has to read the current RM
state, and only if it is different from its requirements, do the
save/modify/restore stuff. Given that, depending upon the specifics, it
may be cheaper to just do the save/change/restore, but that is very
system and application dependent.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

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

On Tuesday, July 27, 2021 at 11:13:12 AM UTC-6, MitchAlsup wrote:

> Then there is the fact that while a DRAM cell can store for milliseconds
> a positive voltage, it can only store a negative voltage for microseconds.
> (It leaks when storing negative, whereas it does not when positive)

I'm not asking the DRAM cells to store negative voltages. The negative
voltage is only used on the pins for signalling with more states - to give
three states, as opposed to the four used by GDDR6x.

John Savard

On Tuesday, July 27, 2021 at 11:40:56 AM UTC-6, MitchAlsup wrote:
> On Tuesday, July 27, 2021 at 10:11:44 AM UTC-5, EricP wrote:

> > Because x86/x64 and others (Alpha) put the control bits like round mode
> > and denorms-are-zero and exceptions mask, which are inputs,
> > in the same HW register as the result exception flags, which are outputs.
> > So reading the control bits requires synchronizing with the status bits.

> Yes, others did it wrong, that does not mean everyone has to do it wrong.

Oh dear. I'll have to revise the *original* Concertina architecture, then!

John Savard

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

John Savard