Hello together!

With revision 26849 which I just committed a few minutes ago an imporant milestone was reached for reviving the M68k port: the cross compiled compiler is now not only able to compile a program, but this program is also able to run correctly!

See here:

=== shell begin ===

$ cat ./fpctests/helloworld.pas
program helloworld;
begin
   Writeln('Hello World');
end.
$ ../run-qemu-m68k ./compiler/ppc68k -iSPSO
m68k linux
$ ../run-qemu-m68k compiler/ppc68k -n -Furtl/units/m68k-linux -viwn
-Cpisac -O- -FEtestoutput -XPm68k-elf- -sh ./fpctests/helloworld.pas
$ ./testoutput/ppas.sh
Assembling helloworld
Linking testoutput/helloworld
m68k-elf-ld: warning: testoutput/link.res contains output sections; did
you forget -T?
$ ../run-qemu-m68k ./testoutput/helloworld
Hello World

=== shell end ===

Notes:
- run-qemu-m68k is a shell script that calls qemu-m68k which allows me to run m68k-linux binaries on my x86_64 linux system (works on any other Linux architecture supported by QEMU as well) [this is QEMU's user space emulation]
- I need to use -sh (thus generating the ppas.sh script), because QEMU does not seem to allow me to exec a non m68k program

That the compiler is now working shows already that the work Charlie and me have done on the code generator has finally paid of and that it's nearing production quality again. There are still around 210 test suite errors for the full suite, but quite some are related to the one main problem that still exists: linking to libraries. Once Charlie and/or me have managed to set up the necessary C libraries we can fix this problem to have the m68k port reach the state of the old times again. :D

After that the main work on m68k will switch to optimizations and maybe/likely revival of other m68k RTLs (Amiga, Atari, Mac OS, NetBSD) :D Of course an embedded target will be a nice to have as well ;)

Regards,
Sven

Congratulations and thanks :-) Only 68K I've got here is an old Mac, and I'm told it needs a bucketload of caps before it will be any use.

Sven Barth wrote

- I need to use -sh (thus generating the ppas.sh script), because QEMU does not seem to allow me to exec a non m68k program

And with revision 26851 "-sh" isn't needed anymore as the compiler can now correctly find the "as" and "ld" binaries. :D (the problem was that the location of the environment variables was calculated incorrectly which resulted in envp being Nil => no PATH variable)

=== output begin ===

$ ../run-qemu-m68k ./compiler/ppc68k -n -Furtl/units/m68k-linux -FEtestoutput -viwn -XPm68k-elf- -O- -Cpisac ./fpctests/helloworld.pas Target OS: Linux for m68k
Compiling ./fpctests/helloworld.pas
Assembling helloworld
Linking testoutput/helloworld
/usr/bin/m68k-elf-ld: warning: testoutput/link.res contains output sections; did you forget -T?
5 lines compiled, 0.8 sec
$ ../run-qemu-m68k ./testoutput/helloworld
Hello World

=== output end ===

Regards,
Sven

GREAT !!!!

I do have an real ( :-) ) 68 K (in fact "Fido" based) Board sitting on my desk which I work with every day.

I do development with same using GNU C via Eclipse and a JTAG adapter.

The embedded system does not run Linux but both a very propriety non-preemptive (pure system mode) OS by Innovasic and a very propriety preemptive (user mode) OS by myself.

Any chance to do some tests with your milestone on this system ?

Thanks
-Michael

We don't have an embedded target yet and for the two OS you mentioned the RTL would need to be ported (or at least mostly stubbed). As you use GNU C then the calling convention used should hopefully be the same as for Linux though you might want to check whether it's using A6 or A5 as stack frame register.

If you want to play with it nevertheless, the necessary parameters should be -O- -Cp68000 (or maybe also 68020) and you'll need the binutils for that target. You could for example compile a simple unit that just contains functions/procedures (without managed types, no RTL usage!) for m68k-linux (with the above mentioned parameters) and then link the resulting .o file from a C program for the fido that calls the functions (keep name mangling in mind or use "[public, alias: 'SomeName']" on the Pascal procedures/functions).

I know that sounds rather complex and restricted at the same time, but for now that would be the only possibility if there is no port yet.

Regards,
Sven

Sven Barth wrote

We don't have an embedded target yet and for the two OS you mentioned the RTL would need to be ported (or at least mostly stubbed).

Of course.

