Hello,

I'm very happy I can announce that for the first time, yesterday a "make cycle" worked under Linux/PPC! This means that compiler was able to compile the RTL and itself, then recompile the RTL and itself using the compiler created in the previous step and then repeat this process once more (and the two last compiler binaries are equal). This means that the code generator can be considered fairly stable (since the compiler is 120000+ lines of code and the RTL is also quite big (I don't know how big though).

There's still quite a bit to clean up though, and the speed of the generated code is far from optimal as well (if you thought gcc generated bad code for the PowerPC, forget it, there's a new kid in town :) I'm not sure what the next steps will be exactly. I'll definitely look into making parts of the optimizer platform independent (just like we did with the code generator) and a Darwin/Mac port is also in the works.

Happy weekend everyone! :)

Jonas

Jonas,

Congratulations on your success! I offer a virtual cigar in honor of the birth of the new compiler.

Regards,
Ron

I can send you a linux/ppc compiler executable (~500kB bzip2ed), creating an rtl with it is a matter of make if you've cvs checked out, just tell me an address :)

I've put a compiled snapshot up at
<http://jonagold.elis.ugent.be:8080/~jonas/fpc/> (from yesterday night's sources). Make sure that you use -Or when compiling something and "-dppc603 -Or" when cycling the compiler for optimal speed (in so far you can call the current speed optimal :)

Thanks for all your other work on fpc!

Jonas

Hi,

Hey, great news! And where to download it? :) Any unofficial snapshot or stg? ;) Since i just got a PMac8500/AV for free with some 604e/200 inside, and Debian 3.0r1 on it, so i wanted to try FPC/PPC out, but i was not able to find it on ftp.freepascal.org. Okay, i can CVS it down, and cross-compile with a Linux/x86 box, but i'm so lazy... So can i have a compiled executable/rtl at least for my further experiments? :)

Anyway, i did some bug-hunting-and-fixing in the 68k codegenerator, a few weeks ago, i just had no time (my job & such lame excuses blah) in the last weeks to finalize my changes, but i can send some patches probably this week. Anyway, Nils or someone can please look at the Keypressed function of the CRT unit in the Amiga port? It seems it's somewhat broken and Wait() forever... At least on my system. I also attempted to fix this, but i'd no success, since i haven't enough knowledge about the console.device stuff of the OS...

Also, the OS/2 snapshot compilation is somewhat broken now i think, i'm going to fix it sometime this week.

Bye,

Make sure you do not update it for now though, because currently the compiler is quite unstable (even for i386).

Jonas

Hi,

Thanks, i've got it, it's working, thanks! Very cool. :)

Bye,

Hi,

Okay i'm not going to update it for a while. Anyway, while testing some of my existing sources, i found a bug. :) I've got an Internal Error
200203271. I'm not sure if this also exist in the x86 compiler, since i can't test it right now (no x86 around). I used the parameters you recommended (-dppc603 -Or). Without -Or, the problem is not there.

Anyway i traced the problem until i was able to generate a short example which shows it. Attached. I made a workaround until it's got fixed, so it's not a big problem now. (BTW i know it's generally not a good idea to cast a single to a dword, but the code is from my .3DS loader, where some endian-issues came into the picture, and it's easier to convert the endianness of an integer than a float...:)

Bye,

Thanks, it's fixed! It also existed in the x86 compiler, but there -Or is completely broken currently, so it wouldn't have been noticed :)

where some endian-issues came into the picture, and it's easier to convert the endianness of an integer than a float...:)

Wussie! ;)

Jonas