I was browsing some TP pages, and found this Pascal-compiler poll:

http://pub.alxnet.com/poll?id=1250146

FPC is already second, after TP :-)

(and third is Bloodshed........)

Marco van de Voort ( or )

The funny part is how -bad- GNU pascal is. I havn't gotten any remotely serious project to comile in GNU pascal, and yet they claim borland pascal compatibility. Their "compatibility" is so easily broken just by declaring a variable with a name that is reserved in C (since it apparently still reserves those in pascal), and that's just the start. It's amazing how broken it is, when I can get most of my programs to compile under Borland TP 7 for DOS, Pure Pascal for Atari, Free Pascal for Linux, and even Delphi on windows (which lacks CRT, etc.). Consider also that Virtual Pascal has only 2%, but that's for OS/2, and I'm sure it has most of the OS/2 pascal people (just that that's a smaller group). GNU pascal works on a lot more platforms than even Free Pascal. Obviously it is pretty bad if it still can't gain support. I myself would like to use it because I use Linux on Sparc, and there is no Free Pascal yet for Sparc, so I have really tried to get GPC to be usefull, I am not just bashing it here, but I challenge anyone else to port a large borland pascal type program to it. The [most recent] program I was trying to port was my matchup CGI, which can be found (as source) on atari-source.com, and also actually running ; The CGI
portion compiles only on Free Pascal at the moment, but the rest of it will compile on VP in OS/2, BP7 on DOS, Delphi, and Pure Pascal on Atari. The delphi took the most work (to fake out a CRT unit), and was still easy compared to trying to get anything to work under GNU Pascal.

- noah

I have a shell account on a linux sparc box..
How hard would it be for someone reasonably proficient in pascal, very proficient in assembler and never done anything on a sparc to port the compiler ?

I have (had) a real SPARC and gave up two years ago (even though I'm pretty proficient in Pascal AND 68K/x86/Z80/6xxx assembler). You would need not only a fairly good knowledge about the SPARC CPU, but also about the whole SPARC system as well.
I got some source from someone who started a port (Carl-Eric ?), but after several weeks, i still didn't get anything working. Then first my SPARC (actually the hard drive and the memory) died and shortly after that i changed jobs and didn't have any time anymore....
At the same time the x86 compiler made so many changes, that i even thought it wouldn't make any sense anymore to even try to keep up, maybe it's easier once they are done with the changes to support multi CPU support that was mentioned a few times before on this list...

Ralf

I suppose it depends on if that person knew/could learn RISC assembler. (i.e. MIPS is similar to SPARC, while intel or some others are fairly different).
Anyhow, I would be willing to loan out accounts on a linux/sparc machine, and maybe even set up another linux/sparc machine for the purpose of helping development.

thanks,
noah silva

Yes,

I have used beta versions of the m68k version of FPK onmy Atari. It is obvious to me from these posts that interest for a sparc port is definatly there. Not only that, but once a sparc port is done, porting to MIPS and other Risc processors would be more straighforward. Again, if anyone has serious intentions of working on this, I have several internet connected sparc/linux machines that could be at their disposal. I think lack of multi-processor support is really holding FPK back at the moment. If FPK worked well on Atari I wouldn:t use Pure Pascal so much. If it worked on Sparc, I wouldn:t waste so much time trying to get GPC to compile anything, and I wouldn:t need this 486...

Thanks,
Noah Silva

It would be a bad idea to start a port right now, because the code generator is being reorganized. The purpose of these reorganizations is to be able to make porting to a new processor more easy.

The core FPC team has plans for m68k, ALPHA and PPC ports; SPARC has been requested several times, so if someone else could do that it would be very good. The existing Intel Solaris port could then be used to provide the RTL.

But as I said, it is better to wait a little for starting a new CPU port.

Michael.

Ok, I have read the docs/Makefiles.. and I can't get a definitive answer.. soooo...
Can you make a shared rtl yet?
ie libfpc.so
that all my programs can dynamicly link against ?
I tried doing a make_shared in the rtl dir, but it gives me an io error 101 with PPU-Mover 0.99.7

The other question..
I have this great script that I can feed the names of all my executables and it strips glibc down to only the required routines needed for those executables..
Can I do the same with libfpc.so (if I can even create it)

I'm using this in an embeded type environment with very limited disk space so I can strip glibc2.1 down to 440k from 800k to save space.. It would be nice to be able to do the same thing with the fpc shared lib. If I can use it at all that is..

Maybe I'm off base here, but I was thinking of linux for SPARC. I guessed this would take care of most of the architecture specific stuff, and leave just the raw SPARC code to convert.
Not that I have a SPARC anyway, just an account on one. Thought it might be a nice project though. Like I have a 68k Mac running Linux, and I'd considered a port to that. This should only really involve the code generation, as all other stuff is handled by syscalls to the kernel, and MVC has already done that for the x68 port.

For 1.0.x compiler you need ppumover 1.00.

You can create a shared library. But since the compiler doesn't generate PIC (position independent code) it's possible that the resulting executable doesn't work correct. But simple tests have shown in the past that it worked good for small problems.

Don't know how your scripts works. but you can always edit the RTL yourself and strip all unused things.

...

I was unaware that there was a solaris/intel port of FPK, but a lot of us with Sparcs use Linux, because it is faster on low end sparcs.

thanks,
noah silva

Support is in the compiler (both 1.0.5 and 1.1 versions). But there is no RTL yet.

Yes, but there is a binary distribution which should work.

Michael.