Hi,

Here are a few things about the m68k version i'd like to discuss.

First, how well the FPU codegenerator is tested in the m68k version? I ask, because i've got a pretty big piece of code here, which makes heavy use of float math. (A 3D engine namely.) I wrote it using the i386 compiler, a few years ago. So now i tried to port it to m68k. After working around a few internalerror(10)'s :) i successfully compiled the code, and it worked. But then i tried to switch off the FPU emulation to generate direct FPU code, since that should be really faster on my '060 baby. But i didn't got anything but nasty crashes, and some invalid instruction exceptions... So, are there any known defects of the FPU code generator, or should i try to give a small example program which shows the error?

Second, is there a chance to get '020 style addressing supported in inline assembly? So to use (1234,a0) instead of 1234(a0). Well, it's not that important, but can come handy in some cases...

Third, is it possible to have parameter-passing in registers, in the procedure definition in a foreseeable future? Needless to say, it can come handy when someone writing header units for AmigaOS libs... :)

And for last, are there any jobs open for volunteers in the m68k/amigaos port? I'd really like to make myself useful. :)

Bye,

What version do you use?
the Amiga napshot that Carl created?
Did you try the linux or the netbsd port?
The main difference, is that these two ports have
do not use FPU emulation by default.
Testing your code under these target would allow
to check if the problems are generic fpu code generation problem or problems specific to the ports that use emulation by default.

Second, is there a chance to get '020 style addressing supported in inline assembly? So to use (1234,a0) instead of 1234(a0). Well, it's not that important, but can come handy in some cases...

That should problably not be very difficult to implement.... just take a look into m68k/raasm.pas

procedure BuildReference
and extend it to support comma after a constant expression....

Third, is it possible to have parameter-passing in registers, in the procedure definition in a foreseeable future? Needless to say, it can come handy when someone writing header units for AmigaOS libs... :)

This will only be started in the 1.1 compiler but is not yet in the high priority list....

And for last, are there any jobs open for volunteers in the m68k/amigaos port? I'd really like to make myself useful. :)

This is more a question for Carl....

Hi,

I've compiled it myself from CVS sources. (Using a Linux/x86 box.) But i tried Carl's snapshot too, and it didn't made any differences.

Did you try the linux or the netbsd port?

No, only the Amiga port. I've no Linux/68k or NetBSD/68k installed here.

And what if i build an Amiga port which uses FPU by default? Is it possible somehow? It would be much more easy for me than a BSD or Linux install. (And after then, port my code to BSD and Linux...)

Ahem, well... Maybe i'll take a look. :]

Bye,

I can vaguely remember something about the 040 not having a few FPU instructions the 030 has, maybe that also goes for 060's.

The NetBSD kernel emulates these afaik. (for 040)

Hi,

Marco van de Voort wrote

I can vaguely remember something about the 040 not having a few FPU instructions the 030 has, maybe that also goes for 060's.

The 030 doesn't have any internal FPU. You most probably think about the '881/882 FPU. :) But yes, the 040/060 FPU only supports portions of the 6888x FPU instruction set. In fact, most of the FPU instructions are emulated on a 040. But of course, the most important instructions (FADD/FSUB/FMUL/FMOVE/FDIV/FSQRT/etc) are supported by the hardware. Only the less often used instructions was left out and emulated, like FCOS-FSIN&co, FLOG*, and such.

The NetBSD kernel emulates these afaik. (for 040)

Motorola always gave a software emulation package for 040 and for 060 too, which provides 100% 68020 and 68882 compatibility. AmigaOS also emulates the unimplemented instructions, using these so-called cpu-libraries. The 68060 has a few, but rarely used integer instructions unimplemented, to simplify the CPU's pipeline design, but the 68060.library emulates these as well.

There is another possibility to avoid emulation under AmigaOS. Most Amiga compilers use the so-called mathieee* libraries to take care on their math. These libraries are provided by default, and contains emulation stuff for float math. (Both for double and for single precision). But these libs are replaceable by the user, if wanted. So it's possible avoid unnecessary emulation by replacing the libs with ones optimized for the used CPU.

