<case closed> output filename bug?

[MarkMLl]

Not quite.

I promise that I will resist the temptation to spend the next few hours trawling Intel material to see exactly what variants they try to apply (R) marks etc to :-)

MarkMLl

[PascalDragon]

Not quite.

I promise that I will resist the temptation to spend the next few hours trawling Intel material to see exactly what variants they try to apply (R) marks etc to :-)

At least the Intel® 64 and IA-32 Architectures Software Developer’s Manual contains no mention of x86_64 or x86-64. It's always named Intel® 64.

[KodeZwerg]

https://en.wikipedia.org/wiki/X86-64 thats the only source i found where I for myself would not rely on.

[rvk]

https://en.wikipedia.org/wiki/X86-64 thats the only source i found where I for myself would not rely on.

Well, they are not wrong:

Intel 64 is Intel's implementation of x86-64, used and implemented in various processors made by Intel.

So, Intel just rebranded (and probably expanded) their implementation of x86-64 to Intel 64 ( oops, sorry Intel® 64  ).

[MarkMLl]

https://en.wikipedia.org/wiki/X86-64 thats the only source i found where I for myself would not rely on.

That's your problem.

Code: Text  [Select][+][-]

1. $ uname -a
2. Linux tel-dev-01 4.19.0-21-amd64 #1 SMP Debian 4.19.249-2 (2022-06-30) x86_64 GNU/Linux
3.  

I'd refer you in particular to https://wiki.osdev.org/Target_Triplet , since this is a widely-used convention which is substantially larger than Windows.

However I would note from your earlier

Verbose: Linking C:\Projects\FreePascal\FindFiles\pstalk-x86_64-win64-win32.exe

that "win32" as the widget set name is slightly confusing.

MarkMLl

[KodeZwerg]

That's your problem.

Noticed ✓
Thanks MarkMLI

[MarkMLl]

That's your problem.

Noticed ✓
Thanks MarkMLI

Sorry :-) But it /is/ a widely-used designation, in particular in the context of Linux and anything else (e.g. a multitude of embedded firmware) that uses GCC etc.

To add to the confusion, 32-bit Linux etc. usually refers to itself as "i386" rather than "x86"; however on occasion software still describes itself internally as "i586" if it wants to emphasise that it's compiled for a Pentium or later. I've not checked but I suspect that tools which are still able to produce 16-bit code for DOS etc. probably use "x86" (noting that this includes FPC).

MarkMLl

[PascalDragon]

To add to the confusion, 32-bit Linux etc. usually refers to itself as "i386" rather than "x86"; however on occasion software still describes itself internally as "i586" if it wants to emphasise that it's compiled for a Pentium or later.

I think ArchLinux even had i686 back when it still supported 32-bit x86.

I've not checked but I suspect that tools which are still able to produce 16-bit code for DOS etc. probably use "x86" (noting that this includes FPC).

Where does this include FPC(*)? FPC uses i8086 for the 16-bit x86 target, i386 for the 32-bit x86 target and x86_64 for the 64-bit x86 target. x86 alone is usually only used to describe all three targets at once (e.g. when talking about FPU support).

(*) Yes, FPC defines CPUX86 for the i386 target and not for the other two x86 targets, but in general one should use CPU386 for checks anyway as that is clearer for the user.

[MarkMLl]

Where does this include FPC(*)? FPC uses i8086 for the 16-bit x86 target, i386 for the 32-bit x86 target and x86_64 for the 64-bit x86 target. x86 alone is usually only used to describe all three targets at once (e.g. when talking about FPU support).

(*) Yes, FPC defines CPUX86 for the i386 target and not for the other two x86 targets, but in general one should use CPU386 for checks anyway as that is clearer for the user.

TFT, I was hoping you'd correct me if necessary although I'd suggest that internal identifiers like CPUX86 are distinct from the public triplets used by e.g. the linker.

MarkMLl

[KodeZwerg]

To personal me there is no confusing since i do when needed this

Code: Pascal  [Select][+][-]

1.    {$IFDEF WIN32}
2.   execute 32bit code
3.    {$ENDIF}
4.    {$IFDEF WIN64}
5.   execute 64bit code
6.    {$ENDIF}
7.  

[PascalDragon]

To personal me there is no confusing since i do when needed this

Code: Pascal  [Select][+][-]

1.    {$IFDEF WIN32}
2.   execute 32bit code
3.    {$ENDIF}
4.    {$IFDEF WIN64}
5.   execute 64bit code
6.    {$ENDIF}
7.  

Please be aware that WIN64 is also set for aarch64-win64, so if you have x86_64 specific code that would then fail when compiled for Aarch64. Also if you really have code that is simply different regarding bitness you can just as well use CPU32 and CPU64 which will also work on non-Windows targets.

[KodeZwerg]

To personal me there is no confusing since i do when needed this

Code: Pascal  [Select][+][-]

1.    {$IFDEF WIN32}
2.   execute 32bit code
3.    {$ENDIF}
4.    {$IFDEF WIN64}
5.   execute 64bit code
6.    {$ENDIF}
7.  

Please be aware that WIN64 is also set for aarch64-win64, so if you have x86_64 specific code that would then fail when compiled for Aarch64. Also if you really have code that is simply different regarding bitness you can just as well use CPU32 and CPU64 which will also work on non-Windows targets.

Thank you Grandmaster for the cpu-switches but i like to ask because i do not know those:
Would they work same like win32/64 ?
I mean, win32/64 does react on how i set my compiler target, independently of my cpu or operating system.
On what does cpu32/64 react please?
Thanks in advance!

[rvk]

On what does cpu32/64 react please?

You can find them here: https://www.freepascal.org/docs-html/prog/progap7.html
So they react on the chosen target.

CPU16   Free Pascal target is a 16-bit CPU.
CPU32   Free Pascal target is a 32-bit CPU.
CPU64   Free Pascal target is a 64-bit CPU.

[KodeZwerg]

So they react on the chosen target.

Noted ☑
Thank you rvk, will use them from now on!