Expanded CPU* architecture directives:

[boramis]

• Added new CPUINTEL symbol for any of I8086, I386, or x86-64.
• Added CPUARM and CPUARM64 symbols in the FPC path to match Delphi's symbols.
• Replaced documented CPUx86_64 conditional with CPUX64. Delphi and Free Pascal both define both symbols nowadays, but the JCL/JVCL only ever use CPUX64.

[boramis]

The {$IFDEF CPUX86_64}{$DEFINE CPUX64}{$ENDIF ~CPUX86_64} block that I added to the FPC case may not be necessary. The current documentation shows that both symbols are defined now, but since I was changing the documented symbols I wanted to be careful.

[Delphier]

My suggested changes are as follows:

• Add CPUX64 and deprecate CPUx86_64.
  • CPUx86_64 is not predefined in Delphi, nor is it redefined in Jedi.inc — this should be considered a bug.
  • CPUX64 is predefined in both FPC and Delphi.
• Add CPUX86 and deprecate CPU386: better naming.
• Add CPU32BITS and CPU64BITS, and deprecate CPU32 and CPU64.
  • CPU32BITS and CPU64BITS are Delphi's predefined symbols, and the naming is better.
  • CPU64 is easily confused with CPUX64.

The following are open questions for discussion:

• I don't suggest defining the CPUARM, CPUARM32, and CPUARM64 symbols for now.
  • While adding ARM support to JCL, I haven't yet found a need for these symbols.
  • Once JCL successfully supports ARM, we can decide then whether to add these symbols.
• Regarding CPUINTEL, I don't suggest defining it ahead of time — we'd need a concrete example demonstrating that this symbol is actually necessary.

[boramis]

CPUARM32 is already defined on both FPC and Delphi. CPUARM64 will be necessary if someone creates the .obj files necessary for statically linking bzip2/zlib. As I said, I don't need or want that myself, but I already did that exact thing in Abbrevia and those were the symbols I needed. CPUARM is just bringing FPC in line with what Delphi already defines. Even if they aren't necessary in the jcl right now, jedi.inc is about smoothing over differences between compilers and I think it would be better to include them now rather than relitigate it later.

CPUINTEL isn't actually necessary, it's a shorthand for DEFINED(CPUX86) OR DEFINED(X64). Obviously if we're using $IF in the jedi units we can work around it, but it's a combination that's used a lot. In my original pull request, the two commits that benefited from it the most were
project-jedi/jcl@8e7307f
project-jedi/jcl@720afd7

Regarding CPU386 vs CPUX86, I agree that the latter is a more accurate name, but I still used the former in all of my patches because CPU386 is more visually distinct from CPUX64 so it's easier to tell them apart at a glance.

[Delphier]

• @boramis Then let's not define CPUINTEL — the benefit is too low. If it's just to check CPUX86 OR CPUX64, that's clearly not rigorous enough.
• I do agree with defining the CPUARMXXX-related ones (especially since the CPUARM symbol means different things in FPC and Delphi). I just don't recommend defining them right now. I still lean toward submitting a separate PR for the ARM-related stuff later. Of course, if everyone agrees to handle it now, I have no objection either.

[obones]

FWIW, I'd rather have one PR that works on all this as we have reached some sort of an agreement here.
So please add the ARM ones, and let me know when a PR is ready, and which one (I'm starting to loose track here).

[Delphier]

@obones What is your opinion on the changes suggested above?

[obones]

Well, it's all a bit confusing with #28 and I'm not sure what to think of the CPUINTEL situation which appears to be the same as the suggested ASMX86_OR_X64 in the other PR.

As to the others, I'd define all the possible ones, even if not used already, trying to "bridge the gap" between FPC and Delphi when one defines a symbol the other does not.
And this where the following tables comes handy:

https://docwiki.embarcadero.com/RADStudio/Florence/en/Conditional_compilation_(Delphi)#Predefined_Conditionals
https://www.freepascal.org/docs-html/prog/progap7.html

This may not help the debate over CPU386 versus CPUX86 especially because CPU386 seems to be weirdly be defined when using DCCOSX64

But my desire is here, bridge the gap between the main two compilers around. Oxygene is a different beast altogether, but it should not be forgotten.