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)

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

Likewise.

> /Marcus