Hello together!

Over the past weeks I've spent some time on getting something to work in FPC and now I'm about to commit this either this evening or at least this weekend (depending on the time I have). Now I thought that I'd make a little test to see how good you know FPC and thus I've written a little fairy tale which is more or less loosely based on the work I've done.
One important note beforehand though: it may sound as if I'm critizing some actions of the other FPC core devs in this tale, but this is definitely NOT my intention, so take the story not too seriously, please ;) [and also keep in mind, please, that I'm not a native English speaker...]

Here it is:

Once upon a time there was a small kingdom ruled by a kind king. The king had two daughters and more children were planned to come. But the king had already problems to find approbiate rooms for his second child. So he ordered his mages to reconstruct the castle in a way that the ever-growing family can easily be accommodated.
The mages immediately began with their work and reshaped the castle with their spells. But as the work on the castle neared its completion a terrible accident happend to the second princess when she played between the working mages. She was no longer able to walk or even sit upright without support. The mages tried their best to heal her, but in the end they needed to finish the castle so that the royal family could have their home back before the winter strikes. But even after the castle had been finished they didn't have enough time for the disabled princess as the family had already grown during the mages' work and required their full attention. And so the days and months passed by in which the second daughter of the king was confined to her room and could not join in the family's activities.
Then one day a young mage came along and joined the mages of the castle. He helped them with maintaining the magically enhanced castle, but while searching for places to fix and further extend he stumpled upon the room of the isolated princess. He felt sorry for the girl's state and although he did not know much about healing magic he decided to improve his knowledge and help the her. So he spent the evenings after his normal work at the castle in the library and looked through the books about healing magic. Sometimes he then went to the princess' chamber and applied his newly learned knowledge.
After some weeks his work finally paid off and the girl was able to feel and move her legs again. And after some more time she was finally able to walk again. Although she needed to move slowly and with the help of crutches, she was finally able to take part in the life at the castle again. The young mage continued to heal her and they all lived happily ever after.

So... now I'm curious what you think I have worked on and I'm also curious whether someone can fully "decipher" that little story. :)

Regards,
Sven

Are you resurrecting m68k port?

Just a guess, of course...

Pierre Muller

speaker...]

Hm.

I've been on the core team since a very long time, but I don't have a clue what this is about. I can think of several things that could apply, but the story really doesn't give clear hints - well, not to me at least.

(but then, I've never been good at symbolics)

Michael.

In our previous episode, Sven Barth said:

Once upon a time there was a small kingdom ruled by a kind king. The king had two daughters and more children were planned to come. But the king had already problems to find approbiate rooms for his second child.

King=Borland
children=Delphi and Kylix

So he ordered his mages to reconstruct the castle in a way that the ever-growing family can easily be accommodated.

reconstruction=CLX? (or Firemonkey?)

End of support of Kylix.

Mage is Lazarus/freepascal, helping old Kylixers to migrate, and remove their codebase from being "iced"/isolated.

A Kylix codebase compiles/starts to work with FPC/Lazarus

Although she needed to move slowly and with the help of crutches

Crutches=libc unit obviously

Pierre Free Pascal wrote

Are you resurrecting m68k port?

PLEEEAAASE !

-Michael

Marco van de Voort wrote

Crutches=libc unit obviously

But Wine stuff dumped :)

-Michael

Sven Barth wrote

Once upon a time there was a small kingdom ruled by a kind king. The king had two daughters and more children were planned to come. But the king had already problems to find approbiate rooms for his second child. So he ordered his mages to reconstruct the castle in a way that the ever-growing family can easily be accommodated. The mages immediately began with their work and reshaped the castle with their spells. But as the work on the castle neared its completion a terrible accident happend to the second princess when she played between the working mages. She was no longer able to walk or even sit upright without support. The mages tried their best to heal her, but in the end they needed to finish the castle so that the royal family could have their home back before the winter strikes. But even after the castle had been finished they didn't have enough time for the disabled princess as the family had already grown during the mages' work and required their full attention. And so the days and months passed by in which the second daughter of the king was confined to her room and could not join in the family's activities. Then one day a young mage came along and joined the mages of the castle. He helped them with maintaining the magically enhanced castle, but while searching for places to fix and further extend he stumpled upon the room of the isolated princess. He felt sorry for the girl's state and although he did not know much about healing magic he decided to improve his knowledge and help the her. So he spent the evenings after his normal work at the castle in the library and looked through the books about healing magic. Sometimes he then went to the princess' chamber and applied his newly learned knowledge. After some weeks his work finally paid off and the girl was able to feel and move her legs again. And after some more time she was finally able to walk again. Although she needed to move slowly and with the help of crutches, she was finally able to take part in the life at the castle again. The young mage continued to heal her and they all lived happily ever after.

