Advise on FreePascal on Amiga & other Native Amiga Pascal versions

Hi everyone,

So, the bug which people ran into on 28 Oct. should be fixed. Try the next nightly to see what happens.

Some TL;DR details: It was a register-preservation issue. In *some* cases, the compiler didn't preserve some address register (primarily A6) contents, when it was generating code for Amiga library calls, but overwrote them. This only caused issues with complex code, like the compiler itself, where register A6 was used for a register variable as well. However, the issue was not tied to A6 register itself, but it was the most common case, because A6 is always used as libbase when generating a library call of course. Actually, the actual case was a bit more complex, because the A6-non-save issue only occured, when the function doing the Amiga library call was really small, and didn't use any other non-volatile address registers. So you needed a really complex function using A6 as address register variable calling into a really simple function, doing an Amiga library call, and not preserving the A6 meanwhile.

This was a long standing issue, but since the compiler wasn't using address registers for register variables it was hiding and caused no issues. It was exposed by the large patch known as SVN r33591, committed 1 May, this year, which introduced register variables for pointer types in address registers.

This could affect any code generated by the compiler, including the one generated by the crosscompiler as well.

The issue is now fixed in SVN r34777. Additional credits fly out to Alb42, who figured out the SVN revision introducing the issue, which really helped to track the issue.

Edit: a possible workaround is for older FPC revisions is, to use -O1 level as maximum optimization level. The issue is there from -O2 and up, below the register variables optimization is disabled.

Have fun with FPC!

[MoRetro]

@ALB42
I downloaded and installed VMPlayer.
When compiling windowstest, I get the gtk2cellrenderer.pas error in virtual lazarus. The target is set to Amiga m68k.
See the compile message output.

Hint: (11030) Start of reading config file /etc/fpc.cfg
Hint: (11031) End of reading config file /etc/fpc.cfg
Free Pascal Compiler version 3.1.1 [2016/05/16] for m68k
Copyright (c) 1993-2016 by Florian Klaempfl and others
(1002) Target OS: Commodore Amiga
(3104) Compiling lcl.pas
(3104) Compiling ./gtk2/alllclintfunits.pas
(3104) Compiling ./gtk2/gtk2cellrenderer.pas
/home/test/lazarus/lcl/interfaces/./gtk2/gtk2cellrenderer.pas(30,3) Fatal: (10022) Can't find unit gtk2 used by Gtk2CellRenderer
Fatal: (1018) Compilation aborted
Error: /usr/bin/ppcross68k returned an error exitcode

@emufan
Your Mines binary doesn't run in my ClassicWB.
I got the error 'Form resource TmainWin not found......' (See picture)
http://eab.abime.net/attachment.php?...1&d=1478285487

@Chain-Q & ALB42
1) On the Amiga I instaled the https://home.alb42.de/fpcreleases/fp...m68k-amiga.lha from 20161103
I corrected in FP the empty Directories setting. It's now compiling fine Freepascal and lcl projects. No more crashing of WinUAE anymore.
So the bug Chain-Q is refering to is gone i think

Have still that suspend /Reboot requester when exiting mines.
On the other hand I got addicted to this game

2) Is the source of the Amiga units available. It would be interesting study material and it would give us a peek in the internals of the Amigados implementation

All the best

[ALB42]

Originally Posted by MoRetro

@ALB42
I downloaded and installed VMPlayer.
When compiling windowstest, I get the gtk2cellrenderer.pas error in virtual lazarus. The target is set to Amiga m68k.
See the compile message output.

Hint: (11030) Start of reading config file /etc/fpc.cfg
Hint: (11031) End of reading config file /etc/fpc.cfg
Free Pascal Compiler version 3.1.1 [2016/05/16] for m68k
Copyright (c) 1993-2016 by Florian Klaempfl and others
(1002) Target OS: Commodore Amiga
(3104) Compiling lcl.pas
(3104) Compiling ./gtk2/alllclintfunits.pas
(3104) Compiling ./gtk2/gtk2cellrenderer.pas
/home/test/lazarus/lcl/interfaces/./gtk2/gtk2cellrenderer.pas(30,3) Fatal: (10022) Can't find unit gtk2 used by Gtk2CellRenderer
Fatal: (1018) Compilation aborted
Error: /usr/bin/ppcross68k returned an error exitcode

