[Ecls-list] Porting CL to new platforms: what can be reused?

[Christian Schafmeister]

Anton,

I've just managed to host much of the ECL Common Lisp code on a C++ core that was built completely from scratch.
I just got ECL-CLOS and generic function dispatching to compile and run a few days ago.
I've exposed the LLVM C++ library to Common Lisp and written a new self-hosting compiler in CL.
I also wrote an S-expression walking CL interpreter to bootstrap the compiler.

It's taken me about a year working about 8 hours a day.  It's my first time and I have no previous experience with Common Lisp.

Juanjo is absolutely correct, it's the interactions of the CL code with the lower level code that require a lot of time to implement properly. 
This involves a lot of implementation dependent stuff that are not described in the CL standard.

When I started seriously trying to host the ECL code I had Juanjo's excellent ECL C-code to help me understand what the low-level functionality did. 

Also, very important details like lexical environments are not described at all well in the CL standard and you need to do a lot of code refactoring to get something that works properly in the end.

Also, tracking down subtle bugs that I introduced because I didn't exactly implement standard Common Lisp behavior the first, second or third time around has taken a lot of my time.

Best,

.Chris.



On Apr 18, 2013, at 9:10 AM, Juan Jose Garcia-Ripoll <juanjose.garciaripoll at gmail.com> wrote:

> 
> On Wed, Apr 17, 2013 at 9:55 PM, Anton Vodonosov <avodonosov at yandex.ru> wrote:
> In theory CL core consists of 25 special operators + build-in data types. Everything else
> is a library. So when porting to a new platform, theoretically, all we need to reimplement
> is a compiler understanding 25 operators + some build-in functions representing datatypes
> (make-array, aref, cons, etc) and some basic reader, allowing to read the source code of the library.
> 
> That is indeed the theory. In practice much of the library deals with operating system stuff: memory allocation, files, etc. That forces a low level implementation of several core structures. Moreover, several functions are critical for performance and are also hard-coded to make bootstrapping faster.
>  
> How close this theoretical view to practice? We now have several open-source CL implementations.
> If one wants to create a Javascript port, what else he must be prepared to solve?
> 
> ECL is pretty well isolated: the C library works like the lisp API and offers a number of functions that one may start with. Many of those functions could _nowadays_ be ported back to Common Lisp, using the fact that the compiler is more efficient. But there are critical things, such as the filesystem, running processes, or I/O operations, that would be hard to implement from scratch.
> 
> Perhaps Christian could comment, given that he is using the ECL Common Lisp base to implement a LLVM-based Common Lisp implementation
> 
> Juanjo
> 
> -- 
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain) 
> http://juanjose.garciaripoll.googlepages.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20130503/e49975e8/attachment.html>