I guess it's about one of the branches at http://svn.freepascal.org/svn/fpc/branches/ that was abandoned in a half-working state by two (core) developers and that you now fixed, but I have no idea about which one :)

Jonas

Is it about fpc and unit loading? ;)

Regards,
Zilvinas Ledas

Jonas Maebe wrote

On 18 Oct 2012, at 13:13, Sven Barth wrote: > Once upon a time there was a small kingdom ruled by a kind king. The

.
.

I'd guess for one of the left-overs from the 1.0 -> 2.0 transition (on the compiler side). Since I've never been involved so deeply in the compiler area, I can't remember the topic well, but I can remember repeated references to a need for rewrite of one of compiler parts - possibly something related to PPU loading / writing?

Tomas

Possibly, yes. Both Peter and I worked on that. And I believe Sven mentioned in the past he needed it for some generics-related functionality as well.

Jonas

I also think that should be something generics related since Sven is working on them last time (as well as on record helpers for simple types).

Best regards,
Paul Ishenin

[snip]

So... now I'm curious what you think I have worked on and I'm also curious whether someone can fully "decipher" that little story. :)

Thank you all for your suggestions. I hadn't thought that my story is that unobvious, but at least one of you got it right. :D There were definitely some nice suggestions like the unit loading stuff (which is indeed on my longterm ToDo list if no one else beats me there ;) ). Generics and helpers are my usual topics, so those don't apply here as well (though you, Paul are in so far right that I'm currently also working on type helpers (proof of concept) and generic constraints (nearly Delphi compatible already)). Special thanks goes to Marco for indeed trying to decipher the story.

But now the solution (I can't hold it back any longer myself ^^): Pierre was right. M68k is BACK!

At least 2.7.1 is again able to generate working executables though currently only primitive programs do indeed work as I have encountered problems with the heap manager and stdio (though this could all be related to the fact that SetJmp/LongJmp is not implemented yet...). Also I'm currently only testing on QEMU's Coldfire emulation (cfv4e to be precise), but I also plan to test Aranym (which emulates a M68040) and to purchase myself a cfv4e development board (cause ARM isn't geeky enough anymore with all those cheap boards :P ). So I hope to get the compiler fully running at least for m68k-linux (natively) and maybe m68k-embedded (cross) and to maintain that state, but every other target (e.g. Amiga) will be up to contributors.

And now you might be able to decipher the story a bit better :) (but I'm still eager to read suggestions)

Regards,
Sven

Sven Barth wrote

But now the solution (I can't hold it back any longer myself ^^): Pierre was right. M68k is BACK!

Nicely done.

but I also plan to test Aranym (which emulates a M68040)

I was impressed by it, unpretentious but effective. The only /real/ 68k I've got is a Palm on alarm clock duty.

Pierre Free Pascal wrote

Are you resurrecting m68k port? Just a guess, of course...

Too late, but it would have been my guess as well. The tale misses only the very sad part about the two children who never made it to life ;(

Sven Barth wrote

Over the past weeks I've spent some time on getting something to work in FPC and now I'm about to commit this either this evening or at least this weekend (depending on the time I have).

I've now commited my changes, but currently the compiler for m68k can only be build from within an IDE (e.g. Lazarus) as the makefile immediately complains that "ppcross68k" is missing if I want to start a "make cycle CPU_TARGET=m68k" (or a "make all CPU_TARGET=m68k"). It works for other CPUs though... (besides the point that FPC currently can't cycle on a i386-linux...)
Does anyone know what the problem could be for m68k?

Regards,
Sven

Wrong naming somewhere in the makefile? Anyways, here it stops with c:/fpc/svn/compiler/ppc.exe -Ur -Xs -O2 -n -Fum68k -Fusystems -Fuc:/fpc/svn/rtl/units/i386-win32 -Fi
m68k -FE. -FUm68k/units/i386-win32 -dRELEASE -dm68k -dGDB -dBROWSERLOG -dNOOPT -Sew pp.pas
cpupara.pas(52,90) Error: Identifier not found "tcpuregisterset" cpupara.pas(52,20) Error: There is no method in an ancestor class to be overridden: "procedure get_v
olatile_registers_int(tproccalloption):<erroneous type>;" cpupara.pas(59,3) Fatal: There were 2 errors compiling module, stopping

The strange thing is that in my normal trunk checkout (which I don't work in) starts the cycle correctly as well... Oh well... Then it does indeed seem to work and I'm again confirmed in my opinion that computers are everything but deterministic...

Anyways, here it stops with c:/fpc/svn/compiler/ppc.exe -Ur -Xs -O2 -n -Fum68k -Fusystems

-Fuc:/fpc/svn/rtl/units/i386-win32 -Fi

m68k -FE. -FUm68k/units/i386-win32 -dRELEASE -dm68k -dGDB -dBROWSERLOG

-dNOOPT -Sew pp.pas

cpupara.pas(52,90) Error: Identifier not found "tcpuregisterset" cpupara.pas(52,20) Error: There is no method in an ancestor class to be

overridden: "procedure get_v

olatile_registers_int(tproccalloption):<erroneous type>;" cpupara.pas(59,3) Fatal: There were 2 errors compiling module, stopping

Doing line based commits needs to be learned... *sigh*

Fixed in 22754

Regards,
Sven

Sven Barth wrote

So... now I'm curious what you think I have worked on and I'm also curious whether someone can fully "decipher" that little story. :)

i don't konw, specifically, of what you speak but the story has been told many times since opensource reared its head... some things just, sadly, get forgotten about and/or left behind as all the newer fancy items get worked on and applied...

i assume that's a palm pilot? if so damn, that's sad for a device that lead the PID revolution :?

Yes, a IIIe I scrounged. I believe there's a Pascal compiler for it but I've never tried running it.

I believe that the Palms were at one time popular as a "brain" for mobile robot experiments, programmed using a larger system and orchestrating commands to microcontrollers.

Sven Barth wrote

Pierre was right. M68k is BACK!

GREAT ! Thanks a lot.

We just developed a board featuring a "Fido" chip by Innovasic. The prototype is sitting on my desk since the beginning of this week.

Fido is a very nice upgrade to the Mortorola 68332 chip (hardware-multi-threaded <i.e. five automatically switching register sets>, 66 MHz instead of 16, four versatile 8 Bit coprocessors instead of one "Time machine coprocessor", two DMA controllers instead of none, a decent amount of internal memory, external SDRAM possible, ...).

So I would able and happy to do some tests with the 68 K cross-compiler, if same can do code for a no-MMU hardware without a "normal" OS.

-Michael

Pray tell.

One wonders whether this would be a good time to send orphans such as Alpha and IA-64 into the forest.

[This should have gone to the list, instead of Florian directly]

I see that I should have waited a bit longer then ^^

Yes... that could be mentioned as well... (and what about "vis"? ) though Itanium looks in my opinion more dead for real than M68k (considering the existance of Coldfire)... and Alpha is also only available if you can find a legacy system

Regards,
Sven

Mark Morgan Lloyd wrote

Pray tell.

AFAIK, MIPS has not completely seen the light of day.

I fell this would be a really interesting Architecture, as e.g. Microchip adopted it for PIC32 and they are aggressively developing more and more chips on that base. I heard about one to come that might run with 400 MHz and have several MByte internal Flash and some 512 K of internal RAM (and of course lots of PIC-standard on-Chip peripherals)

Seems very appropriate for versatile embedded controllers.

-Michael

How do you mean that?

Regards,
Sven

Sven Barth wrote

How do you mean that?

From what I read in the forum I understand that someone is really interested and maybe working on it, but it's not yet usable out of the box. Am I wrong ?

-Michael

The question is in how far the Fido is compatible with the Motorola CPUs. The Coldfire for example imposes several restrictions to a.g. memory accesses and the instruction set in general (which shows in some of the changes I have done). If they are mostly similar one could add a new "fido" cpu type to address special issues.

Also please keep in mind that currently neither the heap manager nor stdio nor (likely) exceptions are working correctly. I need to address these issues first so that the port becomes fully useable again (as the target is to have again a native m68k-linux compiler).

Regards,
Sven

It runs enough that we already have automatic test results for MIPS and MIPSel (around 125 failures, while other platforms have around 30 (or 70 for the BSDs)). So it's already quite usable. More than m68k at least ;)

Regards,
Sven

It looked pretty darned good when I was running it under Qemu two days ago.

Sven Barth wrote

It runs enough that we already have automatic test results for MIPS and MIPSel

Great !

I will check it once I will get a prototype with a PIC32 (supposedly not before 2014).

-Michael

I'd love to see an Itanium port, but I don't think it's realistic in view of the limited number of manufacturers shipping systems based on it and the known difficulty of filling the bundles. I haven't had a chance of looking at GCC output to see how well their backend does, but the last I heard it was difficult to get even 75% utilisation. Add to that the the opcode set etc. is weird: SPARC-style register windows with none of the charm.

To my surprise I've got an Alpha system, but my understanding is that nobody's making silicon any more. Since Chinese manufacturers appear to have settled on MIPS as their non-x86 of choice, I don't see much future for it.

Vis, LLVM, and- of course- the Android and JVM ports are obviously valuable. Apart from that the only architecture that FPC doesn't support is the IBM S/390.

Mark Morgan Lloyd wrote

It looked pretty darned good when I was running it under Qemu two days ago.

Nice ! good to know...

-Michael

Sven Barth wrote

The question is in how far the Fido is compatible with the Motorola CPUs.

It's nearly 100% code-bit compatible with the 332 (aka CPU32), there are some additions to provide multi-threading and power-Management (e.g. the "trapx" and "sleep" instructions) and some additional registers accessible by the movec instruction to support certain hardware features. But there are only very few dropped features: the only I know is that the source and destination function code registers do exist but have no influence on the hardware,

I don't think that this is relevant to the compiler.

Also please keep in mind that currently neither the heap manager nor stdio nor (likely) exceptions are working correctly. I need to address these issues first so that the port becomes fully useable again (as the target is to have again a native m68k-linux compiler).

Let me know when you want me to do any tests.

For me it would be the easiest way to have fpc compile the Pascal sources to ANSI C gnu compatible object code (*.a files ? ) so that I can just link it to an existing ANSI-C project. Here the heap management would be done by the GNU C library (or am I wrong ?). But I don't know how the FPC RTL comes into play...

-Michael

In our previous episode, Sven Barth said:

Those *bsd results are probably very skewed. Much more binaries use "iconv" now, but apparently some of the VMs the testsuite runs on don't get the location of that library right.

You're wrong ;-)

Mark Morgan Lloyd wrote

You're wrong ;-)

I do like this fact :-) :-) :-) .

-Michael

I wouldn't wonder if Alpha was sold more than Itanium ;)

To my surprise I've got an Alpha system, but my understanding is that nobody's making silicon any more. Since Chinese manufacturers appear to have settled on MIPS as their non-x86 of choice, I don't see much future for it.

That nobody is producing Alpha (or Alpha-like) chips anymore is the biggest problem with it. So only have legacy devices and emulators to work on...

Vis, LLVM, and- of course- the Android and JVM ports are obviously valuable. Apart from that the only architecture that FPC doesn't support is the IBM S/390.

As Android and JVM ports are working ports I don't say anything about them (especially since I already used the Android port to write an application for my phone). The LLVM port is not even in trunk yet, so I don't say anything about it either. But I don't know what state Vis is in especially since I don't know what VM it does use exactly.

Regards,
Sven

From what I can see from your explanation I'd agree. In the end only a test can tell. As Pierre is already improving M68000 support you might have more luck today than yesterday ;)

Once I'm satisfied myself everyone is welcome to test more complex programs :)

It would be easier if you'd use the C code from within FPC code. You might also circumvent heap manager issues by using the "cmem" unit. But as I already wrote I'm currently using the user space emulation of QEMU and with that I don't have the need to find/compile corresponding C libraries and I'd anyway like to have FPCs normal syscall interface for Linux working. Also I don't know how well FPC will handle it if I let it link to libraries as this is not tested yet...

Regards,
Sven

Sven Barth wrote

But I don't know what state Vis is in especially since I don't know what VM it does use exactly.

That port was started by Carl-Eric Codere, and afaik VIS was a "Virtual Instruction Set" (= VIS) he invented himself.

Jonas

Thank you for the explanation.

Regards,
Sven

Much as I respect venerable antiques, if nobody's using it and having an FPC port isn't going to encourage use I see little point in the effort.

SPARC is live- although Oracle are being aggressive in their attempts to make it a closed system for their turnkey products. MIPS is alive, courtesy of the Chinese who- I'm told- are now shipping good-value kit. 68K is alive thanks to Coldfire etc. IA-64 is alive but on life-support. IBM mainframes are alive, thanks largely their support for Linux.

In our previous episode, Mark Morgan Lloyd said:

68K is alive thanks to Coldfire etc.

Well. I would like to run it on the real thing. 68040/40 the same one as 1.0.x did :-)

