Over the past few days I've been Googling away looking for either
a scheme or CL native compiler implementation that would not
use *any* C "kernel". In Scheme land, all of the few schemes
that are actually compilers
http://community.schemewiki.org/?scheme-faq-standards#implementations
are using C. In CL land, both Clozure MCL and SBCL use some sort
of C kernel.
I fail to see the reason why this is so, as it seems that it used
to be the case that some implementations (T, NIL) had been written
that way?
To make it clear, what I'm looking for is the source code of
an implementation written in some lisp dialect that:
- uses lisp to write a "bootstrap executable" file in whatever
native format the host OS supports (ELF, Mach-o, exe/dll ...)
- runs that bootstrap and augments is with the whole missing
shebang so as to reach a miniumn level of usability. I'm not
bothered if "full standard compliance" is not reached, but I
really am interested in the low level stuff, written in Lisp,
from GC, to thread support, to code generation. Using the native
underlying platform's thread (POSIX?) is OK, but *having to*
invoke some sort of C compiler at any point during any of the
two phases above is a non starter.
I'm really interested in looking at the source code of such "lisp
all the way down" native compiler implementation. Anyone could
direct me to such an elusive beast? :-)
Many Thanks
--
JFB
verec <·····@mac.com> wrote:
+---------------
| Over the past few days I've been Googling away looking for either
| a scheme or CL native compiler implementation that would not
| use *any* C "kernel". ... what I'm looking for is the source code
| of an implementation written in some lisp dialect that:
| - uses lisp to write a "bootstrap executable" file in whatever
| native format the host OS supports (ELF, Mach-o, exe/dll ...)
| - runs that bootstrap and augments is with the whole missing
| shebang so as to reach a miniumn level of usability.
+---------------
Have a look at this paper:
http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf
"An Incremental Approach to Compiler Construction"
Abdulaziz Ghuloum
2006 Scheme and Functional Programming Workshop
He incrementally develops a compiler from Scheme to x86 assembler,
and in "24 small steps" ends up with "a compiler powerful enough
to compile an interactive evaluator". [Which, if you fed it the
source of the compiler...]
He does peripherally use a C compiler, but only as a tool to
see what assembler code given sample bits of C generate --
esepcially subroutine calling sequences -- thus avoiding having
to actually *learn* x86 assembler! ;-}
And he does use a 3-line C program as the top-level "main()"
to call his compiled programs. But one could eliminate *that*
as well by running "gcc -S" on it once, and then just cloning
the assembler for "main()" into each program compiled.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
verec <·····@mac.com> writes:
> Over the past few days I've been Googling away looking for either
> a scheme or CL native compiler implementation that would not
> use *any* C "kernel". In Scheme land, all of the few schemes
> that are actually compilers
> http://community.schemewiki.org/?scheme-faq-standards#implementations
> are using C. In CL land, both Clozure MCL and SBCL use some sort
> of C kernel.
>
> I fail to see the reason why this is so, as it seems that it used
> to be the case that some implementations (T, NIL) had been written
> that way?
The reason is simple. All these lisp implementations work on a POSIX
system, most of them on a unix system. The few lines of C they
incorporate are the glue between the lisp world and the POSIX world.
That glue could be written in assembler but this would be less
portable than C. These implementations don't target a given
processor, but a given virtual machine: the POSIX (or unix) virtual
machine.
Now, I can guarantee you 100% that ABCL or CLforJava use 0 line of C
code. Since they target the JVM, they may use a few java lines to
glue to the underlying virtual machine.
And to make it perfectly clear, the Zeta-C compiler used also 0 line
of C code, but used a few lines of Lisp, to glue to its target virtual
machine, namely the Lisp Machine!
On the other hand, Movitz targets the bare ix86 processor, and
therefore contains absolutely no C code. Since it targets only one
processor, it can translate the little glue it needs directly from
lisp to binary.
> To make it clear, what I'm looking for is the source code of
> an implementation written in some lisp dialect that:
> - uses lisp to write a "bootstrap executable" file in whatever
> native format the host OS supports (ELF, Mach-o, exe/dll ...)
> - runs that bootstrap and augments is with the whole missing
> shebang so as to reach a miniumn level of usability. I'm not
> bothered if "full standard compliance" is not reached, but I
> really am interested in the low level stuff, written in Lisp,
> from GC, to thread support, to code generation. Using the native
> underlying platform's thread (POSIX?) is OK, but *having to*
> invoke some sort of C compiler at any point during any of the
> two phases above is a non starter.
You have to have code implementing the glue between your lisp
implementation and the underlying virtual machine. You can write this
code in lisp, but if this underlying virtual machine is defined in
terms of C, ie. if it is POSIX or unix, then you will have to
implement compilers for the (subset of) lisp you used to implement
this glue targetting all the targets of POSIX or unix. That's a lot
of work. It's smarter to translate this Lisp into C, and let the
POSIX or unix virtual machine do its job of pre-targetting to its
underlying virtual machine (the various OS POSIX is implemented on, or
the various processors unix is implemented on).
> I'm really interested in looking at the source code of such "lisp
> all the way down" native compiler implementation. Anyone could
> direct me to such an elusive beast? :-)
Movitz http://common-lisp.net/project/movitz/
LispMachine http://www.unlambda.com/cadr
--
__Pascal Bourguignon__ http://www.informatimago.com/
CONSUMER NOTICE: Because of the "uncertainty principle," it is
impossible for the consumer to simultaneously know both the precise
location and velocity of this product.
On Jul 26, 3:25 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> And to make it perfectly clear, the Zeta-C compiler used also 0 line
> of C code, but used a few lines of Lisp, to glue to its target virtual
> machine, namely the Lisp Machine!
I'm afraid this is not correct. Zeta-C used a YACC-generated parser,
in C, along with a hand-coded lexer, also in C.
(Yes, I'm the author.)
-- Scott
Scott Burson <········@gmail.com> writes:
> On Jul 26, 3:25 am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
>> And to make it perfectly clear, the Zeta-C compiler used also 0 line
>> of C code, but used a few lines of Lisp, to glue to its target virtual
>> machine, namely the Lisp Machine!
>
> I'm afraid this is not correct. Zeta-C used a YACC-generated parser,
> in C, along with a hand-coded lexer, also in C.
>
> (Yes, I'm the author.)
Sorry, I just guessed wrong about Zeta-C :-)
So you did you write a bootstrapping C interpreter or compiler in
Lisp, or did you do the bootstrapping on another system?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Small brave carnivores
Kill pine cones and mosquitoes
Fear vacuum cleaner
On Jul 27, 4:19 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
>
> So you did you write a bootstrapping C interpreter or compiler in
> Lisp, or did you do the bootstrapping on another system?
I wrote a nano-Lisp in C -- just implementing symbols, strings,
numbers, `cons', and `print'; no GC. This was just enough to run the
actions in the YACC-generated parser and print the tree out as s-
expressions. Then I linked the lexer and parser with this nano-Lisp
and used the resulting executable to parse the lexer and parser source
and convert them to s-expression form, whereupon I could load them
into Lisp and compile them.
-- Scott
v> I'm really interested in looking at the source code of such "lisp
v> all the way down" native compiler implementation.
i really wonder why do you need this. C part (in compiler implementations)
is typically some boring
glue code that is just easier to write in C (because you get some
portability
for free). it can be converted to pure Lisp, but it would be equally boring,
just
larger and platform-specific.
JFB wrote:
> In Scheme land, all of the few schemes
> that are actually compilers
> http://community.schemewiki.org/?scheme-faq-standards#implementations
> are using C.
For what it's worth, that's not true. Common Larceny
does not execute a single line of C code (it uses C#
for its glue code instead), and I suspect that the
JVM-based compilers don't use any C code either.
Many JVMs and CLR-compatible runtimes are written in
C, of course, but that's transparent to the Scheme or
Lisp system. By the time they get around to using
the JVM or CLR, all that C code has been translated
to machine language, just like the code executed by
the host OS, ELF, Mach-o, and exe/dll you mentioned.
Although a Scheme-only or Lisp-only implementation is
feasible, it's so pointless as to be rare. There do
exist at least three Scheme compilers that compile
directly to machine code without going through C and
using a compiler written entirely in Scheme: Chez
Scheme, native Larceny, and Ikarus. Ikarus contains
about 7000 lines of C code in its runtime system, and
Larceny's runtime contains about 21000.
The source code for Ikarus and Larceny is open to the
public, so you are free to study their "all the way
down" native compilers [1,2]
Will
[1] http://www.cs.indiana.edu/~aghuloum/ikarus/
[2] https://trac.ccs.neu.edu/trac/larceny
On Jul 26, 1:36 am, verec <·····@mac.com> wrote:
>
> I'm really interested in looking at the source code of such "lisp
> all the way down" native compiler implementation. Anyone could
> direct me to such an elusive beast? :-)
The T sources are available at Jonathan Rees' site:
http://mumble.net/~jar/tproject/index.html
Alas, they're not well commented.
-- Scott