Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2004-01

Mac OS X pre-release version of the Free Pascal Compiler available!

25 messages · 6 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Jonas Maebe

Hello,

I'm very glad I can announce that today, for the first time I've been able to do a "make cycle" under Mac OS X (compile the compiler with itself, and then again with the resulting compiler, and then once more). This means that the compiler is now self-hosting under Darwin/Mac OS X, and ready for first testing!

--- What is ready?

* The basic units required to cycle the compiler (mostly file-system and exception handling related)
* The PPC code generator is in quite good shape (correctness-wise). On Linux/PPC, our regression test suite currently shows 17 errors (on 2185 tests), versus 10 for the 80x86 version. I have not yet run the test suite under Mac OS X, and some OS-specific things will probably still need fixing

--- What is still left to do?

* Mac OS (X) specific:
* Port the missing RTL units (mainly text console handling)
* Create a Mac OS X installer package definition
* Try to create some kind of plug-in so the compiler can be called from XCode and Project Builder
* Run the test suite and fix bugs
* Fix support for importing global variables from shared libraries
* Replace as many of my handwritten assembler routines with calls to libc versions, as Apple is much better at writing fast ppc assembler code that I am :) Do the same for the generic math routines.
* Support the Apple dialect so we can use the Universal Interfaces
* Finish Classic Mac OS support
* ...