For MIPS it's not only the Chinese. MIPS CPUs are used in quite some current TVs together with ARM. Especially Samsung is rather prominent here (on both flavors runs Linux).

Regards,
Sven

Do you have a system with such a CPU? If so it would be nice - if time permits - if you could test a bit. Of course you can wait until I fixed the heap manager and stdio issues :)

Regards,
Sven

In our previous episode, Sven Barth said:

Routers are also often MIPS. MIPS is said to have lower licensing costs than ARM.

In our previous episode, Sven Barth said:

I still have a Quadra AV, though it has not run since FPC 1.0.x times. I was thinking of buying a SCSI2CF converter, and try to get it running again. ($130ish)

At some point it had 128MB and ran NetBSD. I checked, and NetBSD/macm68k is still supported in the most recent release (though there are no images yet)

Sven Barth wrote

It would be easier if you'd use the C code from within FPC code.

I don't think I can easily do this, as there is a booting system called "Leash" provided by Innovasic, that finally runs the user code (everything is compiled to a single loadable/executable file, though, it's embedded stuff in the end...) Leash is highly configurable, initializes the chip internal hardware and finally starts and monitors four user's hardware-Threads, that work (and in the Eclipse-based debugger look as if there really were) four (plus one) independent processors.

So, if you think it's not easily doable to link a set of fpc procedures into this monolithic executable, maybe writing a little loader (e.g. loading the fpc executable into a dedicated predefined memory location) would be easier to do and workable at least for testing.

