Re: [Gcl-devel] GCL as gcc front end?

[Louis Glassy]

If you wanted to do this - integrate GCL with gcc - I think it would 
possible, though very difficult.  You would probably want to talk with 
others who've been down that road - like Craig Burley (former G77 guy),
Robert Dewar (Gnu-Ada guy), as well as the current gcj people.

(setf mostly-just-my-opinion-mode t)

Many people have tried to port new languages into the gcc framework.
Few have succeeded.

* Gnu Pascal (last I checked, early 2001) still emits assembly, uses
  'gas' to assemble it, but does not use the rest of the gcc backend.

* The Gnu Modula2 project has never gotten a gcc backend.  My understanding
  is that it was the undocumented-ness of gcc's backend that pretty much 
  stalled them (years ago).

* ACT did get Ada to talk to the gcc backend, and this took modifying
  the backend a lot, since Ada supports things that a C-ish world
  can't understand.  This work was done by several programmers working
  full-time on it for quite a while.

* Gnu Fortran took a long time to get the backend integration with gcc
  working, too.  In this case, I think the problem is that the backend 
  needed to be enhanced to handle optimizations a normal Fortran compiler
  would do (but that a normal C compiler would not do, because of aliasing).

Getting GCL to emit native machine code using gcc's backend looks 
attractive, but ...

[1] Java's requirements and CL's for the back-end are different
    enough that I think reusing much (if any) of gcj's runtime
    would not work.  For example: lambda - Java has no equivalent,
    since functions are not first-class citizens in the language.

    Not java-related, but another example of gcc-backend semantic
    mismatch: bignums (and arithmetic, generally).  The gcc backend
    has a verrrrry sloppy idea of how to arithmetic, and doesn't
    support any kind of arithmetic that isn't native to the underlying
    hardware.  gcj basically ignores this, so its arithmetic is fast
    but WRONG, in that it isn't java-compliant.  Throw in the rest of
    the numeric tower (complexes, ratios) and you'll see the gcc
    backend could be made to do all these things - but not without a
    LOT of work.

[2] (IMHO) gcc's backend was never really designed with non-C-like
    languages in mind.  The amount of work it took to get Ada to use
    the gcc backend was pretty lengthy (several man-years of effort?).
    And Ada is closer to C, semantically, than CL is...

[3] From the new-language-integrator's standpoint, gcc's backend is
    mostly undocumented.  Suppose you look at the backend as: [a]
    getting your parse tree into RTL [b] taking RTL to object code.
    There's a copious supply of info files documenting *something* to
    do with [b], but what's undocumented is how you do [a].  There is
    a blob of info documentation on the middle part of the backend
    (how to talk RTL - "register transfer language" - gcc's
    intermediate representation).  What goes on below that -
    converting RTL into assembly or object code - is pretty standard
    from one language to another, from what I've heard.

Caveat: I know almost nothing about the gcc backend - what little I
know, is from what I've heard from others over the years.  But I'm
thinking you would REALLY want to talk with someone who knows what
they're talking about, before undertaking a GCL/gcc integration.  :-)

I think it would *GREAT* if GCL could compile to machine-code.  It's
just the amount of work it would take, that leaves me doubtful...

[...you wrote...]

   From: Camm Maguire <address@hidden>
   Sender: address@hidden
   Date: 19 Jun 2002 17:51:08 -0400


   Greetings!  I've recently been appointed by RMS to maintain gcl, the
   official GNU Common Lisp.  I was wondering about the prospects of
   eventually including gcl as a supported front-end to the gcc suite of
   compilers.  After all, gcj is there, and it has garbage collection,
   and a runtime required (I think) too.  What would it take?  As a
   *very* long term goal, that is?
[...]

-- 
Lou Glassy (address@hidden)