Re: arm_neon.h / vext_u64 (uint64x1_t __a, uint64x1_t __b, __const int __c)

[Jochen Barth <jpunktbarth@gmail.com>]

Thanks a lot! Regards, Jochen

Von meinem iPhone gesendet

> Am 10.09.2020 um 10:35 schrieb Tamar Christina <Tamar.Christina@arm.com>:
> 
> Hi Jochen,
> 
>> -----Original Message-----
>> From: Jochen Barth <jpunktbarth@gmail.com>
>> Sent: Thursday, September 10, 2020 9:14 AM
>> To: Tamar Christina <Tamar.Christina@arm.com>
>> Cc: gcc-help <gcc-help@gcc.gnu.org>
>> Subject: Re: arm_neon.h / vext_u64 (uint64x1_t __a, uint64x1_t __b,
>> __const int __c)
>> 
>> Dear Tamar,
>> 
>> Sorry, I do no get the point:
>> 
>>>>> EXT is a byte level extract, if you have a 64 bit vector and a
>>>>> 64-bit type like uint64x1_t then the only possible index for n is 0.
>> 
> 
> Because those intrinsics are not doing byte level extraction. They are convenience functions that
> do not allow partial extraction of a type. For instance vext_s16 which takes an int16x4_t as input
> restricts the values of n to 0 to 3 because when used with the EXT instruction it always
> makes sure they're a multiple of 2 bytes since a int16 is two bytes.
> 
> A uint64x1_t is a vector of 8 bytes which the intrinsic does as a group of 8 bytes since it
> Always wants to extract whole numbers. As such the only possible index is 0.
> 
> To get the behavior you have in your example you need to do the extraction on bytes using
> vext_u8 which will allow you to corrupt the number. i.e.
> 
> what you want is
> 
> vreinterpret_u64_u8 (vext_u8 (vreinterpret_u8_u64 (a), vreinterpret_u8_u64 (b), <number>))
> 
> where your extraction happens on bytes. In this case n has the range 0-7.
> 
> Instead of looking at the Arm ARM you should look at the definition of the intrinsics
> https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics
> 
> Regards,
> Tamar
> 
>> But my previous examples with n=c=1..7 showed that different (n=c)'s are
>> possible,
>> 
>> why is "the only possible index for n=0" ?
>> 
>> Kind regards, Jochen