[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