On 7 January 2012 02:00, Walter Bright
<newshound2@digitalmars.com> wrote:
On 1/6/2012 12:45 PM, Manu wrote:
In computer graphics it's common to work with float16's, a type not supported by
simd units. Pack/Unpack code involved detailed float/int interaction.
You might take a register of floats, then mask the exponent and then perform
integer arithmetic on the exponent to shift it into the float16 exponent
range... then you will mask the bottom of the mantissa and shift them into place.
Unpacking is same process in reverse.
Other tricks with the float sign bits, making everything negative, by or-ing in
1's into the top bits. or you can gather the signs using various techniques..
useful for identifying the cell in a quad-tree for instance.
Integer manipulation of floats is surprisingly common.
I'm aware of such tricks, and actually do them with the floating point code generation in the compiler back end. I don't think that renders the idea that floats and ints should be different types a bad one.
I'd also argue that such tricks are tricks, and using a reinterpret cast on them makes it clear in the code that you know what you're doing, rather than doing something bizarre like a left shift on a float type.
I've worked a lot with large assembler programs. As you know, EAX has no type. The assembler code would constantly shift the type of things that were in EAX, sometimes a pointer, sometimes an int, sometimes a ushort, sometimes treating a pointer as an int, etc. I can unequivocably state that this typeless approach is confusing, buggy, hard to untangle, and ultimately a freedom that is not justifiable.
Static typing is a big improvement, and having to insert a few reinterpret casts is a good thing, not a detriment.
To be clear, I'm not opposing strongly typing vector types... that's my primary goal too. But they're not as simple I think you believe.
From experience, microsoft provices __m128, but GCC does what you're proposing (although I get the feeling it's not a 'proposal' anymore).
GCC uses 'vector float', 'vector int', 'vector unsigned short', etc...
I hate writing vector code the GCC way, it's really ugly. The lines tend to become dominated by casts, and it's all for nothing, since it all gets wrapped up behind a library anyway.
Secondly, you're introducing confusion. A cast from float4 to int4... does it reinterpret, or does it type convert?
In GCC it reinterprets, but what do you actually expect? and regardless of what you expect, what do you actually WANT most of the time...
I'm sure you'll agree that the expected/'proper' thing would be a type conversion (and I know you're into 'proper'-ness), but in practise you almost always want to reinterpret. This inevitably leads to ugly reinterpret syntax all over the place.
If it were a typeless vector reg type, it all goes away.
Despite all this worry and effort, NOBODY will ever use these strongly typed (but still primitive) types of yours. They will need to be extended with bunches of methods, which means wrapping them up in libraries anyway, to add all the higher level functionality... so what's the point?
The only reason they will use them is to wrap them up in a library of their own, at which point I promise you they'll be just as annoyed as me by the typing and need for casts all over the place to pass them into basic intrinsics.
But if you're insistent on doing this, can you detail the proposal...
What types will exist?
How will each one cast/interact?
What about error conditions/exceptions? How do I control these? ...on a per-type basis?
What about CTFE, will you add understanding for every operation supported by each type? This is easily handled in a library...
How will you assign literals?
How can you assign a typeless literal? (a single 128bit value, used primarily for masks)
What operators will be supported... and what will they do?
Will you extend support for 64bit and 256bit vector types, that's a whole bundle more types again... I really feel this is polluting the language.
... is this whole thing just so you can support MADD? If so, there are others to worry about too...