At first, for a proof of concept, I would just try to use some simple pascal functions and call them by a gcc function and have the pascal project call some gcc functions.

For useful work in my project, I would need strings and with that of course heap.

I suppose I can (and need to) create the appropriate RTL functions for providing a heap to the user code by forwarding the call to malloc/free and friends in the C RTL (which I of course have).

As you use GNU C then the calling convention used should hopefully be the same as for Linux though you might want to check whether it's using A6 or A5 as stack frame register.

The calling convention with C is (as well for gcc, as for the old MRI compiler I used before, as well for 68K-"CPU32" as for FIDO:

A7 = Stack
A6 = call frame (handle by LINK / UNLNK instructions D0, D1, A0, A1 can be modified by the called function D2, D3, D4, D5, D6, D7, A2, A3, A4, A5 need to be restored by the called function
all parameters are pushed to stack as 32 Bit values (some compilers might allow for word parameters to be pushed as 16 Bit value, but I don't use this), normal C-Call pushing order
The stack is cleared up by the caller after the call

That is exactly what I am up to right now. (AFAIK, "CPU32" and FIDO in fact provide most ASM features of 68020 - but no MMU - , so maybe "68020" might be appropriate. But I can't provide the "binutil" API to the pascal project, but just some dedicated RTL features I would be able to do myself)

and then link the resulting .o file from a C program for the fido that calls the functions (keep name mangling in mind or use "[public, alias: 'SomeName']" on the Pascal procedures/functions).

Yep.

I know that sounds rather complex and restricted at the same time, but for now that would be the only possibility if there is no port yet.

I did not expect anything simpler :-)

In the end I supposedly will want to create a mechanism of "loading" a Pascal "program" using the running C project as a kind of "boot loader", e.g. doing the necessary recalculation of non-relative addresses.

For this the Pascal project would need to be linked to something similar to a Linux program (elf or whatever file) and my "loader" would need to handle same.

Thanks again,
-Michael

BTW:

The PCB I use has as well the said FIDO chip as a PIC32. We did not yet decide which of the chips would be our favorite to run the ported Pascal code.

The PIC32 has a MIPS32 M4K architecture and can do MIPS16e mode if desired.

I remember that a MIPS port is in the works, as well.

Do you know anything about it's state ?

Thanks,
-Michael

It's MIPS32/64, supports big and little endian and runs already good enough to be used for mipsel-android. (I have not worked on it myself though)

Regards,
Sven

Yes.

For useful work in my project, I would need strings and with that of course heap.

Here you'll basically need the initalization from the system unit. For Linux for example the entry point is located in
$fpc/rtl/linux/m68k/prt0.as which calls PASCALMAIN (that's the main code of the program file). At first that initializes all units (including system) by calling fpc_initializeunits. In the system unit initialization the heap is then initialized and that should normally be sufficient for using strings (though the atomic functions will need to be implemented as well if you want to use multi threading ;) )

I suppose I can (and need to) create the appropriate RTL functions for providing a heap to the user code by forwarding the call to malloc/free and friends in the C RTL (which I of course have).

You could either write a custom heap manager (similar to cmem which simply calls malloc/free from the C library), but you'd still need to keep the initial heap usage for initialization of the system unit in mind (except you replace the default heap manager functions inside the system unit). Otherwise you'd need to implement the SysOSAlloc and SysOSFree functions usually located in $fpc/rtl/OS/sysheap.inc (for Linux the location is $fpc/rtl/unix/sysheap.inc) to get the heap to use your C library functions.

That's good. That's the same ABI that Linux uses.

FPC itself does not need to care for MMU or no-MMU. ;) What do you mean with the "binutil API"?

In the end I supposedly will want to create a mechanism of "loading" a Pascal "program" using the running C project as a kind of "boot loader", e.g. doing the necessary recalculation of non-relative addresses.

Yes, currently FPC can not generate m68k PIC code, so something like that will be necessary.

Regards,
Sven

Thanks for all these useful hints.

As the heap needs to be shared between the C functions and the Pascal functions I suppose I should just implement the SysOSAlloc and SysOSFree functions i a new "embedded" RTL and call the appropriate C RTL functions there. And yes, I do multithreading. The C RTL heap handling functions already are thread save, so no problem here. I suppose the string handling needs additional thread awareness, but as - at least at this point in planning - the use of Pascal is restricted to a single thread, this should not be a problem.

That's good. That's the same ABI that Linux uses.

This is what I expected. I forgot to mention that the result of a function is returned in D0. But I a positive that this is the same in Linux as well.

> FPC itself does not need to care for MMU or no-MMU. ;)

Great. So the FIDO will be compatible with 68020 (e.g. can do 32 Bit offset with BCC)

> What do you mean with the "binutil API"?

Am I wrong to assume that "binutil" also provides some library functions to include in the to-be-compiled project (e.g. "prototypes" for calling stuff in glibc) ?

In fact I do not really understand why I need to have binutils just for creating a .o file that is to be linked into a C project.

Yes, currently FPC can not generate m68k PIC code, so something like that will be necessary.

I did assume this ;-) .

-Michael

Sounds good.

So we will take a look and maybe try to implement a draft for an "embedded" RTL compatible with the C RTL provided by microchip.

Thanks a lot,

-Michael

Broadly working when I last looked: both mips and mipsel were OK on Linux to the extent of being able to do a full native build, neither were up to compiling Lazarus (but things might have improved since).

Mark Morgan Lloyd wrote

Broadly working when I last looked: both mips and mipsel were OK on Linux to the extent of being able to do a full native build, neither were up to compiling Lazarus (but things might have improved since).

In fact I am not sure about what the M4K variant exactly means.

I read about other variants needing more dummy instructions (delay slots) after conditional branches (M4K needs one, AFAIK) This of course is relevant for the compiler.

I took a look at

http://wiki.freepascal.org/Native_MIPS_Systems

Here the PIC32 as a "deeply embedded target" is not mentioned. IMHO this is a very relevant use for the FPC MIPS compiler and should be added at least as a "todo".

(I could provide some PIC32 / Microchip IDE knowledge if appropriate.)

-Michael

As long as the Pascal code is restricted to one thread you won't have a problem, otherwise the reference counting needs to be threadsafe (it uses InterlockedIncrement/-Decrement which currently is implemented as a simple inc/dec).

Yes, result in D0 is fine as well ^^

>> What do you mean with the "binutil API"? Am I wrong to assume that "binutil" also provides some library functions to include in the to-be-compiled project (e.g. "prototypes" for calling stuff in glibc) ?

Yes, you are wrong here...

In fact I do not really understand why I need to have binutils just for creating a .o file that is to be linked into a C project.

... as the binutils are merely assembler and linker. And without the former you won't get a .o file and without the later not a program ;)

> Yes, currently FPC can not generate m68k PIC code, so something like > that will be necessary. I did assume this ;-) .

