[fpc-devel] The new XMM intrinsics
J. Gareth Moreton
gareth at moreton-family.com
Sat Jan 18 20:44:04 CET 2020
Seems fair.
The main thing that I'm wary of is memory alignment. SSE works best
with structures that are aligned to a 16-byte boundary - attempting to
call MOVAPS with a structure that isn't aligned will trigger an access
violation, while MOVUPS is considerably slower on older processors.
This is why I suggested something like the following some time ago,
instead of depending on slightly messy pre-processor directives:
*type *TVector4 = *record*
X, Y, Z, W: Single
*end **align *16;
Gareth aka. Kit
On 18/01/2020 19:39, Sven Barth via fpc-devel wrote:
> Am 18.01.2020 um 18:52 schrieb J. Gareth Moreton:
>>
>> I think more than anything I would like to see a degree of "ease of
>> use" for the SIMD intrinsics, since modifying __m128 data in C/C++ is
>> not that straightforward. Just as a straightforward example, what
>> might be the best way to ensure these following record types are
>> compatible with the __m128 data types?
>>
>> *type *TVector4 = *record*
>> X, Y, Z, W: Single;
>> *end*; // compatible with __m128f
>>
>> *type *TComplex = *record*
>> Re, Im: Double;
>> *end*; // compatible with __m128d
>>
>> Programmers on their own projects, whether it be a game or a
>> mathematical program, would much rather work with those constructs if
>> it can be helped... or at least I would.
>>
> The compiler currently considers corresponding arrays as compatible,
> like "array[0..3] of Single" or "array[0..1] of Double". In theory
> nothing would stop us from implementing similar compatibility with the
> records you mentioned.
>
> Though to be really useable it would need to be flexible enough to
> handle for the following for example as well:
>
> === code begin ===
>
> type
> TVector3 = record
> X, Y, Z: Single;
> end;
>
> TVector4 = record
> P: TVector3;
> W: Single;
> end;
>
> === code end ===
>
> Regards,
> Sven
>
> _______________________________________________
> fpc-devel maillist - fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20200118/523d36a7/attachment.html>
More information about the fpc-devel
mailing list