* PPC-specific:
* improve AIX abi-compatibility (e.g., we don't pass records as the AIX abi prescribes)
* create a PPC-optimizer (if only a peephole optimizer for starters)
* re-enable support for register variables (that's not really PPC-specific, but the PPC will benefit a *lot* of that)

--- System requirements

The Darwin RTL is based on libc and uses only a few basic library calls. Therefore, even though I compiled the binary below on Mac OS X 10.3.2, it should theoretically run on everything, even the Mac OS X Public Beta :) The BSD subsystem and the Developer Tools (or XCode) must be installed, though. There are no further requirements.

--- Where to get it

* The source

You can get the source code of the compiler and rtl by following the instructions at <http://www.freepascal.org/develop.html#cvs>. To recompile the compiler and rtl, first download and install the binary snapshot as indicated below, then go in the fpc/compiler directory you checked out from cvs and type "make cycle".

* The binary snapshot

You can download a minimal binary snapshot from
<http://jonagold.elis.ugent.be/~jonas/fpc/fpc-darwinppc -20040104.tar.bz2>. I would suggest not unpacking it with Stuffit Expander, but on the command line. Use

gnutar xjvf fpc-darwinppc-20040104.tar.bz2

and it will expand the file in the current directory. You'll get one directory (fpc) with two subdirectories: bin and rtl. The bin directory contains the two program files, ppcppc (the actual compiler) and fpc (the compiler front-end). The rtl directory contains a darwin subdirectory with all units.

The easiest will be if you put this fpc directory in your home directory, then create a file called ".fpc.cfg" (note the extra "." at the start) in your home directory with as contents (replace <your_short_name> with your short login name)

-Fu/Users/<your_short_name>/fpc/rtl/darwin
-O1
-vei

Next, if your shell is bash, add the following to the file .bash_profile in your home directory (create the file if it doesn't exist yet):

export PATH=~/fpc/bin:"$PATH"

If your shell is tcsh, add the following to the file .tcshrc in your home directory:

setenv PATH ~/fpc/bin:{$PATH}

Type 'exit' in the Terminal window, and then open a new one. From now on, you can compile programs by going to the directory with your source files and typing e.g.

fpc helloword.pas

Run the result by typing

./helloworld

Happy programming, and bug reports are of course welcome!

Jonas

Reply by email

Marco van de Voort
to Jonas Maebe: Sorry, make that <http://jonagold.elis.ugent.be:8080/~jonas/fpc/fpc-darwinppc…
Show quoted text 9 lines
On 4 jan 2004, at 23:23, Jonas Maebe wrote: > You can download a minimal binary snapshot from > <http://jonagold.elis.ugent.be/~jonas/fpc/fpc-darwinppc > -20040104.tar.bz2>. Sorry, make that <http://jonagold.elis.ugent.be:8080/~jonas/fpc/fpc-darwinppc -20040104.tar.bz2>.

Most of the failures look like "usual suspects". The ones that always fail after porting.

At least the two texceptions, tlibrary's and tmt1 faill in that category.

tw0869,tw0937,tw1152, tw1792a, tw2318b, tw2377 sound familiar too.

Reply by email

Jonas Maebe
to Karl-Michael Schindler
Karl-Michael Schindler wrote
fpc runs on my Dual G4 867 MHz, but on my iMac G3 233 MHz and my PowerBook 12" G4 800 MHz it doesn't. I receive: Bus error

Strange. Which versions of Mac OS X are they running? There were some problems with the alignment settings, but in most cases that's harmless (it's only a problem if you try to use atomic operations, but those are only used in a few places and nowhere in the compiler itself, afaik).

Jonas

Reply by email

Karl-Michael Schindler
to Jonas Maebe
Jonas Maebe wrote 10 lines
On 7 jan 2004, at 17:58, Karl-Michael Schindler wrote: > fpc runs on my Dual G4 867 MHz, but on my iMac G3 233 MHz and my > PowerBook 12" G4 800 MHz it doesn't. I receive: Bus error Strange. Which versions of Mac OS X are they running? There were some problems with the alignment settings, but in most cases that's harmless (it's only a problem if you try to use atomic operations, but those are only used in a few places and nowhere in the compiler itself, afaik).

German 10.3.2 on all three of them. Maybe something is wrong with my libSystem.B.dylib or the libmathCommon.A.dylib on the two.

That's the system.log of the PowerBook:

Jan 8 13:50:55 localhost crashdump: Unable to determine CPSProcessSerNum pid: 1565 name: fpc
Jan 8 13:50:55 localhost crashdump: Started writing crash report to: /Users/michael/Library/Logs/CrashReporter/fpc.crash.log Jan 8 13:50:57 localhost crashdump: Finished writing crash report to: /Users/michael/Library/Logs/CrashReporter/fpc.crash.log

And /Users/michael/Library/Logs/CrashReporter/fpc.crash.log:

Host Name: michael-pbook-ep3.local
Date/Time: 2004-01-08 13:50:55 +0100
OS Version: 10.3.2 (Build 7D24)
Report Version: 2

Command: fpc
Path: /Users/michael/fpc/bin/fpc
Version: ??? (???)
PID: 1565
Thread: 0

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000018

Thread 0 Crashed:
0 fpc 0x00031a84 0x1000 + 0x30a84 1 libSystem.B.dylib 0x90025148 _sigtramp + 0x68 2 libSystem.B.dylib 0x9001a5ac syscall + 0xc
3 libSystem.B.dylib 0x90020a4c sigaction__ + 0xac 4 fpc 0x00031b08 0x1000 + 0x30b08 5 fpc 0x00039fe8 0x1000 + 0x38fe8 6 fpc 0x0002f0e4 0x1000 + 0x2e0e4 7 fpc 0x0003a498 0x1000 + 0x39498 8 fpc 0x00039f04 0x1000 + 0x38f04 9 fpc 0x0000223c 0x223c + 0x3923ff4f 10 fpc 0x000020b0 0x20b0 + 0x3923fdc3

PPC Thread State:
srr0: 0x00031a84 srr1: 0x0000f030 vrsave: 0x00000000 cr: 0x48000042 xer: 0x00000000 lr: 0x00031a70 ctr: 0x90003800 r0: 0x00031a70 r1: 0xbfffeff0 r2: 0x54485244 r3: 0x00000008 r4: 0x00000000 r5: 0xbfffeefc r6: 0xbffff1d8 r7: 0xbffff218 r8: 0x00000000 r9: 0x00000001 r10: 0x00000004 r11: 0xa0004228 r12: 0x90003800 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000 r20: 0x00000000 r21: 0x00000000 r22: 0x00000000 r23: 0x00000000 r24: 0x00000000 r25: 0x00000000 r26: 0xbffffe68 r27: 0x00000008 r28: 0xa00050e8 r29: 0xbffff218 r30: 0x00000001 r31: 0x900250e8

Binary Images Description:
0x1000 - 0x3afff fpc fpc
0x8fe00000 - 0x8fe4ffff dyld /usr/lib/dyld
0x90000000 - 0x90122fff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x939d0000 - 0x939d4fff libmathCommon.A.dylib
/usr/lib/system/libmathCommon.A.dylib

Michael

Reply by email

Jonas Maebe
to Karl-Michael Schindler
Karl-Michael Schindler wrote
German 10.3.2 on all three of them. Maybe something is wrong with my libSystem.B.dylib or the libmathCommon.A.dylib on the two.

I doubt it. However, maybe you could try ppcppc instead of fpc. It's quite possible that fpc does use ansistrings, which require atomic operations for increasing/decreasing their reference counts.

Jonas

Reply by email

Florian Klaempfl
to Jonas Maebe
Jonas Maebe wrote 10 lines
On 8 jan 2004, at 14:03, Karl-Michael Schindler wrote: > German 10.3.2 on all three of them. Maybe something is wrong with my > libSystem.B.dylib or the libmathCommon.A.dylib on the two. I doubt it. However, maybe you could try ppcppc instead of fpc. It's quite possible that fpc does use ansistrings, which require atomic operations for increasing/decreasing their reference counts.

This is only required when running multithreaded programs.

Reply by email

Karl-Michael Schindler
to Jonas Maebe
Jonas Maebe wrote 6 lines
You're right, and as of yet our compiler isn't multithreaded :) Strange... anyway, I've put a new snapshot at <http://jonagold.elis.ugent.be:8080/~jonas/fpc/fpc-darwin -20040108.tar.bz2>.