You might also circumvent heap manager issues by using the "cmem" unit.

Or in the loader providing a cmem workalike, that preforms a callback to the C-generated infrastructure, that of course does provide malloc() and friends...

As my system obviously does not run Linux, I hope I might be able to provide some kind of infrastructure that allows to decently execute FPC generated files. (This maybe in fact is similar to what QEMU does - without the code-interpreter.)

Thanks,
-Michael

As I said the other day, having real hardware available is a big incentive to firing something up and checking things work. But I haven't a clue what realistic 68K systems are available these days.

Marco van de Voort wrote

MIPS is said to have lower licensing costs than ARM.

Its also said to use less die space than ARM, but provide a lower performance/clock relation.

Besides the already mentioned implementations, multiple dedicated chips, and the rather universal PIC32, AFAIK MIPS is used as a soft-core in FPGAs. Altera provides a rather nice "NIOS" processor core, that is quite similar to MIPS.

-Michael

Michael Schnell wrote

As my system obviously does not run Linux, I hope I might be able to provide some kind of infrastructure that allows to decently execute FPC generated files. (This maybe in fact is similar to what QEMU does - without the code-interpreter.)

I've never really tried to get to grips with the innards of Qemu, but I suspect that it's complex. I've got a very vague recollection that Bochs can be embedded.

