From: cr88192@gmail.com
On 10/3/2025 11:40 AM, EricP wrote:
> MitchAlsup wrote:
>> My 66000 2.0
>>
>> After 4-odd years of ISA stability, I ran into a case where
>> I needed to change the instruction formats.
>> And after bragging to Quadribloc about its stability--it reached the
>> point where it was time to switch to version 2.0.
>>
>> Well, its time to eat crow.
>> --------------------------------------------------------------
>> Memory reference instructions already produce 64-bit values
>> from Byte, HalfWord, Word and DoubleWord memory references
>> in both Signed and unSigned flavors. These supports both integer and
>> floating point due to the single register file.
>>
>> Essentially, I need that property in both integer and floating
>> point calculations to eliminate instructions that merely apply value
>> range constraints--just like memory !
>
> Why? Compilers do not have any problem with this
> as its been handled by overload resolution since forever.
>
> Its people who have the problems following type changes and most
> compilers will warn of mixed type operations for exactly that reason.
>
>> ISA 2.0 changes allows calculation instructions; both Integer and
>> Floating Point; and a few other miscellaneous instructions (not so
>> easily classified) the same uniformity.
>>
>> In all cases, an integer calculation produces a 64-bit value
>> range limited to that of the {Sign}×{Size}--no garbage bits
>> in the high parts of the registers--the register accurately
>> represents the calculation as specified {Sign}×{Size}.
>>
>> Integer and floating point compare instructions only compare
>> bits of the specified {Size}.
>>
>> Conversions between integer and floating point are now also
>> governed by {Size} so one can directly convert FP64 directly
>> into {unSigned}×{Int16}--more fully supporting strongly typed
>> languages.
>
> Strongly typed languages don't natively support mixed type operations.
> They come with a set of predefined operations for specific types that
> produce specific results.
>
> If YOU want operators/functions that allow mixed types then they force
> you to define your own functions to perform your specific operations,
> and it forces you to deal with the consequences of your type mixing.
>
> All this does is force YOU, the programmer, to be explicit in your
> definition and not depend on invisible compiler specific interpretations.
>
> If you want to support Uns8 * Int8 then it forces you, the programmer,
> to deal with the fact that this produces a signed 16-bit result
> in the range -128*256..+127*256 = -32768..32512.
> Now if you want to convert that result bit pattern to Uns8 by truncating
> it to the lower 8 bits, or worse treat the result as Int8 and take
> whatever random value falls in bit [7] as the sign, then that's on you.
> They just force you to be explicit what you are doing.
>
>> --------------------------------------------------------------
>> Integer instructions are now:: {Signed and unSigned}×{Byte,
>> HalfWord, Word, DoubleWord}
>> while FP instructions are now:
>> {Byte, HalfWord, Word, DoubleWord}
>
> I doubt any compilers will use this feature.
> Strong typed languages don't have predefined operators that allow mixing.
> Weak typed languages deal with this in overload resolution and by having
> predefined invisible type conversions in those operators and then using
> the normal single type arithmetic instructions.
>
>> Although I am oscillating whether to support FP8 or FP128.
>
> The issue with FP8 support seems to be that everyone who wants it also
> wants their own definition so no matter what you do, it will be unused.
>
> The issue with FP128 seems associated with scaling on LD and ST
> because now scaling is 1,2,4,8,16 which adds 1 bit to the scale field.
> And in the case of a combined int-float register file deciding whether
> to expand all registers to 128 bits, or use 64-bit register pairs.
> Using 128-bit registers raises the question of 128-bit integer support,
> and using register pairs opens a whole new category of pair instructions.
>
I generally went with register pairs...
Where, say, for base types:
8-bits: Rarely big enough
16-bits: Sometimes big enough
32-bits: Usually big enough
64-bits: Almost always big enough
Vector types:
2x: Good
4x: Better
8x: Rarely Needed
For a scalar type, the high 64 bits of a 128-bit register would be
almost always wasted, so it isn't worthwhile to spend resources on
things that are mostly just going to waste.
At least with 64-bit registers, they cover:
Integer values: Usually overkill
'int' is far more common than 'long long'.
Floating Point: Usually Optimal
Binary64 is almost always good.
Binary32 is frequently insufficient.
2x Binary32 and 4x Binary16: OK
Then, 128-bit as pairs:
Deals with the occasional 128-bit vector and integer;
Avoids wasting resources all the times we don't need it.
Well, since computation isn't exactly a gas that expands to efficiently
utilize the register size (going bigger = diminishing returns).
If the CPU is superscalar, can use 2x64b lanes for the 128-bit path, ...
As for Binary128:
Infrequently used;
Too expensive for direct hardware support;
So, ended up adding a trap-only support;
Trap-only allows it to exist without also eating the FPGA.
As for FP8:
There are multiple formats in use:
S.E3.M4: Bias=7 (Quats / Unit Vectors)
S.E3.M4: Bias=8 (Audio)
S.E4.M3: Bias=7 (NN's)
E4.M4: Bias=7 (HDR images)
Then, for 16-bit:
S.E5.M10: Generic, Graphics Processing, Sometimes 3D Geometry
Sometimes not enough dynamic range.
S.E8.M7: NNs
Usually not enough precision.
It is likely the more optimal 16-bit format might actually be S.E6.M9,
but this is non-standard.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