I'll need to check how Linux does PIC on m68k and also learn how to implement PIC in FPC. :)

Regards,
Sven

In our previous episode, Michael Schnell said:

I can vaguely remembering some difference between Linux and NetBSD in the registers used for return values. Maybe Pierre can still remember it.

Sven Barth wrote

As long as the Pascal code is restricted to one thread you won't have a problem, otherwise the reference counting needs to be threadsafe (it uses InterlockedIncrement/-Decrement which currently is implemented as a simple inc/dec).

I understand that this code resides in the RTL, which I would need to re-implement for the "embedded" system anyway. Here I simply could disable/enable interrupt to disallow a task switch.

> ... as the binutils are merely assembler and linker. And without the > former you won't get a .o file and without the later not a program ;)

I see.

I'll need to check how Linux does PIC on m68k and also learn how to implement PIC in FPC. :)

Yep. But don't hurry :-)

-Michael

Yes, they reside in $fpc/m68k/m68k.inc and are normally OS independant as they normally use corresponding CPU instructions. There are exceptions though like the kuser_xchg, etc functions provided on certain arm-linux systems.

Regards,
Sven

Sven Barth wrote

are normally OS independant as they normally use corresponding CPU instructions.

Of course for simple stuff like inc/dec I can (better) use atomic 68 K instruction :-) .

-Michael

Of course. But e.g. not every Coldfire architecture supports them. For this reason I introduced the cpuflags CPUM86K_HAS_TAS and CPUM68K_HAS_CAS which are set if the test-and-set and the compare-and-swap instructions are available respectively (68000 only has the TAS, but not the CAS, 68020 and 68040 have CAS and TAS while Coldfire ISA-A and ISA-A+ have neither and ISA-B and ISA-C only have TAS). When I find the time I will implement the Interlocked* functions accordingly :)

Regards,
Sven

Hi,

