Hi everyone,
I'm just trying to get properly versed with the rules of record types
over here: https://www.freepascal.org/docs-html/ref/refsu15.html
For standard record types (no "packed" modifier or compiler directives
or anything), I'm wondering how many liberties that the compiler is
allowed to take in storing its data. Take the following example (from
raybench.pas over here: http://runtimeterror.com/tools/raybench ):
type
Vec = record
X, Y, Z: Single;
end;
function VLength(const V: Vec): Single;
begin
Result:=Sqrt(V.X*V.X + V.Y*V.Y + V.Z*V.Z);
end;
If you wanted to get the highest speed possible for this routine on an
Intel processor, one solution would be to pack X, Y and Z together, have
an invisible 4th dummy field, and align the entire record to a 16 byte
boundary, because then you could pass the entire record by value through
an XMM register and the VLength operation can be performed with just a
pair of VDPPS (dot product) and VSQRTSS (square root) instructions.
Obviously if you use 'packed record' or a compiler directive to change
things up, this may not be possible, but at what points is the compiler
allowed to make its own choice on what might be best?
Gareth aka. Kit
P.S. Of course you can force it by forcing the vector to be an m128 type
and specifying vectorcall for x86_64-win64, but not everyone will know
to do that and it gets unwieldly rather quickly. Speaking of
vectorcall, I'm wondering if we can introduce 'fastcall' as an alias for
'ms_abi_default', mostly so if we follow Microsoft Visual C++'s example
of automatically making all routines vectorcall (which is closer to the
System V ABI used by linux and will make vectorisation easier), we can
force the default one if we need a routine that, say, has to interface
with a third-party library ('fastcall' under win32 is what the MS ABI is
based off... first parameter in ECX, second in EDX and everything else
on the stack).
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