That means you didn't read the manual carefully enough, it is not enough to switch to Amiga, you also have to choose MUI as widget set (gtk is not available for Amiga as far as I know) Thats the reason I created this templates to load
look at:
https://blog.alb42.de/virtual-lazarus/

Q: How to compile for Amiga/AROS/MorphOS?
A: You can set by hand in Project Options. But I suggest you use my prepared config file as shown in the video. Open “Menu – Project -Project Options” press “Import” (Button on the lower edge) choose the “/home/test/AllAmigaPlatforms.xml”. Now you have build settings for all four platforms.

@emufan
Your Mines binary doesn't run in my ClassicWB.
I got the error 'Form resource TmainWin not found......' (See picture)
http://eab.abime.net/attachment.php?...1&d=1478285487

The means there is the Mines.fpcres missing. This file contains the resource informations for this programs, for Amiga this is an external file, because nobody wrote a Hunk resource support for FPC until now. (all other Amiga-style system use ELF there is internal resources supported)

@Chain-Q & ALB42
1) On the Amiga I instaled the https://home.alb42.de/fpcreleases/fp...m68k-amiga.lha from 20161103
I corrected in FP the empty Directories setting. It's now compiling fine Freepascal and lcl projects. No more crashing of WinUAE anymore.
So the bug Chain-Q is refering to is gone i think

Have still that suspend /Reboot requester when exiting mines.
On the other hand I got addicted to this game

Thanks for the test, for your crash problem, I do not have an idea.
the strange looking Font, just want to ask you, do you have the XEN.font and topaz.font installed? this strange looking font appears if the font cannot be found, I do not remember which one Mines use. (could be even Arial ;-))

2) Is the source of the Amiga units available. It would be interesting study material and it would give us a peek in the internals of the Amigados implementation

Of course everything is open source.
Which source you are looking for
Freepascal source:
http://svn.freepascal.org/svn/fpc/trunk
most important directories:
http://svn.freepascal.org/svn/fpc/trunk/rtl/amicommon/
http://svn.freepascal.org/svn/fpc/trunk/rtl/amiga/
http://svn.freepascal.org/svn/fpc/tr...s/amunits/src/

Lazarus/LCL Source
https://github.com/alb42/lazarus/tree/lazarus-morphos
most important directory
https://github.com/alb42/lazarus/tre...interfaces/mui

both links can be also found on my Blog.

[MoRetro]

@ALB42
1) Thanks for reminding me the Q&A of the Virtual Lazarus Blog page.
I imported you XLM file and compiled ColorIt & Mines flawlessly.

2) I didn't know about the external resource file. Is there possible way to get this into the executable with external tools or somthing else?

3) I still get that requester error when exiting mines, even the one compiled in Virtual Lazarus. I must be something with my ClassicWB full edition.
Have to look into that when i have some spare time

4) Thanks for the links to the Amiga source files. It must somehow missed that.

All the best,

[cla]

@ALB42
Great piece of software. It reminds me of my Delphi 5 days

[MoRetro]

@ALB42
Didn't have much time for more testing, but i have question i forget asking every time:
Why are the executables so big in size?
Is there debug information that can be switched of or is it something else?

@MoRetro:
This is because FPC's binaries are currently statically linked, and the RTL (run time libs) are quite big, and all of it gets attached to the binary even if the actual code doesn't use it. We need a better linker which is able to strip out as much the unused data and code as possible. There's not just debug info in there, but for example RTTI data (Run-Time Type Information), and others, which most code doesn't need.

Recent GNU LD versions have this feature called "section garbage collection", also FPC's internal linker is able to do it on Windows for example, which result in really small binaries. Sadly, neither recent GNU LD and neither FPC's internal linker is available for classic Amiga. VLink also tries to do it, but it seems to be more conservative, and keeps a lot of data in there, which should be possible to throw away.

