[fpc-devel] The new XMM intrinsics

J. Gareth Moreton gareth at moreton-family.com
Thu Jan 16 23:22:01 CET 2020


Hey everyone,

Maybe I'm being a bit pedantic with this, but must we abide by C/C++ 
standards and go by the name __m128 etc. for the 128-bit data type?  
Being as how Pascal tended to go for more readable and BASIC-inspired 
names like Integer and Single, might it be better to name them TM128 
instead?  If not that, then is it possible to add a union-like record 
type to the System unit or the inc files that contain all of the intrinsics?

My vectorcall tests (e.g. tests\test\cg\tvectorcall1.pp) have something 
like this:

{$PUSH}
{$CODEALIGN RECORDMIN=16}
{$PACKRECORDS C}
type
   TM128 = record
     case Byte of
       0: (M128_F32: array[0..3] of Single);
       1: (M128_F64: array[0..1] of Double);
   end;
{$POP}

Granted, given that __m128 will be automatically aligned, all of the 
codealign directives may not be necessary - for example:

type
   TM128 = record
     case Byte of
       0: (M128_F32: array[0..3] of Single);
       2: (M128_F64: array[0..1] of Double);
       3: (M128_Internal: __m128);
   end;

The main thing I'm thinking about is that it's actually rather difficult 
to modify the elements of a variable of type __m128 directly in C/C++ 
because of the type being opaque and difficult to typecast sometimes 
(some compilers will treat it as an array, others will treat it as a 
record type like the above (Visual C++ does this), while others may not 
allow access to its elements at all).  Often, I might want to map a 
4-component vector with Single-type fields x, y, z and w to an aligned 
__m128 type, or Double-type fields Re and Im when dealing with complex 
numbers. That way, I can read from and write to them outside of 
intrinsic calls.

I suppose I'm suggesting we introduce something more usable than what C 
has so people can actually use intrinsics more easily.

Gareth aka. Kit



More information about the fpc-devel mailing list