From: ThatWouldBeTelling@thevillage.com
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.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
