Lazarus for Windows on aarch64 (ARM64) - Native Compiler

[msintle]

If I would have the time I would be quite tempted by this... But that would still have the problem to have Windows running in a usable simulation environment. And as it seems that solutions like UTM are essentially QEMU and KVM seems to not be working correctly on either UTM or Asahi Linux according to various sources (thus meaning bad performance) I can just as well use the Pi 4 I have (where KVM does work by the way) or lend the Windows Dev Kit 2023 from my workplace...

Simulation? You'll have Windows 11 on ARM64 running flawlessly, even including GPU acceleration, legally and for free using VMware Fusion. This will be super fast (almost as fast as the paid Parallels) as VMware Fusion still is a very highly performant hypervisor. Take it while you can, I'd say. In fact, on this M3 Supermax, your virtualized Windows could run faster (and will certainly have more memory) than native Microsoft or other vendor Snapdragon hardware (none go to 128 GB RAM, and the RAM is all soldered, so utterly non-upgradeable).

[Wallaby]

Fingers crossed, but the latest changes appear to have fixed the exception handling! We may be able to compile for win64-aarch64 soon!

I have tested my program from #40203 and it now produces the expected output!

Thank you soooo much @PascalDragon!

[DonAlfredo]

Can confirm the good news !! I can now run a cross-compiled version of fpcupdeluxe natively on arm64 Windows !!

[PascalDragon]

Hold your horses, please. As long as a cross compiled compiler is not able to compile itself I'm not going to trust the code... (and that is not working correctly currently)

[msintle]

Unfortunately the M3 Supermax has been repurposed at our end.

We still do have a Starlight M3 Air 15.3" 2 TB 24 GB available as a bounty for the eventual resolution of this problem.

Please note battery shipping restrictions still apply as they are immutable at courier's end.

[abouchez]

I have modified mORMot to compile on this target.
I can run mormot.core.base and mormot.core.os and retrieve some system information:

Code: [Select]

admin@ARM64-WIN C:\Users\Admin\Documents>winarm
Run mORMot 2.3.8892 with Free Pascal 3.3.1 64 bit
OSVersionText=Windows 11 24H2 (10.0.26100.2314)
CpuInfoText=4 x Apple Silicon [12MB] (aarch64)
CpuCacheText=L1=4*128KB  L2=12MB
BiosInfoText=Parallels International GmbH. Parallels ARM Virtual Machine 0.1   
ToTextOS=Windows 11 26100
ahcAES
ahcCRC32
ahcSHA1
But when mormot.core.unicode initializes, then there is a "try..finally" block with an "exit" which does not call the "finally" block.
So execution can't go any further.

And when I include all mormot units, then I have a linking issue:

Code: [Select]

(9015) Linking /home/ab/dev/lib2/test/bin/fpc-aarch64-win64/mormot2tests.exe
Error: (9221) Undefined symbol: MORMOT.DB.RAW.SQLITE3$_$TSQLREQUEST_$_EXECUTE$h4ds6BRYEByO_$$_fin$00000282 (first seen in mormot.db.raw.sqlite3.o)
Fatal: (10026) There were 1 errors compiling module, stoppingIt seems related to a missing "finally" block label.
Perhaps somewhat related to the previous bug.

Anyway, running mormot2tests with fpc is a good way to validate a target, especially about multi-threading abilities.

The good news is that the Windows Arm64 is moving on FPC/Lazarus. We have pressure from some of our clients to compile some services to this system.
Note that the French company I work for (TranquilIT) can also offer a bounty for any FPC core dev working on aarch64-win64 compatibility. You can ask me in a private message.
 

[Thaddy]

Did you even search? Googling for “Windows ARM Laptops” brings quite some result of various Snapdragon based laptops. (Though they have the tendency to be nearly as expensive as Apple MacBooks... 🙄)

You did not read it right: I was searching for an M4 mac mini, which is not a laptop... which I get in a few days and that means I am lucky because that product has serious delivery issues.
(At 700 euro, it is not that expensive for Apple gear, cheaper than the phones)
I am not planning to run Windows on it. Although these laptops can be quite cheap, because, well, nobody orders them..
And for AARCH64 testing I have plenty of Raspberry pi's.

