On 7 January 2012 00:38, Manu <turkey...@gmail.com> wrote: > On 7 January 2012 02:00, Walter Bright <newshou...@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. >
FYI, vector conversion in GCC is roughly to the idiom of *(float4 *)&X; in C. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';