That I didn't appreciate. I think it's probably very easy to confuse it with a similarly-named SPARC opcode extension.

On Fri, Oct 19, 2012 at 11:25 AM, Mark Morgan Lloyd <

You're probably talking about PocketStudio (
http://en.wikipedia.org/wiki/PocketStudio). When they appear I semi-automatically ported my ReadThemAll reader for PalmOS from C to their flavor of Pascal. Worked well. Interestingly they still offer the product as I see (http://www.winsoft.sk/pstudio.htm). Pity PalmOS is dead, otherwise it would be reasonable to suggest some kind of compatibility between fpc and PocketStudio.

Max

Before I forget it: here is the meaning of the story elements:

small kingdom => FPC project + community (small compared to e.g. the C "kingdom" ;) )
the royal family => the compiler with
the king => the "fpc" binary
the children => the single "ppcX" binaries (with "ppcX" and "ppcrossX" being together as one)
the oldest child => x86 (the platform on which Florian developed FPC on)
the second oldest child => m68k (the first platform after x86 that he compiler was ported to and which lead to the insight that the code generator needs to be redesigned)
all the other younger children => arm, powerpc(64), sparc, mips(el), x86_64, jvm (, aarch64 ;) ) - most of them were "born" during the rewrite
(not mentioned, but the children that are dead (at least so far) => alpha, itanium, vis)
the mages => the compiler developers
the rebuilding of the castle => the code generator rewrite (and I like the result very much! :D )
the "accident" => m68k never got fully rewritten
the "young mage" => me :)
the healing => fixing the m68k code generator
the need to use crutches => m68k starts to compile simple applications again (the current state I'd describe as "heavily limping without crouches" by the way)

I hope now it's more clear what I wanted to tell with the story. Some parts might indeed not be that obvious (e.g. that the king is the "fpc" binary; he could have been "King FPK" as well ;) ), but I had not imagined that it's that unobvious...

Regards,
Sven

I go back rather (too?) far...eg pre v1.0 - unfortunately I can't remember what the version was when I first downloaded fpk & tried to compile an fft
- it crashed compiler - fixed by Jonas iirc. I'm so sad that I still use fpk for fpc directories - I'm kind'a sorry we changed that. I sort of got the flow about 'right'? except I thought the king might be have been & perhaps should have been Florian!

NIce story, btw brilliant English too - tho' I'm used to calling the 3 Kings 'Magis' in context of Christmas and all that...J

Sven Barth wrote

the "young mage" => me :)

