On 2009-02-19 21:04:06 +0100, Bill Baxter <[email protected]> said:
To justify making them primitive types you need to show that they are
widespread, and that there is some good reason that they cannot be
implemented in a library. And even if they can't be implemented in a
library right now, it could be that fixing that reason is better than
making new built-in types. For instance I think there's issues now
with getting the right stack alignment for structs. But that's
something that needs to be fixed generally, not by making new built-in
types that know how to do alignment right.
Firstly they are widespread. They might be hampered by the fact that
they have no direct support in many languages however. There are
reasons that you nowdays have standard vector syntax in GCC. It is a
bit rough (only support basic operations like elementwise add, div, mul
et.c.) and does not support permutations. The cross product is only a
nice to have operator for floats, but it is far from neccisary,
permutations are more painful though as GCC at the moment force you to
write CPU-speciffic intrincics for them.
There are firstly the alignment issuse, but there are as other said
alignment attribute in D as well. More problematic for a library
implementation of these types is however calling conventions.
Passing a vector into a function is very efficient, they can be passed
in registers for both in and out values (if the ABI allows, I think PPC
and x86-64 calling conventions allow for this). The problem with the
GCC versions however is that due to how the vectors work in it, you
have to resort to union hacks to get the scalars out of a vector:
union {
_m128 data;
struct {
float x, y, z, w;
}
}
Unfortunatelly, due to this, in order to make the compiler issue nice
code, you have to work with the vector type only, and only bring out
the union when inspecting the scalars in the vector. Which
unfortunatelly will happen quite often (since the union has an
ambiguous call by value semantic, should it be passed by one or four
xmm regs (assuming x86-64 conventions)).
Also, if a vector is a struct you do get the alignment issuse in some
cases but you may also have different call by value calling conventions
(with the x86-64 they would in principle be the same, but that is just
coincidence).
I do agrre that if it could be implemeted a library type, then it
should, but this doesn't work if you take the fact of calling
conventions into account.
Also, I am sure that the optimiser could more easily make
transformations of vector types than on structs that are being passed
around since the semantics of a primitive type is known by the compiler.
/ Mattias