But it is on my to do list to improve this situation.

An additional way would be to use a completely custom "lite-RTL", where most of the advanced features are left out, so it's more suited for limited platforms like classic Amiga, especially small systems like the plain 68000. It is also what FPC uses on embedded platforms for example (remember, FPC has an 8bit backend for AVR). It's a bit similar to what you can also do with C compilers when you don't link against libc, but you use your own custom startup code.

[MoRetro]

Thanks Chain-Q,

The big size was the first thing i noticed when compiling for M68K Amiga. In my Delphi days i knew that this could be the debugger code that was added to the compiled executable.
But now I understand that the run time libraries are all linked staticly. I hope that in the near future this will change. Like you mentioned it's a necessesty on the classic Amiga 68000 systems with 1MB of ram or less.
I hope you will have some spare time in the near future to improve the Amiga FPC linker.

All the best,

[ALB42]

Originally Posted by MoRetro

@ALB42
Didn't have much time for more testing, but i have question i forget asking every time:
Why are the executables so big in size?
Is there debug information that can be switched of or is it something else?

besides what ChainQ wrote. I think the exe created with the Virtual Lazarus still has the debug informations inside you can remove them with the "strip" program. This must be done directly on the Amiga (the cross binutils ma68k-amiga-strip does not work, I have no idea why). But you can download a binutils atrchive from Aminet there should be the strip command included
then easily "strip --strip-all myprogram"

About the sizes.
A Simple HelloWorld program should be around 100-200k striped
program helloworld
begin
writeln('Hello World');
end.

A Hello world in Lazarus using LCL Window and so on will be 6 Mb even after optimization of the linking process as ChainQ described it will be not lower than 1-2 Mb because this LCL Wrapper is huge.

If you want to omit it and reduce the size to Amiga typical RAM levels you have to program directly Amiga API, like the examples WindowTest/SimpleGraphics (in example directory) or for MUI the examples
at github https://github.com/alb42/fpc-tests/tree/master/Zune

[MoRetro]

Originally Posted by ALB42

besides what ChainQ wrote. I think the exe created with the Virtual Lazarus still has the debug informations inside you can remove them with the "strip" program. This must be done directly on the Amiga (the cross binutils ma68k-amiga-strip does not work, I have no idea why). But you can download a binutils atrchive from Aminet there should be the strip command included
then easily "strip --strip-all myprogram"

Thanks for the info ALB42. I've downloaded the binutils-m1-bin-m68k.lha from Aminet. (http://aminet.net/package/dev/gg/binutils-m1-bin-m68k)
I've copied the strip binary to C: en did my test with the Mines demo
program. For the test i copied Mines to RAM: to save writing to my CF Card.
Then I used the following call c:strip Ram:Mines
The size went from 8,591,376 to 4,353,848 butes, almost the half.
After stripping the Mines program worked in the same way as before. (Still that mysterious suspend error when closing it!)
THen i used the switch you proposed "strip --strip-all Mines" The size went down 3,924,152 bytes. That's quite a lot

Originally Posted by ALB42

About the sizes.
A Simple HelloWorld program should be around 100-200k striped
program helloworld
begin
writeln('Hello World');
end.

A Hello world in Lazarus using LCL Window and so on will be 6 Mb even after optimization of the linking process as ChainQ described it will be not lower than 1-2 Mb because this LCL Wrapper is huge.

Nice to know that and i've noticed the difference when compiling without Lazarus components.

Originally Posted by ALB42

If you want to omit it and reduce the size to Amiga typical RAM levels you have to program directly Amiga API, like the examples WindowTest/SimpleGraphics (in example directory) or for MUI the examples
at github https://github.com/alb42/fpc-tests/tree/master/Zune

For a little program that's maybe a solution. But it is not desirable if someone would make a complex one with a lot of windows or interfaces in it.
I hope that one of these days you can attack this problem.

All the best,

[emufan]