Could you publish a state report on how powerful the actual magic has become ?

Thanks,
-Michael

If you mean how far the m68k port has come now, sure:

* currently the only tested "environment" is QEMU's userspace emulation for Coldfire (v4e to be precise, though I currently try to stay with ISA_A without adding ISA_B features - I save that for later ;) ); I've not yet come around to test programs on Aranym (simulates a M68040) or real hardware (I plan to purchase a cfv4e development board though :) )
* the state of the Amiga and Atari targets is not yet known (I'd first need to build binutils for them); I stated that I won't really work on them, but I want them at least compiling and a working "Hello World" program on corresponding emulators (target "palmos" is definitely off for me though :) )
* no work was yet done for m68k-embedded (I plan it for the future once m68k-linux is working good enough)
* the test suite does not yet run unattended, because there are some tests that cause a hang in the emulator (not yet investigated) - the compiler itself is another example of such an application (so no native Coldfire compiler yet)
* primitve procedural programs do definitely work
* StdIO (to/from console/file) is working
* the Linux API can be used without problems (so far)
* signal handling works (recently I also managed to get the stack trace output working :) )
* command line parameters are handled correctly, environment variables don't work yet
* linking to C libraries was not tested (and from what I've seen so far in the startup assembly code it might not work)
* building Pascal libraries was not tested and might not work as well
* sets are currently problematic as well
* 64-Bit operations do work (since the weekend ;) )
* floating point operations don't work currently (includes Currency though it should be an Int64 on m68k...)
* the calculation of array element addresses in multi dimensional arrays might currently be wrong (at least I had troubles with the MonthDay array in SysUtils)

Nevertheless although it's quite hard work it's also a very rewarding work as you can see that after a bit of work another test compiles or even runs correctly (though most tests currently fail at runtime as you can see below).

Here are the testresults from the weekend before I fixed the 64-Bit operations (which caused at least 2 tests to fail, though it could be more as the compiler sometimes uses 64-Bit values for immediates) and the command line parameters.

