LispOS and C

[Mike McDonald]

>To: lispos@math.gatech.edu (Lisp OS project)
>Subject: Re: LispOS and C
>From: marcus@cathcart.sysc.pdx.edu (Marcus G. Daniels)
>Date: 08 May 1997 18:01:41 -0700
>
>>>>>> "FR" == Fare Rideau <rideau@ens.fr> writes:
>
>FR> Well, in all those cases, they forget something *essential*: the
>FR> memory model of LispOS, with its GC and orthogonal persistent
>FR> store.  Unless the C code is carefully written with just that in
>FR> mind, output by GCC will not comply to to the memory model of
>FR> LispOS, hence be unusable under LispOS, unless a unix/whatever
>FR> emulator is used (which might be the underlying OS, or a OS
>FR> concurrently running on the same microkernel, or a full-fledged
>FR> emulation box written for LispOS).
>
>I'm talking about a feature I'd like to have: GCC working on LispOS.
>I think it would be cool to be able to browse around in a Lisp
>environment looking at who malloced what.
>
>It seems to me GCC would need to output some instruction set that can
>be assembled by LispOS.  The rest of Unix is implemented in C by GNU.

  I haven't looked at GCC in a while so maybe my data is out of date
but at one time, GCC used an abstract register machine as its
intermediate target. The instructions generated by the front end were
a bunch of tuples for this abstract machine. Why couldn't one take
this abstract machine and implement an emulator for it? Isn't that
essentially what the LispVM guys are doing with Lisp? Oh, the RTL used
to get printed out with lots of parantheses too. It woudln't give you
the fastest running C code but it would run. And I'd guess for the
vast majority of C programs, speed isn't that big of a deal.

>FR> If you think such problems are trivial, you are invited to write
>FR> the GC and persistent store...
>
>One case is that the resources a C program allocates are not garbage
>collected at all until that program exists -- but Unix is already like that.
>

  Mike McDonald
  mikemac@engr.sgi.com