I found the source of an animation player (Big)AnimFX v157 - came with AnimFX v2.3.
when compiling i get the following:
system: pp(9,1) Error: Compilation raised exception internally
system: pp(0) Fatal: No Memory left

i have no idea how to cope with that error.
can anyone try to compile the attached source?

#1) soundplay.mod added - included by mainfile.
error may be connected to the includes. any idea?

#2) i think this is a nogo, tested source with HSPascal, next to other obstacles,
i cannot find the aga.lib elsewhere.
must be made by the coders of (Big)AnimFX they forgot to include.

[ALB42]

Originally Posted by emufan

I found the source of an animation player (Big)AnimFX v157 - came with AnimFX v2.3.
when compiling i get the following:
system: pp(9,1) Error: Compilation raised exception internally
system: pp(0) Fatal: No Memory left

I guess that means your computer does not have enough RAM to compile it.
Compilation needs a lot of RAM, especially the linking stage at end.

Originally Posted by emufan

i have no idea how to cope with that error.
can anyone try to compile the attached source?

#1) soundplay.mod added - included by mainfile.
error may be connected to the includes. any idea?

#2) i think this is a nogo, tested source with HSPascal, next to other obstacles,
i cannot find the aga.lib elsewhere.
must be made by the coders of (Big)AnimFX they forgot to include.

I looked into the source.
I guess thats a meta Pascal compiler or so, which compiles the source to a C source and then compile it with a normal C compiler. the Syntax is rather different to the todays standard Pascal. But I was able to fix it, the aga.lib and also other includes are not needed because they are included in the standard libs supplied with FPC Amiga.

I packed the source with a compiled binary to a Package to download.
But just as personal notice, the Source is very bad, (many things forced by the used compiler I guess) pointer - longint mixed very inconsistent use, big sources of possible errors. So it could be used to learn to NOT do it
But learn how to read and display anims.

I tested with this anim: http://aminet.net/package/pix/anim/diceanim and it works

[emufan]

Originally Posted by ALB42

I guess that means your computer does not have enough RAM to compile it.
Compilation needs a lot of RAM, especially the linking stage at end.

using winuae here, 8mb chip + 512 mb fast z3 ram - not enough?

But just as personal notice, the Source is very bad, (many things forced by the used compiler I guess) pointer - longint mixed very inconsistent use, big sources of possible errors. So it could be used to learn to NOT do it
But learn how to read and display anims.

thanks for that info too. this is some rare player for some iff-sound-anim format. some skilled ppl may resuse your fixed source to make it even better

I packed the source with a compiled binary to a Package to download.

thanks alot, i will test it in a minute

#1) tested with my iff-sound anims, they introduced some new "features" with that version,
so my old anims do not work anymore. it plays some other standard anims just fine.
only those with sound now need different sound format.
thats a pity but no big issue. I'll take a look into the source, maybe i can switch some things
thanks again for your help

[ALB42]

About this year ... 2016

https://blog.alb42.de/2016/12/31/about-this-year-2016/

[ALB42]

Awesome news about the executable size:

https://blog.alb42.de/2017/01/07/small-is-beautiful/

[emufan]

nice achievement
I was about to use fpc-release.m68k-amiga.lha (07-Jan-2017),
while extracting - and this happened on earlier released too, IIRC - there are two file conflicts,
maybe too long filename. see image attached.

[MoRetro]

Originally Posted by ALB42

Awesome news about the executable size:

https://blog.alb42.de/2017/01/07/small-is-beautiful/

Nice work ALB42,
I'll test it as soon as possible.
Saw on your webpage that Amiga LCL will get an update. Again that's fantastic

All the best,

[phx]

Originally Posted by emufan

maybe too long filename. see image attached.

Yes, I would guess the same. Which file system do you use? The standard FFS? Then file names are limited to 30 characters.

[emufan]

Originally Posted by phx

Yes, I would guess the same. Which file system do you use? The standard FFS? Then file names are limited to 30 characters.

i was extracting the archive to the default ram disk.

[phx]

That might explain it. I guess the Ram-Disk is always FFS.