[Ecls-list] Patch: FTYPE proclamations with DEFTYPE'd types.
Juan Jose Garcia-Ripoll
juanjose.garciaripoll at googlemail.com
Sun Sep 14 00:09:38 UTC 2008
On Sat, Sep 13, 2008 at 2:23 AM, Gabriel Dos Reis <
gdr at integrable-solutions.net> wrote:
> However, I realize that ECL reports 8.9.0 as version, when previously
> it said 0.9l. I was under the impression that you did not want to
> release 1.0 before the compiler is stable. How should I interpret
> the new version?
Well, I have become a bit fed up with the old compiler. It does the job
pretty well, but it is a mess to maintain, it is not very flexible and it
duplicates the effort that I want to put into the bytecodes compiler, which
currently, together with the library, is the most stable component in ECL.
Besides that, one sometimes needs an additional motivation to keep working,
so I have decided to put the old compiler in pure maintainance mode and find
me a more interesting task, which is to write a compiler from scratch.
As I have it in mind, this is going to be an incremental task. First born as
a new frontend to the bytecodes system, it should coexist with it. It is
going to be developed solely in lisp, though I do not discard a translation
to C for stability and self-bootstrapping. The design should be based on two
layers: a lisp -> SSA translation and two SSA -> anything backends, one for
bytecodes and one for C. All in all, the library should remain the same and
that is already more than 90% of the code.
SSA stands for static single assignment and it is something that I
accidentally discovered by reading the LLVM manual and similar literature
(*) It is really what the current lisp->C translator should have had from
scratch, for it makes it so much easier to do type propagation and discovery
of the actual representation of objects, as well as experimenting with
different backends and doing unit testing of the different layers of the
translator.
Also, SSA is well suited for doing lifetime analysis and register
allocation, which is what the current bytecodes compiler is desperately
missing. And finally, if we have an SSA frontent, perhaps some adventurous
guy (not me) would find it easy enough to emit LLVM internal representation
and thus get both an optimizing compiler and a JIT engine.
Anyway, this is currently my pet project. I guess it is going to take 10
times the time that it would take if I did not have a real life, a job and a
mortgage to pay, but as I said before, one needs more than just polishing
corners of something that already works pretty well (the interpreter and
library) or trying to stretch something which is too limited by design (the
current lisp->C translator)
And this is also the reason why I stopped thinking about 1.0 versions this
week.
Juanjo
(*) Please bear in mind I am no Computer Scientist, and I am just finding
out things 20 years later :-)
--
Instituto de Física Fundamental
CSIC, Serrano, 113, Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20080914/df578d95/attachment.html>
More information about the ecl-devel
mailing list