I remember mention on this newgroup of C to Lisp compilers, presumably
for Lisp machines. Could anyone give me some information on what
approach they took?
I am interested in the more general case of translating unsafe
languages into safe languages -- safe in the sense not only of
preventing access outside allocated blocks of memory, but also in the
stronger sense of preventing forging of pointers to blocks a function
has never been passed -- and I am wondering if the C to Lisp compilers
went this far. (I've looked at a couple of C interpreters and for
papers in ResearchIndex and found nothing on this subject.)
--
Mark Seaborn
- ········@bigfoot.com - http://www.srcf.ucam.org/~mrs35/ -
A bad tool blames its workman.
Mark Seaborn wrote:
>
> I remember mention on this newgroup of C to Lisp compilers, presumably
> for Lisp machines. Could anyone give me some information on what
> approach they took?
>
> I am interested in the more general case of translating unsafe
> languages into safe languages -- safe in the sense not only of
> preventing access outside allocated blocks of memory, but also in the
> stronger sense of preventing forging of pointers to blocks a function
> has never been passed -- and I am wondering if the C to Lisp compilers
> went this far. (I've looked at a couple of C interpreters and for
> papers in ResearchIndex and found nothing on this subject.)
The Symbolics C compiler represented pointers as (offset obj)
pairs. You could construct these pairs from scratch, which was handy
for converting lisp objects into something C could use, but the
standard range-and-type-checks still applied.
This all worked pretty well for conforming programs, since pointers
to within an array are only valid within that array (and one element
beyond for comparison and arithmetic purposes), you can't compare
pointers to different structures (can't legally compare &a[i] and &b[j],
for instance).
I don't remember what happened if you tried serious typecasting games.
The defsystem added C support to ZMACS as well, so the standard compile-
defun, recompile-changed-definitions etc worked as expected, and
packages worked as well.
I used this compiler for a few days when I was developing a non-GPL-
infected regex library for use at work. It wasn't quite as nice as
developing in lisp, but it was as close as I've ever seen C get.
Michael Parker <·······@pdq.net> writes:
>
> The defsystem added C support to ZMACS as well, so the standard compile-
> defun, recompile-changed-definitions etc worked as expected, and
> packages worked as well.
Does anyone know when the symbolics C compiler was available? It must
have been one of the best *C* development environments of its time I
should think.
Back on topic slightly, I was very disappointed when I discovered that
symbolics had an X server to find that it was just the MIT X server
compiled with the symbolics C compiler (+ device support code,
obviously). I'm not really familiar with MIT X internals, but I
imagine it does horrible things, so the compiler must have been up to
supporting quite a lot of stuff.
--tim
Tim Bradshaw wrote:
>
> Michael Parker <·······@pdq.net> writes:
>
> >
> > The defsystem added C support to ZMACS as well, so the standard compile-
> > defun, recompile-changed-definitions etc worked as expected, and
> > packages worked as well.
>
> Does anyone know when the symbolics C compiler was available? It must
> have been one of the best *C* development environments of its time I
> should think.
>
> Back on topic slightly, I was very disappointed when I discovered that
> symbolics had an X server to find that it was just the MIT X server
> compiled with the symbolics C compiler (+ device support code,
> obviously).
I was aware that this is how the X stuff is implemented, I just assumed
that Symbolics hacked the source wherever any ugly pointer-munging
occurred.
Why were you upset? It may be a lispm, but it certainly supported
numerous languages (fortran, pascal, ada, prolog, ???), some of them
reasonably efficiently. There was a fair bit of fortran numerical
stuff that was run on those machines. I'd be more upset if they
rewrote the X support in CL and missed something. I still have
problems untarring binary files on mine.
Michael Parker <·······@pdq.net> writes:
>
> Why were you upset? It may be a lispm, but it certainly supported
> numerous languages (fortran, pascal, ada, prolog, ???), some of them
> reasonably efficiently. There was a fair bit of fortran numerical
> stuff that was run on those machines. I'd be more upset if they
> rewrote the X support in CL and missed something. I still have
> problems untarring binary files on mine.
Oh I wasn't really upset - I just thought it would be cool if there
had been a Lisp X11 implementation...
I can never get tar to work right, either.
--tim
Tim Bradshaw wrote:
>
> Michael Parker <·······@pdq.net> writes:
>
> >
> > The defsystem added C support to ZMACS as well, so the standard compile-
> > defun, recompile-changed-definitions etc worked as expected, and
> > packages worked as well.
>
> Does anyone know when the symbolics C compiler was available? It must
> have been one of the best *C* development environments of its time I
> should think.
It was pretty decent -- you could incrementally recompile functions and
get the error messages there in the editor like in lisp. They didn't
have a single-stepping debugger that I could find, but like in lisp
it really wasn't needed -- you could trace and step functions. The
only thing that really annoyed me was not being able to usefully call
individual functions from the C listener -- the "Execute C Function"
command assumed that the function it was calling took argc and argv.
I just cranked the Symbolics C system up and compiled a few simple
routines (recursive factorial, sum an array of ints, and sum an array
of chars) and decompiled them -- the factorial and sum of ints seemed
to generate pretty reasonable-looking code to me, but the sum-of-chars
was calling a function to fetch the char. It did work when I called
the sum-of-chars routine on the int array. sizeof(int) was 4, which
I thought was amusing. Forgot to check if the C fact() could handle
overflow to bignums.
Michael Parker <·······@pdq.net> writes:
>
> I just cranked the Symbolics C system up and compiled a few simple
> routines (recursive factorial, sum an array of ints, and sum an array
> of chars) and decompiled them -- the factorial and sum of ints seemed
> to generate pretty reasonable-looking code to me, but the sum-of-chars
> was calling a function to fetch the char. It did work when I called
> the sum-of-chars routine on the int array. sizeof(int) was 4, which
> I thought was amusing. Forgot to check if the C fact() could handle
> overflow to bignums.
Heh. I used it much the same, but I compiled STREAM (I think I had to
hack a couple of things). I forget what the result was but it was
pretty slow compared to a SS2 which was the slowest other machine I
had at the time (:-).
--tim