Bye,

The jobs/problems you mentioned above :) ?

I give up, anyone can provide that comparch.tex in _ANY_ other format but TeX? HTML or PDF would be great.

Thanks,
Yakov

Yakov Sudeikin wrote

I give up, anyone can provide that comparch.tex in _ANY_ other format but TeX? HTML or PDF would be great.

Did you try
pdflatex comparch
?

If it doesn't work for you, tell me an email address where I can send it too (the pdf is ~0.5 MB).

Under FreeBSD one has to increase the poolsize to compile, maybe that is what is bothering him.

hi!

Isn't LaTex2HTML a tools that translates TeX to HTML? Look at http://www.latex2html.org/.

hth,

anton.

----------

"Adas Methode war, wie sich zeigen wird, Tagträume in offenbar korrekte Berechnungen einzuweben."

Doris Langley Moore: Ada, Countess of Lovelace (London 1977).

----------

Anton Tichawa
Volkertstrasse 19 / 20
A-1020 Wien
mobil: +43 664 52 07 907
email:

----------

Greetings,
Apart from testing the basic instructions FADD/FMOVE, etc on the Amiga version i did not test much, i know that Pierre added instructions which might not be supported by the 68060 hardware, maybe there lies the problem? But you say that Amiga emulates all these

correctly?

Can you please send me the code which gives problems... We'll try to fix it asap!

Second, is there a chance to get '020 style addressing supported in inline assembly? So to use (1234,a0) instead of 1234(a0). Well, it's not that important, but can come handy in some cases...

Heu, maybe in 1.1? (If i ever do 680x0 on 1.1...)

Third, is it possible to have parameter-passing in registers, in the procedure definition in a foreseeable future? Needless to say, it can come handy when someone writing header units for AmigaOS libs... :)

This will be supported in 1.1 in a generic way i think so if 680x0 is supported, it should not be that difficult to implement...

Since you are the main person worknig on the Amiga currently, did you have serious problems with the compiler and the generated code? Please report any serious problem, and we'll try to fix it!

And for last, are there any jobs open for volunteers in the m68k/amigaos port? I'd really like to make myself useful

Nils Sjoholm has helped a lot since he has ported all Amiga includes to pascal! Yes, I really need help in debugging the bugger... I think maybe the Amiga RTL is shaky, but i'm not sure, as i only test minimally, and only on WinUAE, my Amiga 3000 being somewhere in a box in another country! (Which i cannot reach before the end of this year!)..

Carl Eric Codere

I give up, anyone can provide that comparch.tex in _ANY_ other format but TeX? HTML or PDF would be great.

The PDF version is available on the freepascal ftp site in the docs directory. I also have the original (ooh.. what horrible words i will say!) in Microsoft Word format!

microsoft is ok. but possibly you'll need a license to read your own documents.

anton tichawa.

----------

"Adas Methode war, wie sich zeigen wird, Tagträume in offenbar korrekte Berechnungen einzuweben."

Doris Langley Moore: Ada, Countess of Lovelace (London 1977).

----------

Anton Tichawa
Volkertstrasse 19 / 20
A-1020 Wien
mobil: +43 664 52 07 907
email:

----------

Hi,

Yes it emulates all of them of course. There is 68040.library for '040 CPU's and 68060.library for '060 CPU's. These libraries contains support code for these CPU's. These libraries loaded by SetPatch at boot-time. After the libs got loaded, they install their exception handler, and traces all invalid instruciton exceptions, and emulates unsupported but valid instructions if found.

I used lot of unsupported FPU instruction in my previous assembly codings, for eg. for generating sin/cos tables and such. And they never made any problems, the exception handler just took care of them.

Can you please send me the code which gives problems... We'll try to fix it asap!

Okay, i'll hunt down what's causing my troubles, and send some code...