try of new ppcppc just returns immediately and gives this ppcppc.crash.log:

Host Name: michael-pbook-ep3.local
Date/Time: 2004-01-09 11:11:37 +0100
OS Version: 10.3.2 (Build 7D24)
Report Version: 2

Command: ppcppc
Path: ./ppcppc
Version: ??? (???)
PID: 9535
Thread: 0

Exception: EXC_ARITHMETIC (0x0003)
Code[0]: 0x00000003
Code[1]: 0x60224090

Thread 0 Crashed:
0 libSystem.B.dylib 0x9001a5ac syscall + 0xc
1 libSystem.B.dylib 0x90020a60 sigaction__ + 0xc0 2 ppcppc 0x00147268 SYSTEM_INSTALLSIGNALS + 0x58 (osmain.inc:530)
3 ppcppc 0x0014f748 INIT$_SYSTEM + 0xc8 (system.pp:158) 4 ppcppc 0x001447b4 fpc_initializeunits + 0x84 (system.inc:609)
5 ppcppc 0x0014fae4 P$PP_main + 0x14 (pp.pas:191) 6 ppcppc 0x0014f664 main + 0x44 (system.pp:145) 7 ppcppc 0x00001cdc _start + 0x188 (crt.c:267) 8 ppcppc 0x00001b50 gcc2_compiled + 0x30 (rgcpu.pas:207)

