Janis Johnson wrote:
> Oops. I guess we can blame the AltiVec PIM after all.
I think we certainly want to honor the existing standards here,
including the AltiVec PIM and SPE specification. Perhaps we should
leave the issue of the default behavior aside for the moment. I think
it's clear what the specifications should have said, from a
truth-and-beauty language design perspective, but, hey, we are where we are.
Let's accept that both the bit-preserving and value-preserving
conversions would be useful. How do we differentiate the two?
In C++, we could invent __value_cast<T> and __bitwise_cast<T>. For
example, __bitwise_cast<int>(3.0f) would be defined as equivalent to:
({
union {
int i;
float f;
} temp;
temp.f = 3.0f;
temp.i;
})
which would give reasonable semantics, in terms of other things that are
already defined. __value_cast<T> would just be an alias for
static_cast<T> for non-vector types, but for vector types it would do a
value-preserving conversion, even if C-style and static casts are
bit-preserving, for backwards compatibility.
For vectors, these operators would apply to each element, and then
return a vector with the same number of elements as the input vector.
I suppose that we could introduce these operators into C as well,
although the pseudo-template syntax might not be as natural for C users.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