> Second, is there a chance to get '020 style addressing supported in > inline assembly? So to use (1234,a0) instead of 1234(a0). Well, it's > not that important, but can come handy in some cases... Heu, maybe in 1.1? (If i ever do 680x0 on 1.1...)

Please do. The compiler performs very well on my 68060, so this baby has enough power to compile big projects using FPC. In fact, FPC even outperforms most 'traditional' Amiga C compilers on this machine. And there is no other good (and up to date) Pascal compilers for Amiga. And there are lots of Amiga ppl. i know, who just don't want to switch to any of the new PPC machines, but stay with their good old Lady, as long as possible...

Since you are the main person worknig on the Amiga currently, did you have serious problems with the compiler and the generated code? Please report any serious problem, and we'll try to fix it!

No, the compiler basically works very well, i really only miss some features (like lineinfo unit), and ofcourse this FPU stuff goes onto my nerves. But the compiler and the generated code (again not counting the FPU stuff) is very stable, and i really do not had any serious problems with it.

Anyway, i'm not the only one who uses the Amiga version, i know at least two other ppl. here in Hungary, who follow closely the happenings around the Amiga port. Well, not much, but don't forget there is still no official 1.0.x for Amiga, and the 0.99.5d is not too useful, since it's unstable, and also has many features missing... And this is only for Hungary (with ~300 active Amiga users altogether...).

Yes, Nils did a pretty good job on this. On my side... well, i plan to port as much of my previous and current pC works to Amiga as possible, and i need a good FPC port for that. So, we'll see what can i do... :)

Anyway, my current and largest problem is that i can't cycle a compiler on my Amiga, so i have to use a Linux/x86 box to cross-compile a new compiler every time. I've installed all necessary tools (i think), but i just get the following message:

10.Work:Develop/FPC/fixes/fpc/compiler> make compiler Makefile:17: *** You need the GNU utils package to use this Makefile. Stop.

Ideas? :) I'll take a look again on my GNU utils stuff, but i think everything is available, and on the path...

Bye,

From: "Balogh, Karoly (Charlie/iNQ)"
To:

Subject: Re: [fpc-devel]some m68k releated stuff
Date: Mon, 31 Mar 2003 14:29:29 +0200

Hi,

.
.

