The point is that the existing Altivec and SPE cast syntax requires that
a C-style cast from one vector type to another be bit-preserving. So,
we can't change that (or static_casts, which are the kind of C++ cast
that are using to implement this kind of C-style cast) without breaking
backward
If you're interested in adding value for generic vectors, it may be
interesting to consider element access operations. Being able to
write things like:
float X = V[1];
or
V[2] = X;
That was on my todo list, but unfortunately I have little time for FSF
work now and this would require me to
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| > I agree with everything you have said. I suppose I'm a bit unclear
| > about this:
| >
| >already defined. __value_cast would just be an alias for
| >static_cast for non-vector types, but for vector types it woul
Gabriel Dos Reis wrote:
> I agree with everything you have said. I suppose I'm a bit unclear
> about this:
>
>already defined. __value_cast would just be an alias for
>static_cast for non-vector types, but for vector types it would do a
>value-preserving conversion, even if C-style
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Chris Lattner wrote:
| >
| > On Apr 19, 2006, at 1:56 PM, Mark Mitchell wrote:
| >
| >> Let's accept that both the bit-preserving and value-preserving
| >> conversions would be useful. How do we differentiate the two?
| >>
| >
| >> For vectors, these
Chris Lattner wrote:
>
> On Apr 19, 2006, at 1:56 PM, Mark Mitchell wrote:
>
>> Let's accept that both the bit-preserving and value-preserving
>> conversions would be useful. How do we differentiate the two?
>>
>
>> For vectors, these operators would apply to each element, and then
>> return a
On Apr 19, 2006, at 1:56 PM, Mark Mitchell wrote:
Let's accept that both the bit-preserving and value-preserving
conversions would be useful. How do we differentiate the two?
For vectors, these operators would apply to each element, and then
return a vector with the same number of elements
Joe Buck wrote:
> On Wed, Apr 19, 2006 at 01:56:46PM -0700, Mark Mitchell wrote:
>> 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 and __bitwise_cast. For
>> example, __bitw
On Wed, Apr 19, 2006 at 01:56:46PM -0700, Mark Mitchell wrote:
> 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 and __bitwise_cast. For
> example, __bitwise_cast(3.0f) would b
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
There is the Spe PEM as well (Freescale 8540/8548). On the Spe we
defined a vector type that has no
definition of vector elements. (__ev64_opaque__).
It was designed such that casting from this type to any other vector
type of the same
size can only be accomplished by bit-preserving conversion
>
> I think, like Ian, that conversions from V4SF to V4SI, via an ordinary
> cast, should perform a conversion; this should be the same as converting
> each of the individual floats to int. Then, since the bit-preserving
> conversion is also useful, we should have another syntax for that.
>
> Ho
On Wed, Apr 19, 2006 at 05:53:30PM +0100, Andrew Haley wrote:
> Janis Johnson writes:
> > On Wed, Apr 19, 2006 at 05:30:54PM +0200, Paolo Bonzini wrote:
> > >
> > > The C spec for Altivec (not the ISA) is a horrible spec that set a
> > > horrible de facto standard. To some extent, gcc alread
Janis Johnson writes:
> On Wed, Apr 19, 2006 at 05:30:54PM +0200, Paolo Bonzini wrote:
> >
> > The C spec for Altivec (not the ISA) is a horrible spec that set a
> > horrible de facto standard. To some extent, gcc already departed from
> > Altivec, for example by disallowing the (vector in
On Wed, Apr 19, 2006 at 05:30:54PM +0200, Paolo Bonzini wrote:
>
> The C spec for Altivec (not the ISA) is a horrible spec that set a
> horrible de facto standard. To some extent, gcc already departed from
> Altivec, for example by disallowing the (vector int) (1, 2, 3, 4) syntax
> -- notice t
I think, like Ian, that conversions from V4SF to V4SI, via an ordinary
cast, should perform a conversion; this should be the same as converting
each of the individual floats to int. Then, since the bit-preserving
conversion is also useful, we should have another syntax for that.
However, the Alti
> Of course, it is not practically doable, to have vector typecasts
> preserve values (FLOAT_EXPR) on SSE and bits (VIEW_CONVERT_EXPR) on
> Altivec. The availability of generic vector types, which were
> overhauled in order to provide portable vector support even for machines
> without SIMD ha
> "Vector types can be cast to other vector types. The cast does not
> perform a conversion: it preserves the 128-bit pattern, but not
> necessarily the value. A cast between a vector type and a scalar type is
> not allowed."
Everything becomes clear. I would never have started this thread
Paolo Bonzini writes:
>
> > > The short answer is that AltiVec dictated this behavior. :-( Longer
> > > answers were given by Ian and Paul, and I agree with them.
> >
> > OK, so: firstly, is this behaviour actually documented anywhere? In
> > AltiVec docs, maybe?
> >
> http://publi
> The short answer is that AltiVec dictated this behavior. :-( Longer
> answers were given by Ian and Paul, and I agree with them.
OK, so: firstly, is this behaviour actually documented anywhere? In
AltiVec docs, maybe?
http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?
Paolo Bonzini writes:
> Andrew Haley wrote:
> > Converting a vector of floats (via a cast) to a vector of ints of the
> > same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
> > converted. This is different from a cast from scalar float to int,
> > where a conversion is per
Andrew Haley wrote:
Converting a vector of floats (via a cast) to a vector of ints of the
same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
converted. This is different from a cast from scalar float to int,
where a conversion is performed.
From what I can see of the source,
Paul Brook <[EMAIL PROTECTED]> writes:
> > In general there is a conflict within gcc between treating vectors as
> > unitary types and treating them as collections. In this case we are
> > treating them as unary. However, I think that by analogy to the way
> > we handle arithmetic, and given the
Paul Brook <[EMAIL PROTECTED]> writes:
[...]
| It seems like straight bit-copy "conversion" is a useful feature, so I guess
| we'd want to invent some syntax for this.
memcpy?
-- Gaby
Ian Lance Taylor writes:
[...]
| That is, I think this is a bug.
I agree.
-- Gaby
On Wednesday 19 April 2006 14:41, Ian Lance Taylor wrote:
> Andrew Haley <[EMAIL PROTECTED]> writes:
> > Converting a vector of floats (via a cast) to a vector of ints of the
> > same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
> > converted. This is different from a cast fro
Andrew Haley <[EMAIL PROTECTED]> writes:
> Converting a vector of floats (via a cast) to a vector of ints of the
> same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
> converted. This is different from a cast from scalar float to int,
> where a conversion is performed.
In gen
Daniel Jacobowitz wrote:
On Wed, Apr 19, 2006 at 08:58:59AM -0400, Robert Dewar wrote:
Andrew Haley wrote:
Converting a vector of floats (via a cast) to a vector of ints of the
same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
converted. This is different from a cast from
On Wed, Apr 19, 2006 at 08:58:59AM -0400, Robert Dewar wrote:
> Andrew Haley wrote:
> >Converting a vector of floats (via a cast) to a vector of ints of the
> >same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
> >converted. This is different from a cast from scalar float to in
Andrew Haley wrote:
Converting a vector of floats (via a cast) to a vector of ints of the
same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
converted. This is different from a cast from scalar float to int,
where a conversion is performed.a
Yes, that's the way C is defined
30 matches
Mail list logo