PPC Thread State:
srr0: 0x9001a5ac srr1: 0x0011f930 vrsave: 0x00000000 cr: 0x22000042 xer: 0x20000000 lr: 0x90020a60 ctr: 0x9001a5a0 r0: 0x00000000 r1: 0xbffff810 r2: 0x8fe507cc r3: 0x00000000 r4: 0x00000000 r5: 0xbffff850 r6: 0xbffff890 r7: 0x00000000 r8: 0x00000000 r9: 0x00000006 r10: 0x00000000 r11: 0xa0003d6c r12: 0x9001a5a0 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000 r20: 0x00000000 r21: 0x00000000 r22: 0x00000000 r23: 0x00000000 r24: 0x00000000 r25: 0x00000000 r26: 0xbffffe54 r27: 0x00000008 r28: 0xbffff890 r29: 0xbffff850 r30: 0x00000008 r31: 0x900209a8

Binary Images Description:
0x1000 - 0x14ffff ppcppc ./ppcppc
0x8fe00000 - 0x8fe4ffff dyld /usr/lib/dyld
0x90000000 - 0x90122fff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x939d0000 - 0x939d4fff libmathCommon.A.dylib
/usr/lib/system/libmathCommon.A.dylib

Reply by email

Karl-Michael Schindler
to Jonas Maebe
Jonas Maebe wrote 12 lines
On 9 jan 2004, at 11:17, Karl-Michael Schindler wrote: > try of new ppcppc just returns immediately and gives this > ppcppc.crash.log: Thanks, I think I know what the problem was. I didn't clear all "fpu exception happened for reason X" flags before enabling fpu exceptions. Please try <http://jonagold.elis.ugent.be:8080/~jonas/fpc/fpc-darwin -20040109.tar.bz2>

Good Job.
Success on the Powerbook. Can't check on the Dual PowerMac, right now. I am a bit short in time right now.
Just assume it's fixed, unless I tell differently.

Nice Weekend to everybody!

Michael

Reply by email

Karl-Michael Schindler
to Jonas Maebe: You're right, and as of yet our compiler isn't multithreaded :) Strange... anyway, I've…

When making the rtl under and for darwin I get the following error:

Compiling ../unix/systhrds.pp
thread.inc(34,21) Error: Identifier not found "SysGetCurrentThreadID" systhrds.pp(136) Fatal: There were 1 errors compiling module, stopping

grepping for SysGetCurrentThreadID did not find anything besides the above occurence in thread.inc.
However, I found numerous GetCurrentThreadID.
Therefore, I changed SysGetCurrentThreadID to GetCurrentThreadID in thread.inc and BINGO make cycle went through.

Comments?

Greetings

Dr. Karl-Michael Schindler
FB Physik
Martin-Luther-Universität Halle-Wittenberg
D-06099 Halle (Saale)
Germany
Tel.: ++49 (0) 345 552-5563

Reply by email

Jonas Maebe
to Karl-Michael Schindler
Karl-Michael Schindler wrote 7 lines
grepping for SysGetCurrentThreadID did not find anything besides the above occurence in thread.inc. However, I found numerous GetCurrentThreadID. Therefore, I changed SysGetCurrentThreadID to GetCurrentThreadID in thread.inc and BINGO make cycle went through. Comments?

