Re: [fpc-devel] Rules about record types and internal storage

Agreed.  Sometimes it is a question of how much should be left to the compiler and how much should be left to the programmer when it comes to optimisation. Gareth aka. Kit On 02/04/2020 23:42, Sven Barth via fpc-devel wrote: J. Gareth Moreton > schrieb am

Re: [fpc-devel] Rules about record types and internal storage

J. Gareth Moreton schrieb am Do., 2. Apr. 2020, 22:33: > Hi Jonas, > > I brought that up because Florian once asked about just doing everything > as vectorcall on Win64 because the calling convention, by and large, is > a compatible extension to its default one. I think issues of >

Re: [fpc-devel] Rules about record types and internal storage

Hi Jonas, I brought that up because Florian once asked about just doing everything as vectorcall on Win64 because the calling convention, by and large, is a compatible extension to its default one.  I think issues of compatibility and third-party interfacing makes it not the best idea unless

Re: [fpc-devel] Rules about record types and internal storage

On 02/04/2020 21:25, J. Gareth Moreton wrote: > Am I right in thinking that, for C alignment, each field is aligned > according to its data size? For example, if you had: > > TType = record >   Field1: Byte >   Field2: LongInt; > end; > > Are there are three unused bytes between Field1 and

Re: [fpc-devel] Rules about record types and internal storage

Hi Sven, Am I right in thinking that, for C alignment, each field is aligned according to its data size? For example, if you had: TType = record   Field1: Byte   Field2: LongInt; end; Are there are three unused bytes between Field1 and Field2 and the structure as a whole is 8 bytes long and

Re: [fpc-devel] Rules about record types and internal storage

On 02/04/2020 17:59, J. Gareth Moreton wrote: > For a reference, it's the /Gv compiler option: > https://docs.microsoft.com/en-us/cpp/cpp/vectorcall?view=vs-2019 https://www.freepascal.org/docs-html/prog/progsu7.html and fpc -h ... -Cc Set default calling convention to Jonas

Re: [fpc-devel] Rules about record types and internal storage

For a reference, it's the /Gv compiler option: https://docs.microsoft.com/en-us/cpp/cpp/vectorcall?view=vs-2019 If anything it's proving to be an interesting study case on how to make something optimal when given code that doesn't give the compiler many clues.  Granted, given the sample

Re: [fpc-devel] Rules about record types and internal storage

Apologies - I wasn't clear.  There is an option in the MSVC compiler to default to vectorcall, but you have to specify it. Gareth aka. Kit On 02/04/2020 16:16, Sven Barth via fpc-devel wrote: Sven Barth > schrieb am Do., 2. Apr. 2020, 17:10: P.S.

Re: [fpc-devel] Rules about record types and internal storage

Sven Barth schrieb am Do., 2. Apr. 2020, 17:10: > 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

Re: [fpc-devel] Rules about record types and internal storage

J. Gareth Moreton schrieb am Do., 2. Apr. 2020, 15:25: > 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:

[fpc-devel] Rules about record types and internal storage

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