Hi everyone,

I may need some help with this one.  Is there a tried and tested way of getting FPC to build and install on aarch64-win64? (I assume that's the correct OS for Windows for ARM64).  The make script doesn't seem to accept the combination of CPU_TARGET=aarch64 OS_TARGET=win64 and it's a struggle to even find the right tools for this platform.

Kit

Aah, partially answered.  It's not supported in 3.2.2, but there is better support for it in the trunk.

Kit

J. Gareth Moreton wrote

Aah, partially answered.  It's not supported in 3.2.2, but there is better support for it in the trunk.

You had me worried there for a moment that someone regenerated the makefiles with an older version of fpcmake... ^^'

Anyway, aside from using main you need to make sure that you have a current version of clang installed and preferrably in PATH, because FPC uses it as assembler.

You then call make like this (adding parallelisation options as desired of course):

make all OS_TARGET=win64 CPU_TARGET=aarch64 BINUTILSPREFIX=

(note that there is a space between the last "=" and the end of the command line)

Regards,
Sven

Thanks Sven.  I'm predicting a future of Windows on AArch64, since Windows is not going anywhere but Arm processors are starting to really take off beyond mobile devices.

Kit

Thought I'd give a small update.

I was distracted over the past month with work, the arm-linux blocking bug and a couple of merge requests which were much easier to develop!  I'm now having a solid bash at getting Windows on ARM64 working.  It's proving harder than anticipated because I can't install common helper tools like Cygwin because there isn't a native AArch64 version available (and x64 is not supported for emulation, it seems... only x86), and Microsoft Visual Studio (which contains a working assembler) absolutely refuses to install because Windows 10 on ARM64 is not supported, only Windows 11 (and my Raspberry Pi is not "ready" to upgrade to Windows 11).

I did manage to get the make process to complete with the options that Sven listed, but despite all of the packages building, the resultant "ppca64" executable immediately exited with no messages or anything, even if I specified "ppca64 -i" to display supported information.  I'm not sure if this is due to the bugs regarding exceptions and case blocks, or some other reason.

Nevertheless, it is a problem I am determined to solve.  I hope I'm not acting too greedy with the bounty, but one of my contracts is extremely late in paying me and it's left me in a dire financial position... hunger can be a good motivator sometimes! Also I figured since I have some experience with AArch64, this is something I should be able to handle.

Gareth aka. Kit

J. Gareth Moreton via fpc-devel schrieb am
Sa., 25. Mai 2024, 10:49:

Emulation of x86_64 requires Windows 11 ;)

You should be able to install clang natively, then you can use that assembler. After all that's the one we need to cooperate with anyway...

It's very likely the case blocks, cause the compiler contains quite a lot of them.

Regards,
Sven

Indeed - I'm not giving up!  I installed Clang via LLVM.  Which of the EXE files is actually the assembler?  It's not entirely clear (no "clang-as", for example).  (Although I trust it works!)

I've got some ideas as to how to start debugging.  I will solve this puzzle!

Kit

J. Gareth Moreton via fpc-devel schrieb am
Sa., 25. Mai 2024, 22:18:

Indeed - I'm not giving up! I installed Clang via LLVM. Which of the EXE files is actually the assembler? It's not entirely clear (no "clang-as", for example). (Although I trust it works!)

Simply check what FPC calls. ;)

I've got some ideas as to how to start debugging. I will solve this

puzzle!

There is a tool that converts DWARF to CodeView, you can use that to debug with WinDBG.

Regards,
Sven

Thank you for all your assistance with this Sven.

One trick I have been doing is writing equivalent programs in C/C++ to see how Clang and MSVC convert them into equivalent assembly language.  It's providing some insights at least in regards to what works.  My first attempted fix (putting the jump table in the same section as the actual code) unfortunately didn't work, so it's something more subtle.

Kit

Hopefully the first issue has now been resolved, although it may require refactoring later.

https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/691

The main issue is that, for some reason, trying to dereference from a code section instead of a data section raises an access violation, although I'm not sure if it's a permissions issue or a subtle fault with the pointers.  This may require refactoring later on or if bugs manifest in larger projects.

Kit