starting "make fpc_info" might help you (at least it's worth trying).

Tomas

Hi,

It didn't makes any difference. The error message is still the same.

Bye,

Did you install the make<target>.zip file? Be sure that the extracted filenames are all lowercase.

The file you need to check first is pwd.exe, that one is used for the check that fails for you.

Hi,

Yes i did. The filenames are all lowercase. But anyway, the Amiga filesystem doesn't case sensitive...

The file you need to check first is pwd.exe, that one is used for the check that fails for you.

Well, i had pwd on my path, but not pwd.exe. Since there is no .exe suffix on Amiga by default. (The executables doesn't have any standard extension but an executable flag like on Un*x.) I copied pwd to be available as pwd.exe too, and also the same goes for most of the other GNU utils, but it didn't made any difference...

:/

Bye,

Also if the filesystem isn't case sensitive, make itself can be case sensetive. For example the mingw32 make.exe.

Maybe the file extension that is added for executables is not correct or the environment variable PATH is not available.

The only thing you can do is debug the Makefile using 'make -p' to print the internal database and check in Makefile what the check was and what the used values are by looking at the internal database of make.

Peter

Hi,

Peter Vreman wrote

Maybe the file extension that is added for executables is not correct or the environment variable PATH is not available.

Hmmm... Yes, this was the problem. It seems that the Amiga version of GNU tools doesn't use the internal AmigaOS path, but requires an enviroment variable named PATH... :/

The only thing you can do is debug the Makefile using 'make -p' to print the internal database and check in Makefile what the check was and what the used values are by looking at the internal database of make.

Okay. I did as you said, and found some interresting results. If there is a 'pwd.exe' in any of the directories under PATH, i get the following:

13.Work:Develop/FPC/fixes/fpc/compiler> make compiler make: ppc386.exe: Command not found
make: ppc386.exe: Command not found
make: ppc386.exe: Command not found
make: ppc386.exe: Command not found
make: ppc386.exe: Command not found
Makefile:154: *** The Makefile doesn't support target , please run fpcmake first. Stop.

Then i tried:

13.Work:Develop/FPC/fixes/fpc/compiler> make compiler OS_TARGET=amiga CPU_TARGET=m68k make: ppc386.exe: Command not found
make: ppc386.exe: Command not found
make: ppc386.exe: Command not found
make: ppc386.exe: Command not found
make: ppc386.exe: Command not found
ppc386.exe -dm68k -dGDB -dBROWSERLOG -dNOOPT -Ct -Tamiga -Fum68k -Futargets -Fu../rtl/amiga -Fim68k -FE. pp.pas
make: ppc386.exe: Command not found
make: *** [ppc68k] Error 127

After these i removed pwd.exe from the PATH ('pwd' still there) since using .exe suffix with GNU tools on AmigaOS can be declared as unsupported. So i got the followings then:

13.Work:Develop/FPC/fixes/fpc/compiler> make compiler OS_TARGET=amiga CPU_TARGET=m68k make: -iVSPTPSOTO: Command not found
make: -iSP: Command not found
make: -iTP: Command not found
make: -iSO: Command not found
make: -iTO: Command not found
dm68k -dGDB -dBROWSERLOG -dNOOPT -Ct -Tamiga -Fum68k -Futargets -Fu../rtl/amiga -Fim68k -FE. pp.pas make: dm68k: Command not found
make: [ppc68k] Error 127 (ignored)
f pp ppc68k
make: f: Command not found
make: [ppc68k] Error 127 (ignored)

What should i try as next step? I'll modify some makefiles or utils (fpcmake?) if needed, to finally support Amiga target just like all the others, but some hints are welcomed, where to start, what to check first, etc. :) TIA.

Bye,

The Makefile requires the PATH, see fpc/utils/fpcm/fpcmake.ini. That contains Makefile parts with comments.

After these i removed pwd.exe from the PATH ('pwd' still there) since using .exe suffix with GNU tools on AmigaOS can be declared as unsupported. So i got the followings then:

This is correct.

The FPC variable is not set in the Makefile. Try using "make -p" to dump the database and check for FPCPROG. It depends if executable fpc is available.

You can also try "make FPC=ppc68k" to force the use of ppc68k

the

used values are by looking at the internal database of make.

Forget about sing make under AmigaOS, the problem with the ported version of GNU tools as they mimic UNIX too much, so paths, and everything else must be run in ksh, but by doing that, FPC no longer recgnizes Amiga paths and filenames...

So unless someone ports a good native version of GNU make to amiga, building the compiler must be done manually :(

For the amiga script for building the amiga compiler, take a look at /install/amiga in the fixes branch.

Good luck (as it is complex!)
Carl

From: "Balogh, Karoly (Charlie/iNQ)"
To:
Subject: [fpc-devel]Re: some m68k releated stuff Send reply to:

Date sent: Thu, 03 Apr 2003 03:52:10 +0200

Hi,

13.Work:Develop/FPC/fixes/fpc/compiler> make compiler OS_TARGET=amiga CPU_TARGET=m68k make: -iVSPTPSOTO: Command not found make: -iSP: Command not found make: -iTP: Command not found make: -iSO: Command

do you have "fpc" available on PATH? If so, what does "fpc -i" display?

Tomas

Hi,

9.Ram Disk:> fpc -i
Error: ppc68k.exe can't be executed

After i renamed ppc68k to ppc68k.exe, i got the following:

9.Ram Disk:> fpc. -i
Free Pascal Compiler version 1.0.7

Compiler Date : 2003/03/26
Compiler Target: m68k

...and the usual copyright mess... :)

So this seems to be wrong again, since there shouldn't be any .exe suffix on Amiga normally.

Bye,

Hi,

Carl Eric Codere wrote

Forget about sing make under AmigaOS, the problem with the ported version of GNU tools as they mimic UNIX too much, so paths, and everything else must be run in ksh, but by doing that, FPC no longer recgnizes Amiga paths and filenames...

Hehe, well, never say never! :)

9.Work:Develop/FPC/fixes/fpc/compiler> make compiler OS_TARGET=amiga CPU_TARGET=m68k FPC=ppc68k
ppc68k -dm68k -dGDB -dBROWSERLOG -dNOOPT -Ct -Tamiga -Fum68k -Futargets -Fu../rtl/amiga -Fim68
pp.pas
Free Pascal Compiler version 1.0.7 [2003/01/18] for m68k Copyright (c) 1993-2002 by Florian Klaempfl
Target OS: Commodore Amiga
Compiling pp.pas
....
Assembling pp
Linking ./pp
...
9.Work:Develop/FPC/fixes/fpc/compiler> pp
Free Pascal Compiler version 1.0.7 [2003/04/05] for m68k Copyright (c) 1993-2003 by Florian Klaempfl

:)

