Hi everyone,

So I have been asked to do some work in improving optimisation for AARCH64, and ARM by logical extension since some parts are shared. I've had a look around the code for the Peephole Optimizer for these platforms, and while I've found some potential improvements to generated code, my first desire is to break up the monolithic optimisation functions (e.g. "PeepHoleOptPass1Cpu"), since some of them are well over 1,000 lines long and incredibly unwieldy.

The plan for this is simple... each opcode or set of similar opcodes will get its own function similar to how it is done on x86 platforms (e.g. "OptPass1STR" for STR optimisations). This will make the code much more compartmentalised and easier to maintain. There are some exceptions to this rule but I'm managing them easily enough.

Additionally, at a later stage, I want each platform to be able to share the DebugMsg method and the SPeepholeOptimization string, since currently a lot of platforms redeclare DebugMsg but without actually changing anything in the implementation.

Obviously I'll submit the changes as patches so they can be properly reviewed and tested, but does this sound like a good idea?

Gareth aka. Kit

P.S. While I haven't been asked to improve aarch64-linux specifically, if I'm understanding things correctly, there should be very few differences with the actual target platform in regards to calling conventions, for example.

I can't promise anything just yet, but I'll see what I can do.

At the moment I'm still learning to configure anything. I've had apps crash from out of memory errors and the CPU get throttled due to overheating while trying to play a YouTube video. I've got some things sorted by increasing the size of the swap file. Frankly I want my laptop back so I can get a proper e-mail client again, since I can't quite remember the server details off-hand and the Webmail client causes problems with indenting in the fpc-devel mailing list, as you undoubtedly remember.

When you say Windows 10 on ARM64, do you mean an actual build for ARM processors or an x86_64 version running inside a virtual machine? Presumably I'll have to buy a copy of the OS for that, so it will have to wait for a little bit if that's the case. But hey, I'm all for cross-platform development.

Gareth aka. Kit

On Wed 05/08/20 22:44 , "Sven Barth via fpc-devel" sent:

J. Gareth Moreton wrote

P.S. While I haven't been asked to improve aarch64-linux specifically, if I'm understanding things correctly, there should be very few differences with the actual target platform in regards to calling conventions, for example.

Correct, the most is equal between the platform. There are only subtle differences like this one for AArch64-Win64:
https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/aarch64/ncpuset.pas?r1=44949&r2=44948&pathrev=44949