=== testresults begin ===

Total = 5919 (1133:4786)
Total number of compilations = 3681 (172:3509)
Successfully compiled = 2603
Successfully failed = 906
Compilation failures = 170
Compilation that did not fail while they should = 2 Total number of runs = 2238 (961:1277)
Successful runs = 1277
Failed runs = 961
Number units compiled = 121
Number program that should not be run = 241
Number of skipped tests = 389
Number of skipped graph tests = 10
Number of skipped interactive tests = 29
Number of skipped known bug tests = 6
Number of skipped tests for other versions = 4
Number of skipped tests for other cpus = 282
Number of skipped tests for other targets = 58

=== testresults end ===

Regards,
Sven

Sven Barth wrote

* primitve procedural programs do definitely work

This sounds very promising for me, as my planned application is not on a formal OS, but I'll need to build a wrapper to make the Pascal procedures run on my homebrew OS.

I'll just need a decently working compiler and the necessary parts of the RTL,

I suppose I'll need to modify the RTL's OS-API interface according to my needs. Supposedly I just need memory management and semaphores / thread-communication, plus some kind of (serial) bytestream (Pipe). Not files.

In fact the first program is supposed to do the communication with a GPRS modem via a serial interface ("AT..." stuff). The program should be called from a (GNU) ANSI-C program and should be able to call ANSI-C procedures. (The program already works nicely on Delphi/Windows.)

I'll stay tuned. :-)

Thanks,
-Michael

Is "aarch64" the upcoming 64 Bit ARM v8 (
http://www.arm.com/products/processors/instruction-set-architectures/armv8-architecture.php ) ?

Same seems very interesting for future Linux servers and there are strong rumors that Apple might migrate their Laptops and Desktops away from Intel ta ARM (v8).

Regarding that we already do have arm 32Bit and x86_64 this seems rather doable (once testing hardware and/or simulators are available).

-Michael

I wonder whether a PPC Mac- which I believe has good 68K emulation- would be a comfortable testbed?

I don't know... I never had a Mac and thus can not tell. Also this might need a working Mac OS Classic support for m68k first...

Regards,
Sven

I've got one. I'll look. I'll be back.

Didn't you wrote on the Lazarus list that you don't want to get sidetracked? :P

Regards,
Sven

Yes, but the boss is less likely to read this one :-)

Besides which, finding that dirt-cheap hardware was actually a useful substitute for stuff which wasn't easy to source might actually be useful.

Digging around earlier in the day suggested that Apple is doing everything possible to bury the Programmer's Workbench download, but once the name of the file is known it turns out to be cached in various places.

What's the Programmer's Workbench?

Regards,
Sven

Shell, assemblers and so on according to Wikipedia- I'll know more when I've got it installed. Basically, all the stuff that Apple has always sworn their customers didn't need. At one time it had a Pascal compiler, but I think that was dropped. Mentioned in the MacOS variant of FPC's RTL, which looks like it's got at least some 68K stuff in there.

I'm fairly sure that it doesn't include ssh, VNC and so on, which will be a pain. The Mac's got a browser but I don't know about things we take for granted like ftp. Up to now my only use of MacOS on this machine has been to run the program that tells it to boot Linux.

In our previous episode, Mark Morgan Lloyd said:

MPW, I must have some of those downloads somewhere too.

MPW superficially running here. The PPC macos RTL doesn't compile out of the box, I'll dig in presently and start a new thread rather than extending this one indefinitely.

I'm putting notes as I go along in
http://wiki.lazarus.freepascal.org/Target_MacOS which appears to have been written in 2004/2005.

FPC for m68k targeting Linux currently doesn't build due to warnings:

Compiling paramgr.pas
paramgr.pas(297,17) Warning: unreachable code
paramgr.pas(343,21) Warning: unreachable code
paramgr.pas(578) Fatal: There were 2 errors compiling module, stopping Fatal: Compilation aborted
make[1]: *** [ppc68k] Error 1
make[1]: Leaving directory `/usr/local/src/fpc/fpc-trunk/compiler' make: *** [m68k] Error 2

Appears OK if -Sew removed but I've not tried running the result.