Also the rtl compiles OK...

So unless someone ports a good native version of GNU make to amiga, building the compiler must be done manually :( For the amiga script for building the amiga compiler, take a look at /install/amiga in the fixes branch.

Thank you, i'll take a look.

Good luck (as it is complex!)

Well, it is still not as good as cycling a compiler, but i was able to build a compiler using make on Amiga. So IMO it shouldn't be so hard to fine-tune this whole stuff, and finally get a working make process...

Bye,

Hi,

Peter Vreman wrote

You can also try "make FPC=ppc68k" to force the use of ppc68k

Yes, this solved the problem, i was finally able to build a compiler... Still not to cycle though, but i'm satisfied with the current result. It is possible to modify the makefile to automagically recognize OS_TARGET, CPU_TARGET and FPC parameters on Amiga somehow?

Something suggests me i should take a look on fpc/utils/fpcm/fpcmake.ini, you said... :)

Bye,

From: "Balogh, Karoly (Charlie/iNQ)"
To:
Subject: [fpc-devel]Re: some m68k releated stuff Send reply to:

Date sent: Sat, 05 Apr 2003 14:34:29 +0200

Hi,

very easy... ;-) compiler/utils/fpc.pp expects the .exe extension to be always used unless the UNIX conditional is defined. I don't know, whether it would make sense to add this define for Amiga (I suspect it wouldn't be the right solution here), or whether we should add Amiga explicitely there (or maybe don't use .exe for anything but I386???). Once this gets fixed, you shouldn't have to set FPC=ppc68k explicitely, I guess.

Tomas

Hi,

Whooops, i had wrong version of fpc on path. It was the one from the snapshot [2003/01/18] but, Carl already fixed this at 2003/01/27... :)

Now it's working. I'm able to build a compiler just using make compiler OS_TARGET=amiga.
But i can't cylce a compiler since it stops when make wants to spawn a new make process, and looks for /bin/sh, which is not available... So Carl was right, there's a need to port a better make for AmigaOS. Fortunately i found a source pack of GNU Make 3.80 on my HDD, so i began to actualize an old (from 1996) 100% native port for Amiga. After a few hours i was able to compile GNU Make with SAS/C, and it's working with a lot of makefiles. The only problem is that enabling native Amiga path support disabled the support for Unix-style relative paths like '../m68k/inc' and such the FPC makefiles use.

So the next step is probably to patch make to convert Unix paths to Amiga paths internally, but i had no time to do the patch at weekend.

(Yikes, i really hate C, and GNU make has a really messy code, with lot of ugly platform-dependent #ifdefs...)

Bye,

Wow!!! Please, if you can make it work, I'd be so happy!! I played around with amiga scripts for about 7 hours this weekend to be able to generate a release, but i still need to do some manual 'hacking' to create a release!!

You have much courage in tackling the make C source code!! I wish you good luck!