If you want, you could also install a Windows 10 On ARM64 inside a KVM on your Raspberry (with the correct guest drivers you'll get near native performance) like I have done and test around on that as well ;) Maybe you'll find the necessary time earlier than me to fix the remaining problems of the compiler not being able to cycle itself there... :/

Regards,
Sven

Can't you check what you need from the webclient? After all at least your username and password should be the same no matter if you access through the web interface or IMAP...

When you say Windows 10 on ARM64, do you mean an actual build for ARM processors or an x86_64 version running inside a virtual machine? Presumably I'll have to buy a copy of the OS for that, so it will have to wait for a little bit if that's the case. But hey, I'm all for cross-platform development.

Yes, a Windows build for ARM64 processors. I've recently done the port for FPC for that. :)
Well, whether you have to buy a copy I can't answer with finality yet, but you can download the necessary files from Microsoft (no matter the architecture) and at least the "nag screen" that it isn't licensed hasn't appeared yet. So in the worst case you'll simply have to reinstall it every few months to keep using the evaluation version...

Regards,
Sven

Yes, you might have seen, that I started already with this some time ago.

You mean with regard to different aarch64 platforms?

_______________________________________________ fpc-devel maillist - https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Do you mind sharing where you found a working network driver ? I've read endless stories of instabilities with a few possible links to solutions of a few months old.
From all that I got the impression that building myself would be the "quickest" way to get them.

Thanks,
Marc

Marc Weustink via fpc-devel schrieb am
Do., 6. Aug. 2020, 09:13:

When I had setup the machine I had given up on that and simply used an Asix based USB-LAN Adapter and passed that through to the VM. Though I had recently read, that now support for the network driver should be working. You should be able to get the latest drivers from the Redhat site, I think. I'll have to check that again.

Regards,
Sven

...

Didn't try that one yet. I should have one somewhere.

Though I had recently read, that now support for the network driver should be working. You should be able to get the latest drivers from the Redhat site, I think. I'll have to check that again.

Yes, it a bit confusing. If you read the fedora site you may get the impression it supports only x86 or amd64. Today I downloaded the iso and the arm64 driver folders are present. I need to check if they work

Thanks Marc

(Accidentally sent to FLorian privately instead of to the mailing list)

Well, that's good - means I can get straight to work and save you some time, hopefully! AARCH64 doesn't have that much that needs changing in that regard, although ARM needs a lot of clean-up that I'm getting underway with. There's potential to merge some ARM/AARCH64 optimisations too, which differ only in the register names (e.g. x29 instead of r13).

I've done a little bit of refactoring of the individual optimisations to allow for small speed-ups. One of the main ones is an optimisation that converts 4 instructions onto one - in the trunk, it calls GetNextInstruction three times, along with SkipEntryExitMarker a couple of times, then checks to see if the individual operators and their operands permit the optimisation. I've changed this around a little bit so that the first instruction is evaluated, and only then is GetNextInstruction called so the next instruction can be checked, given that GetNextInstruction is a relatively expensive call and it's more likely that the criteria for the optimisation won't be met (e.g. it comes across a different instruction), so the sooner you can detect this and drop out, the faster the Peephole Optimizer will run.

Yes, apologies. I mean in regards to different aarch64 platforms. I've got the basics of the calling convention down, like with passing the first integral parameter through r/x0 and incrementing,

In a funny way, my x86-64 machine breaking is proving to be a blessing in disguise, since I'm now exploring a completely different architecture and learning its assembly language. Some potential speed-ups, like utilising NEON and other SIMD instruction sets, fall under the more general philosophy of vectorization and would be much easier to perform once all the nuances with intrinsics are resolved, because vectorization is much easier to do with nodes than with, say, trying to take a bunch of assembler instructions and attempting to vectorize those.

Gareth aka. Kit

Hi guys, can you confirm that Lazarus compiles on aarch64? When I try under aarch64-linux (with fresh SVN checkouts), it fails with the error message:

Fatal: (10022) Can't find unit db used by fcllaz

Last time this was mentioned, it was due to an oversight on my part when it comes to case block improvements. Sven hinted at problems with this with aarch64-win64, but I can't remember the details on what I did wrong or what's failing exactly (my large benchmark/test, tests/bench/bcase.pp, doesn't show any failures).

Old topic (and link to relevant bug report): https://forum.lazarus.freepascal.org/index.php? topic=43730.0

Gareth aka. Kit

Is there a particular DB test project that I can pick from, or is making a bare-bones project with "uses db;" enough?

Gareth aka. Kit

On Thu 06/08/20 22:46 , "Sven Barth" sent:

Aah, bare-bones project failed to compile with the same error, so FPC isn't configured properly. Is there something I need to do with, say, setting up the config file? I'm trying to remember how everything works with Linux.

Gareth aka. Kit

On Thu 06/08/20 22:38 , "J. Gareth Moreton" sent:

J. Gareth Moreton schrieb am Do., 6. Aug. 2020,
22:36:

Can you compile a simple program that uses the DB unit? If not, then your FPC is configured incorrectly. If you can, then... Uhm... We'll have to check further...

Regards,
Sven

Okay, got it to compile. I had to make a cfg file with absolute paths though that I Have to explicitly reference, since the trunk build puts ppca64 into /usr/local/fpc/3.3.1 and I'm not sure where it looks for fpc.cfg normally. Still, despite it being a little bit untidy, I got it to build at last and it means I can start comparing assembly dumps!

Gareth aka. Kit

On Thu 06/08/20 22:43 , "J. Gareth Moreton" sent:

J. Gareth Moreton schrieb am Fr., 7. Aug. 2020,
01:22:

Yes, the fpc.cfg is intended to have absolute paths and its located either in the global /etc/fpc.cfg or the user specific ~/.fpc.cfg (where ~ is your home directory).

Regards,
Sven

Op 07-08-2020 om 08:00 schreef Sven Barth via fpc-devel:

Yes, the fpc.cfg is intended to have absolute paths and its located either in the global /etc/fpc.cfg or the user specific ~/.fpc.cfg (where ~ is your home directory).

When you use the -va parameter, the compiler will show you where it looks for it's configuration-files.

Regards,

Joost.