I have been out of working mini's for over two years... :'(

[Wallaby]

But when mormot.core.unicode initializes, then there is a "try..finally" block with an "exit" which does not call the "finally" block.
So execution can't go any further.

Thanks for your tests! I have further simplified the problematic code to:

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

1. program test;
2.  
3. uses
4.   Classes, SysUtils;
5.  
6. begin
7.   writeln('begin');
8.   try
9.     writeln('try');
10.     exit;
11.   finally
12.     WriteLn('finally');
13.   end;
14.   WriteLn('end');
15. end.

It will print begin then try, but not finally. Apparently the exit statement isn't working correctly between try..finally.

I have updated my bug report accordingly.

[PascalDragon]

Did you even search? Googling for “Windows ARM Laptops” brings quite some result of various Snapdragon based laptops. (Though they have the tendency to be nearly as expensive as Apple MacBooks... 🙄)

You did not read it right: I was searching for an M4 mac mini, which is not a laptop... which I get in a few days and that means I am lucky because that product has serious delivery issues.

Your message did not mention that you were only searching for a Mini, only that you ordered one:

It seems also very difficult to order such a device over here. So it may be even an abandonware device.
Linux works perfectly good on AARCH64, as reportedly M Apples with some glitches.
I can only confirm or deny after my newly ordered mini is delevered.

[msintle]

Any good news here we can celebrate with the upcoming holidays?

[AlexTP]

Sarah+Sven did some work on Win-aarch64. Now stack is correctly unwinding. IDK - it's full solution or not.

[Alexx2000]

I am periodically test it. I try to compile my project (Double Commander). I am still got a several errors (with the current compiler version from git main branch).

Compiler exception:

X:\Projects\doublecmd\src\.\platform\udcversion.pas(322,31) Error: (1026) Compilation raised exception internally
Fatal: (1018) Compilation aborted
An unhandled exception occurred at $0040EDD3:
EAccessViolation: Access violation
  $0040EDD3
  $004D1C2F

Compiler internal error:

uorderedfileview.pas(458,11) Error: Internal error 200108231

If I comment a "problem" code then I got a linking errors:

Error: Undefined symbol: MTPROCS$_$TPROCTHREADPOOL_$_DOPARALLELINTERN$hle0qQKJsCMD_$$_fin$0000005A (first seen in mtprocs.o)
Error: Undefined symbol: MTPROCS$_$TPROCTHREADPOOL_$_DOPARALLELINTERN$hle0qQKJsCMD_$$_fin$0000005B (first seen in mtprocs.o)
Error: Undefined symbol: USHOWFORM$_$TWAITDATADOUBLE_$_DONE_$$_fin$00000067 (first seen in ushowform.o)
Error: Undefined symbol: UFILESYSTEMSPLITOPERATION$_$TFILESYSTEMSPLITOPERATION_$_MAINEXECUTE_$$_fin$00000030 (first seen in ufilesystemsplitoperation.o)
Error: Undefined symbol: UFILEVIEWWORKER$_$TFILELISTBUILDER_$_EXECUTE_$$_fin$00000069 (first seen in ufileviewworker.o)
Error: Undefined symbol: UFILEVIEWWORKER$_$TCALCULATESPACEWORKER_$_EXECUTE_$$_fin$0000007B (first seen in ufileviewworker.o)
Error: Undefined symbol: FMULTIRENAME$_$TFRMMULTIRENAME_$_CM_RENAME$array_of_ANSISTRING_$$_fin$00000236 (first seen in fmultirename.o)

[msintle]

Thanks for the feedback.

This certainly seems far more involved than it initially appeared to be!

Is there anything we can do at our end to help triage the latest issues encountered by Double Commander, obviously a fantastic real world project to test things with?

[PascalDragon]

Is there anything we can do at our end to help triage the latest issues encountered by Double Commander, obviously a fantastic real world project to test things with?

FPC itself is already a very good “real world project” with the next one on the list being Lazarus.