Add support for Delphi 13.1's WinARM64EC platform for various units

[boramis]

This pull request adds support for compiling a lot of the JCL with Delphi 13.1's WinARM64EC platform.

This is a large PR, so I'm happy to split it up as needed. I wanted to get it up for initial feedback and to avoid anyone else duplicating the effort. I've tried to keep the individual commits self-contained and well described, so they can mostly be applied in any order, though given the unit graph, the WinARM64EC DUnit tests don't compile until everything else is in.

• This needs the CPU architectures PR for jedi.inc. It is branched off the NORETURN PR just because I was aiming to minimize hints/warnings, but obviously I expect that to go in faster.

• The DUnit tests now compile and run on Win32, Win64, and WinARM64EC and in Unicode-enabled Delphis. The branch includes multiple fixes to the test framework and it largely all passes. There are new tests for JclLogic which reveal a failure in the existing Win32 assembly code that I haven't tried to fix. Win64 has some failures due to unimplemented JclMath routines. WinARM64EC is entirely green, though I didn't port JclDebug, so those tests have been disabled. Currently that's done by stubbing out the entirety of TestJclDebug.pas and TestJcl8087.pas, which I did to avoid having {$IFDEF}s in the .dpr's USES clause, though I think having it done in the dpr would make it more obvious what isn't being tested.

• There's a fix to TJclStringBuilder.Remove that I made as part of the DUnit cleanup. It's in its own commit, but the failure didn't appear until the DUnit tests were otherwise working.

• I've added many PUREPASCAL implementations, primarily in JclLogic but in a few other places as well. JclSynch's Locked* functions just calls out to the Win32 Interlocked* apis. Where there were assembly functions I didn't need, I wrapped them in {$IFDEF CPUINTEL} blocks.

• libbzip2 is link-on-demand for WinARM64EC and I've verified that JclCompression's 7-zip support works with this (my primary goal). I did just contribute WinARM64EC static linking of the bzip2 to TurboPack Abbrevia, so the .lib file and relevant header changes could be grabbed from there, but it's not something I need or intend to work on.

[Delphier]

@boramis thanks for the PR! I took a quick look at your changes, and I think using {$IFDEF ASSEMBLER} would be a better way to check for assembler support (for JCL, CPUASM should be used instead). What do you think?

[boramis]

I considered that but FPC actually supports non-Intel asm blocks, and I just verified that CPUASM is declared when using jedi.inc with their own WinARM64 target. We’re currently using a stripped down fork for our macOS/Linux support, so I haven’t tried compiling the current stuff with FPC yet, but I didn’t want to preclude someone from working on it from that direction.

[boramis]

Oh, sorry, in terms of using CPUASM vs PUREPASCAL: I don't have a preference there. JCLLogic.pas and JCLMath already had a lot of PUREPASCAL blocks and were the first units I had to translate, so I just carried that to the later units too. I just checked and those two units are the only ones that used PUREPASCAL previously, but I couldn't find any references to CPUASM at all. Happy to rework things however though.

[Delphier]

I noticed that you defined the symbol CPUINTEL and used it in multiple places in the PR. I don't think this symbol is necessary: in JclMath.pas The purpose is to conditionally compile assembly code.

I just verified that CPUASM is declared when using jedi.inc with their own WinARM64 target.

How did you verify this? Was it based on the syntax highlighting in the Delphi 13.1 code editor? On my end, the syntax highlighting is broken in the 64-bit IDE. You can compare and test it with the 32-bit IDE.

[boramis]

Delphi 13.1 declared ASSEMBLER/CPUASM for Windows x86 and x86-64 targets but not ARM64. I assume they don’t have it enabled for their Linux target but haven’t verified.

I’m not at my desk to check Free Pascal again, so I’m not sure on ASSEMBLER, but I did verify that it declares CPUASM for all CPU targets. Jedi.inc enables Intel syntax for those targets and it uses gas syntax otherwise. They have their own WinARM64 support sitting in an open pull request and I used a version compiled with the fpcupdeluxe tool to verify, but I also checked stock FPC on macOS.

In all cases I checked the compiled output with a series of blocks like:

{$IFDEF CPUASM}
WriteLn(‘CPUASM’);
{$ENDIF}

I alluded to it above but we’re using JclCompression/7-zip on macOS and Linux compiling with Free Pascal on both Intel and ARM. Currently that’s a stripped down separate fork so it doesn’t use so many unnecessary units, but I would like to push that support upstream at some point too.