SIMD support...

[Iain Buclaw]

On 7 January 2012 00:38, Manu <turkeyman at gmail.com> wrote:
> On 7 January 2012 02:00, Walter Bright <newshound2 at 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';