Working on the startupcode, added option to alloc a new Stack if the freepascal needed stack is bigger than the stack supplied by AROS. (which is mostly the case, AROS delivers 40k stack, FPC wants 256k). It works, even not completely finished. It’s my first bigger project with arm assembler better let someone check with more arm assembler knowledge 😉
I tried also LCL on arm, but it did not work, the Handlemessage inside MUI/Zune makes the problem. When I checked on the Structures involved. I noticed that on AROS there are two different structures, one for BINCOMPAT mode one without this define. Until now the BINCOMPAT was only needed for m68k, but there is no special m68k-aros but only m68k-amiga and the x64-aros does not work well because AROS on x64 is near to not usable.
The define AROS_FLAVOUR_BINCOMPAT is now defined as default for arm-aros and it seems to work. Compiled the FPCMines as first try and it is working well.
FPCMines on ARM AROS
I uploaded the arm-aros basic implementation to freepascal trunk, ChainQ added syscalls for arm and some other things to make freepascal on ARM possible.
So finally the compiler works as expected, even the fp-ide works now.
FP-IDE on ARM AROS
If someone want to try it: Freepascal for arm-aros with FP-IDE
I found the reason for the crash inside SysInitFPU, it seems it uses by default the wrong FPU type. so Always -Cfvfpv2 has to be added to use the right FPU commands just to make sure I also added the -CpARMV6 to select the CPU instructions suitable for Raspberry Pi and higher. With this changes the helloworld program do not crash anymore. And also the fpc compiler works now (at least the help text).
Freepascal compiler on RPi AROS
I noticed that the official released AEROS for Raspi is named as ABIv0 and the Nightly I used is ABI_WIP (see screenshot some days before). hmm are there differences between this two, so I installed the latest AEROS on my Raspi and tried my hello world 😉
And, it works, without any problems, or crashes.
Freepascal on latest AEROS for RPI2
Maybe someone noticed the rather strange format of my screen shot, which is 800×480. Thats a special touchscreen display for RasPi. The RasPi can be connected with a foil cable to this display and the touch works as mouse move/click. In principle it can also do multiple touches and so on, but I didn’t install a driver for it.
The RasPi is installed on the back of the display and all is put into on side of the delivery (paper) box of the display. In reality the picture looks perfectly clear and sharp, its just the camera interference creating this stripes.
For Aeros this screen resolution is a little bit too low, some icons are outside the visible area, some programs do not work well (Emula for example), but for my needs its ok.
Maybe I install some smaller icons then it should be much less of a problem.
I playing around with my Raspi2 and AROS on it. I tried long time ago already but didn’t get the cross-compiling tools to work. The tools still do no work, but with some manual work, somehow the assembler and linker work, everything I need for fpc 😉
The biggest problem of course is the startup code again, here even more difficult for me, because never used ARM assembler before.
I found the ExecBase at r5, so the most important Data found already. Sadly it crashes then when it enters the PascalMain, I followed it and it seems it crashes inside the SysInitFPU. I have to admit I have no idea about the FPU in Raspi. I remember there are some different modes for FPU. For now I just disabled the the SysInitFPU() and it works. It works somehow with simple hello world application.
FreePascal Hello World application on arm-AROS
The compiler self does not work, just crash.. maybe this missing SysInitFPU has some side effects or more FPU access which crashes. I’m not sure how to continue here maybe I need to ask someone about it.
It seems the m68k amiga freepascal compiler is broken again. A Simple Hello world program compiled on an Amiga works but when a uses is in the source file the compilation stops with „Fatal: Internal error 201309171“. It happens rather often that the m68k compilation breaks, and it needs always long time to notice it, because I use cross compiling most of the time. (even in UAE native compilation is rather slow). To get faster informed about such things I added a test to my automatic compile server. An E-UAE Amiga with Workbench 3.1 is started and the last compiler is used to compile the example programs. Two of them are also executed (HelloWorld and GenerateMD5, maybe later I write some special testcases). I didn’t have time until now to find out whats the problem, but I hope Charlie can fix that soon.
Chain-Q added support for 68000 to freepascal compiler. It needs special care because it has some additional alignment need on read/write to structures. But to try it on a 68000 Amiga it should be also Workbench 1.3. the current RTL implementation needs at least 3.0. It was rather easy to create a RTL which also works on 1.3 (via defines) but also the init code (written in assembler) must be changed. I have to find out how to make defines inside prt0.as. Then it could be even added to the official repository. I wrote a little testprogram to test the RTL and make some basic alignment tests. Both works well now.
Added some more units to OS4 freepascal: MUI and networking and created a release archive which will be created as nightly (like the other platforms). You can find them on my nightly folder.
Reached the state of AmigaOS4 compiling and running the FP-IDE 😉 This was the aim of this implementation run, so its proven the library units are there and working the rest will be just work. For LCL at least MUI have to be implemented, but when I see how slow the FP-IDE is already in WinUAE I really do not want to try LCL.
I will clean up everything and commit to freepascal repository and make a release archive.
I just waited for this fix to make a Release of Freepascal 3.1.1 for m68k-amiga with the new Lazarus component Library. Of course its still early alpha state but it is somewhat usable.
Check FPC Amiga Page for the download.
Of course this archive does work on m68k AROS also. (It does not include FPGui for now)
Be warned: LCL is still is very early alpha stage, so expect crashes. It aims on fast RTG Amigas or even better RTG-UAE, but some simple programs also work on AGA/ECS Screens.
Notice: you need at least 180 MB of free RAM to compile a LCL program
