tih@barsoom.nhh.no (Tom Ivar Helbekkmo) (07/03/90)
Well, guess who's happy now! :-) I've just finished installing DEC Scheme->C (from gatekeeper.dec.com) on my SCO Unix 386 system. At gatekeeper, I found the distribution .tar.Z, and a toolkit (newish) for installing Scheme on 386 systems. I'm sorry I can't remember the name of the person responsible for this great piece of work, (s)he really deserves credit for that one! (I've removed all headers from the shar files, and can't get out of the country with FTP right now.) Anyway, with that toolkit to fix long filenames and things for me, setting up the directory structure and so on was a cinch. Still, a couple of comments. The patch kit says that exception handling is unfinished and might not even work right on 386 systems, and that's right. Anyway, I thought I'd share with you all what was needed in addition. I'm using GCC 1.37.1 as my C compiler, and as usual, I guess the job would have been harder with the Microsoft cc that comes with this system... I'd really like some feedback on this stuff, if you can see anything I should have done different... First, some trifling details: In scinit.c, I had to change <strings.h> into <string.h>. I also added an ETEXT/STACKBASE defining section for SCO, equal to the 386ix one. Next, signal handling. It really didn't take much to get it working, but some changes were needed. The way it first came up, my whole system would hang the *second* time an interrupt happened -- not unusual when porting BSD style applications to System V... :-) Signals have to be reinitialized whenever they're caught. In signal.c, I added a line "signal(sig, sc_trap_handler);" to the very start of sc_trap_handler(), so that it would always set itself up for the next catch. I didn't bother to differentiate between various floating point errors, I just trigger the traceback and let it go at that. That takes care of the SIGFPE -- but there's more out there... In scrt4.sc, there's a signal catcher in scheme. Now, I got hold of this package to *learn* scheme, so I hope what I've done is reasonable... I changed the line: (define (ONSIGNAL2 sig) ((vector-ref signals sig) sig)) ... into ... (define (ONSIGNAL2 sig) (SIGNAL sig (vector-ref signals sig)) ; Set the signal again ((vector-ref signals sig) sig)) ; Now execute the handler Looks to me like this should handle it, and anyway, I can now hit DEL several times during the same 'sci' run without having my system hang for 5 minutes followed by a core dump. :-) Problem is, I've now done this in the scheme part of the code, while I'd really like to have it be conditional, executed this way only for System V boxes. How would I go about that? Finally, here's a little bug I found in the scheme code: If I start sci, and type a floating point number that needs scientific notation, but has an integral mantissa, it gets printed wrong: > 1.1e-7 1.1e-7 > 1.0e-7 1e-07. Note the trailing '.' there, that thing will screw up GCC when it tries to compile C source written by sccomp! For instance, I couldn't compile testchk.sc in the test directory without hand fixing the C source. I found the problem in scrt7.sc, in the definition of FLOAT->CLIST, at the end of which we see (reverse (if (memq #\. clo) clo (cons #\. clo)))) ... which I changed into ... (reverse (if (memq #\. clo) clo (if (memq #\e clo) clo (cons #\. clo)))) The trouble was, that while the code checked for existence of a '.' in what should be a floating point number, it forgot to look for the 'e' used in scientific notation. With that notation, you can't just add a trailing '.' -- in fact, you emphatically shouldn't. Could I have chosen a more efficient way of doing it, though? Whatever else may be or not be, DEC Scheme->C looks great: I've run a couple of benchmarks through it, and as far as I can tell, the compiler is pretty good at what it does. With this thing running behind EMACS, I'd say that developing in an interpreted environment, and then compiling when the code works and you want SPEED is very feasible indeed. Looking forward to lots of fun with scheme! -tih -- Tom Ivar Helbekkmo, NHH, Bergen, Norway. Telephone: +47-5-959205 tih@barsoom.nhh.no, thelbekk@norunit.bitnet, edb_tom@debet.nhh.no