SIMD support...

Manu turkeyman at gmail.com
Fri Jan 6 11:41:16 PST 2012


On 6 January 2012 21:21, Walter Bright <newshound2 at digitalmars.com> wrote:

> On 1/6/2012 5:44 AM, Manu wrote:
>
>> The type safety you're imagining here might actually be annoying when
>> working
>> with the raw type and opcodes..
>> Consider this common situation and the code that will be built around it:
>> __v128 vec = { floatX, floatY, floatZ, unsigned int packedColour ); //
>> pack some
>
>
> Consider an analogy with the EAX register. It's untyped. But we don't find
> it convenient to make it untyped in a high level language, we paint the
> fiction of a type onto it, and that works very well.
>

Damn it, I though we already reached agreement, why are you having second
thoughts? :)
Your analogy to EAX is not really valid. EAX may hold some data that is not
an int, but it is incapable of performing a float operation on that data.
SIMD registers are capable of performing operations of any type at any time
to any register, I think this is the key distinction that justifies them as
inherently 'typeless' registers.


> To me, the advantage of making the SIMD types typed are:
>
> 1. the language does typechecking, for example, trying to add a vector of
> 4 floats to 16 bytes would be (and should be) an error.


The language WILL do that checking as soon as we create the strongly typed
libraries. And people will use those libraries, they'll never touch the
primitive type.

The primitive type however must not inhibit the programmer from being able
to perform any operation that the hardware is technically capable of.
The primitive type will be used behind the scenes for building said
libraries... nobody will use it in front-end code. It's not really a useful
type, it doesn't do anything. It just allows the ABI and register semantics
to be expressed in the language.


> 2. Some of the SIMD operations do map nicely onto the operators, so one
> could write:
>
>   a = b + c + -d;
>

This is not even true, as you said yourself in a previous post.
SIMD int ops may wrap, or saturate... which is it?
Don't try and express this at the language level. Let the libraries do it,
and if they fail, or are revealed to be poorly defined, they can be
updated/changed.

3. A lot of the SIMD opcodes have 10 variants, one for each of the 10
> types. The user would only need to remember the operation, not the
> variants, and let the usual overloading rules apply.
>

Correct, and they will be hidden behind the api of their strongly typed
library counterparts. The user will never need to be aware of the opcodes,
or their variants.


> And, of course, casting would be allowed and would be zero cost.
>

Zero cost? You're suggesting all casts would be reinterprets? Surely:
float4 fVec = (float4)intVec; should perform a type conversion?
Again, this is detail that can/should be discussed when implementing the
standard library, leave this sort of problem out of the language.


Your earlier email detailing your simple API with an enum of opcodes
sounded fine... whatever's easiest really. The hard part will be
implementing the alignment, and the literal syntax.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120106/ad9b21dc/attachment.html>


More information about the Digitalmars-d mailing list