SIMD support...

[Manu]

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.

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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120107/d6016c67/attachment.html>