Keep in mind that at least TAS is (basically) forbidden on Amiga, because it's incompatible with several HW implementations by Commodore and by how DMA accesses are generated by various bus extensions (Zorro II) or custom chips (eg. Agnus) in respect to the CPU and/or CPU expansion cards.

The same applies to CAS/CAS2, I guess. Basically anything which tries to do an atomic read-write cycle is not guaranteed to work correctly on Amiga.

More info:
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node012B.html http://www.devili.iki.fi/mirrors/haynie/systems/amiga2k/docs/tasa2k.pdf http://eab.abime.net/showthread.php?t=58493

So if you decide to implement anything related to this, better make it OS specific too. :) Thank you.

Charlie

CPI32 (and Fido) has add and sub instruction with memory source and Target.:-)

-Michael

Michael Schnell wrote

CPI32 (and Fido) has add and sub instruction with memory source and Target.:-)

The problem is that InterlockedIncrement and -Decrement return the value after increment/decrement. Thus (with interrupts enabled) there could be the following problem:

Assume this inline assembly code for InterlockedIncrement (target is the "var" argument of the function):

lea target, a0
addq.l (a0), 1
move.l (a0), result
move.l result, target

Now there could be an interupt between addq and move and the OS might decide to run a different thread (in case of Linux or Amiga this is definitely possible). This other thread *might* do an InterlockedIncrement for the same variable as well and might also at least finish the addq instruction. Now the first thread can run again and the move.l will contain a value after *two* increments. Or worse the other thread might have done a InterlockedDecrement and now the target value will be the same as before (keep in mind: var parameter!).

Without the possibility to synchronize the access (I include disabling interupts here ;) ) there will always be race conditions for InterlockedIncrement/-Decrement and the other Interlocked* functions.

Regards,
Sven

Thank you for the warning. ^^ *marks the mail*

Regards,
Sven

This in many cases is not a problem, as the result shows either the state before or after the interrupt and so the atomic variable itself is not a problem.

Of course the user code needs to take into account that the result already might be changed in the Pascal instruction. But I thinks this is obvious, anyway.

To do a semaphore the state of which might be critical to be known at a certain point you can do something like

bclr #0, (A0)
move ccr, D0

here the inverted state of the bit before the operation will be in bit 2 of D0.

-Michael

Done this.

Let me know if somebody feels the wording is not appropriate.

-Michael

No, because the InterlockedIncrement/-Decrement return *by definition* the value increased/decreased by one, so that the code which uses it *can* rely on this.

I've also found some semaphore related sites regarding m68k. I'm sure that I'll be able to come up with something useable :)

Regards,
Sven

Hi,

Well, today on IRC you mentioned Atari too many times for an Amiga guy's taste, so I couldn't resist...

http://charlie.amigaspirit.hu/screenshots/uae/UAE-FPC-m68k-2.7.1-FirstEver.png

:)

And besides, it was a decade old wish of me to have recent FPC running on Amiga again. This also means the CG also somewhat works for a "full" 68k, the 68020, not just for ColdFire. Sadly, it's known to be broken for plain 68000, so now really back to fixing some CG issues, before adding more platform-specific mess... :)

Charlie

Once is already too many? :P

http://charlie.amigaspirit.hu/screenshots/uae/UAE-FPC-m68k-2.7.1-FirstEver.png :)

Congrats! So the cliffhanger resolved satisfactorly :D

Yes. Do you think you could somehow crossrun the testsuite on a 68020 or 68000 system?

Regards,
Sven

Hi,

Sven Barth wrote

> Well, today on IRC you mentioned Atari too many times for an Amiga guy's > taste, so I couldn't resist... Once is already too many? :P

Yes! :)

Yeah, the cliffhanger was r27066, after that I got an Amiga compiler binary. And then it also needed r27070 before it started to work. (And I have an unfinished quick & dirty RTL patch which I still didn't commit, which is required to build the compiler (an Exec unit), but that's possible to work around if you disable the HASAMIGA parts in assemble.pas.)

Well, there's a patched QEMU which - in theory - can run 000 and 020 code. I tried it for some simple 020 bins, and that worked, I'm going to try to run the whole testsuite with it (an also '000).

The additional nice thing if it works that it's much easier to get various C libs to test with a full 68k (for example from Debian-m68k) than Coldfire.

Charlie

:P

Would be interesting to know why these patches aren't in upstream QEMU... :/

The additional nice thing if it works that it's much easier to get various C libs to test with a full 68k (for example from Debian-m68k) than Coldfire.

Agreed. :)

Regards,
Sven