gnu@hoptoad.uucp (John Gilmore) (06/01/89)
I have been working on making the whole BSD Unix system compile under
gcc (the GNU C compiler). UCB intends to use gcc as "cc" in future BSD
releases, though the old pcc compiler will still be around somewhere.
One big stumbling block is Franz Lisp, which is rife with machine- and
compiler-dependencies. Rather than replace these fragile dependencies
with different fragile dependencies, I have been removing them, making
the code more portable.
After a few days' work, I have the Lisp interpreter compiling with gcc
and pcc (and presumably any other C compiler). There are a few loose
ends to smooth out but it's basically there. However, the Lisp
compiler is another matter; it seems to have lots more buried
assumptions about how various C language "global variables" (the stack
pointers) have magically been put into global machine registers.
It looks like this is turning into a bigger effort than I and Berkeley
can support. Two questions: Does anyone care if Franz Lisp moves into
/usr/old and is desupported in BSD releases? And, is there anyone who
wants to take on the Lisp compiler conversion themselves?
--
John Gilmore {sun,pacbell,uunet,pyramid,amdahl}!hoptoad!gnu gnu@toad.com
A well-regulated militia, being necessary to the security of a free State,
the right of the people to keep and bear arms, shall not be infringed.jeff@aiai.ed.ac.uk (Jeff Dalton) (06/02/89)
In article <7487@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >the Lisp compiler is another matter; it seems to have lots more buried >assumptions about how various C language "global variables" (the stack >pointers) have magically been put into global machine registers. Is this true for every target machine? I know that the VAX version assumes that, but I'm pretty sure the 68k one doesn't. Indeed, I think it has a switch that lets you say whether C register hacks have been applied or not. How many different machine architectures have to be supported these days? Is it supposed to work on the Tahoe? >It looks like this is turning into a bigger effort than I and Berkeley >can support. Two questions: Does anyone care if Franz Lisp moves into >/usr/old and is desupported in BSD releases? And, is there anyone who >wants to take on the Lisp compiler conversion themselves? I guess I would like to see Franz supported, but I don't think it's so important now as it was in the past. Jeff Dalton, JANET: J.Dalton@uk.ac.ed AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
cox@ucbarpa.Berkeley.EDU (Charles A. Cox) (06/08/89)
In article <517@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes: >In article <7487@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >>It looks like this is turning into a bigger effort than I and Berkeley >>can support. Two questions: Does anyone care if Franz Lisp moves into >>/usr/old and is desupported in BSD releases? And, is there anyone who >>wants to take on the Lisp compiler conversion themselves? > >I guess I would like to see Franz supported, but I don't think it's >so important now as it was in the past. Just to make sure there's no confusion, this discussion is about the old Opus 38 Franz Lisp available with UNIX BSD distributions. Newer versions of Franz Lisp (currently Opus 43) are supported and available from Franz Inc. (ask info@franz.com for more information). Charley Cox cox@Berkeley.EDU