Yes, someone obviously made an error when he committed (not just Darwin is broken, almost all of the RTL's are). I think your solution is fine (and even if it's not, I don't think many programs, even multi-threaded ones, will suffer from an error in that place)

Jonas

Reply by email

Peter Vreman
to Jonas Maebe
Show quoted text 16 lines
On 21 jan 2004, at 19:40, Karl-Michael Schindler wrote: > grepping for SysGetCurrentThreadID did not find anything besides the > above occurence in thread.inc. > However, I found numerous GetCurrentThreadID. > Therefore, I changed SysGetCurrentThreadID to GetCurrentThreadID in > thread.inc and BINGO make cycle went through. > > Comments? Yes, someone obviously made an error when he committed (not just Darwin is broken, almost all of the RTL's are). I think your solution is fine (and even if it's not, I don't think many programs, even multi-threaded ones, will suffer from an error in that place)

Fixed

Reply by email

Karl-Michael Schindler
to Peter Vreman

One more?

in most files I find fpIOCtl, except the following 3 with lowercase o:

rtl/freebsd/termiosproc.inc:  TCGETAttr:=fpIoCtl(Fd,TIOCGETA,@tios);
rtl/linux/termiosproc.inc:  TCGETAttr:=fpIoCtl(Fd,TIOCGETA,@tios);
rtl/netbsd/termiosproc.inc:  TCGETAttr:=fpIoCtl(Fd,TIOCGETA,@tios);

Greetings - Michael

Reply by email

Marco van de Voort
to Karl-Michael Schindler
Show quoted text 7 lines
One more? in most files I find fpIOCtl, except the following 3 with lowercase o: rtl/freebsd/termiosproc.inc: TCGETAttr:=fpIoCtl(Fd,TIOCGETA,@tios); rtl/linux/termiosproc.inc: TCGETAttr:=fpIoCtl(Fd,TIOCGETA,@tios); rtl/netbsd/termiosproc.inc: TCGETAttr:=fpIoCtl(Fd,TIOCGETA,@tios);

Termio is scheduled for an update anyway. ( better Posix compliance prototypes), and I'll fix this then too.

Reply by email

Unknown author
to Karl-Michael Schindler: When making the rtl under and for darwin I get the following error: Compiling…

From: "Karl-Michael Schindler"
To:

Subject: [fpc-devel]thread.inc
Date sent: 21.1.2004 - 20:01:05

Show quoted text 18 lines
When making the rtl under and for darwin I get the following error: Compiling ../unix/systhrds.pp thread.inc(34,21) Error: Identifier not found "SysGetCurrentThreadID" systhrds.pp(136) Fatal: There were 1 errors compiling module, stopping grepping for SysGetCurrentThreadID did not find anything besides the above occurence in thread.inc. However, I found numerous GetCurrentThreadID. Therefore, I changed SysGetCurrentThreadID to GetCurrentThreadID in thread.inc and BINGO make cycle went through. Comments?

This is a problem I've introduced there probably - I couldn't have tested this part, unfortunately, that's why I didn't spot it. Your change is correct. I'll correct it tomorrow evening in CVS if nobody else from the core team corrects it in the mean time.

Best regards

Tomas

Chces kilo? Tak pripoj kamose pres VOLNY. Vice na http://studentpartner.volny.cz/

Reply by email

Karl-Michael Schindler
to Unknown author

make cycle or make rtl gives

Target OS: Darwin for PowerPC
Compiling ../unix/unix.pp
unix.pp(23,2) Fatal: Can't open include file "systypes.inc" make[1]: *** [unix.ppu] Error 1

including ptypes.inc instead of systypes.inc gives:

Target OS: Darwin for PowerPC
Compiling ../unix/unix.pp
unix.pp(699,63) Error: Incompatible type for arg no. 5: Got "ptimeval", expected "Longint"
unix.pp(701,63) Error: Incompatible type for arg no. 5: Got "ptimeval", expected "Longint"
unix.pp(1533) Fatal: There were 2 errors compiling module, stopping make[1]: *** [unix.ppu] Error 1

Reply by email

Karl-Michael Schindler
to Jonas Maebe

Hi,

I guess, this will mainly be directed to Jonas Maebe

With the MacOS X port available, i played (maybe fooled) around in order to port some of the basic units, such as termio crt video keyboard serial.
I managed to get it compiling by transferring missing definitions of constants and types from netbsd of freebsd versions to termio*.inc files or simply copying missing files from the *bsd folders to the darwin folder. Now to my questions:

Is this actually a sound way to proceed? The problem for me is that I do not know the detailed meaning of all the stuff and therefore, I do not have a real clue, whether this is appropriate at all?

After successful compilation, how can I test the units?

Finally, if this is ok and of any value for the project, how would I submit the files?

Have a nice week - Michael

Reply by email

Jonas Maebe
to Karl-Michael Schindler
Karl-Michael Schindler wrote 11 lines
With the MacOS X port available, i played (maybe fooled) around in order to port some of the basic units, such as termio crt video keyboard serial. I managed to get it compiling by transferring missing definitions of constants and types from netbsd of freebsd versions to termio*.inc files or simply copying missing files from the *bsd folders to the darwin folder. Now to my questions: Is this actually a sound way to proceed? The problem for me is that I do not know the detailed meaning of all the stuff and therefore, I do not have a real clue, whether this is appropriate at all?

In general, yes (because the unix side of Mac OS X comes from *BSD). It's best to double-check with original C-header files from which the include files were derived to see whether it's correct, though (/usr/include/termios.h, /usr/include/sys/termios.h)

After successful compilation, how can I test the units?

Because crt can't be tested automatically (you can make a program that tests whether everything is written in the right place on the screen), you have to do "manual" verifications: try some programs that use these units and check whether the output is correct.

Finally, if this is ok and of any value for the project, how would I submit the files?

Send them to me, and I'll commit them.

Thanks!

Jonas

Reply by email

Peter Vreman
to Jonas Maebe
Show quoted text 26 lines
On 26 jan 2004, at 11:40, Karl-Michael Schindler wrote: > With the MacOS X port available, i played (maybe fooled) around in > order to port some of the basic units, such as termio crt video > keyboard serial. > I managed to get it compiling by transferring missing definitions of > constants and types from netbsd of freebsd versions to termio*.inc > files or simply copying missing files from the *bsd folders to the > darwin folder. Now to my questions: > > Is this actually a sound way to proceed? The problem for me is that I > do not know the detailed meaning of all the stuff and therefore, I do > not have a real clue, whether this is appropriate at all? In general, yes (because the unix side of Mac OS X comes from *BSD). It's best to double-check with original C-header files from which the include files were derived to see whether it's correct, though (/usr/include/termios.h, /usr/include/sys/termios.h) > After successful compilation, how can I test the units? Because crt can't be tested automatically (you can make a program that tests whether everything is written in the right place on the screen), you have to do "manual" verifications: try some programs that use these units and check whether the output is correct.

For some units (e.g. crt) are already (interactive) tests. You can find them in tests/test/unit/<unitname>/

If you have create a new, preferable non-interactive, we can include the test in the testsuite. The only requirement is that it needs to exit with 0 on success and with an other code (normally 1 is used) for failures.

Reply by email

Marco van de Voort
to Karl-Michael Schindler: I guess, this will mainly be directed to Jonas Maebe With the MacOS X port available, i…
Show quoted text 9 lines
I guess, this will mainly be directed to Jonas Maebe With the MacOS X port available, i played (maybe fooled) around in order to port some of the basic units, such as termio crt video keyboard serial. I managed to get it compiling by transferring missing definitions of constants and types from netbsd of freebsd versions to termio*.inc files or simply copying missing files from the *bsd folders to the darwin folder. Now to my questions:

I'm currently redoing termio (and possibly the others too) for the bsd ports. Could you send what you already got to me? I'll then merge it in with my changes, and if possible, move some files to bsd/

Is this actually a sound way to proceed? The problem for me is that I do not know the detailed meaning of all the stuff and therefore, I do not have a real clue, whether this is appropriate at all?

Yes, it is. However only for the FreeBSD parts that have proper libc support. Also be careful with ioctl's.

Luckily Mac OS X is very FreeBSD compatible.

After successful compilation, how can I test the units? Finally, if this is ok and of any value for the project, how would I submit the files?

In general, if it is generic BSD/Unix, to me, if it is Darwin specific to Jonas. I think termio and video can be done generic, I'm not sure about keyboard (since it already differs between BSDs), and I don't know serial well enough. Keyboard and Mouse are not fully debugged for FreeBSD too, e.g. some terminal types have problems.

P.s. it is not a problem if you accidentally send it to the wrong person. It is just a rule of thumb.

Reply by email