[epsilon-devel] Next steps for Mes, stage0+? -- Re: You missed my later work

[Jan Nieuwenhuizen]

>> Thanks for the pointers!  I just released Mes 0.5, which is now fully
>> self hosting.  We would need to investigate.  However, if we restrict
>> the boostrapping path to either Mes or stage0+Mes, how could this help?
>
> The idea is to make a sub-C compiler that supports only enough of the C
> language required to bootstrap your MES, which I then could hand convert
> to assembly and thus solve your lower bootstrapping problem.

Ah, and this is what you would need a separate cpp for?

>> Compiling tcc is near the top of my priority list -- just below
>> releasing Mes 0.5 (done) and discussing the next step (doing that now).
>> So if nothing changes, I'll be working to compile tcc, any help or
>> insights to make that easier are much appreciated.
>
> Use the tests included in tcc, as once you can compile all of them your
> compiler should support everything required to compile tcc.

Thanks for the pointer, I missed that.  I have looked into that
yesterday.  There are 55 tests and Mes has two obvious reasons why none
of them work: we need to supply some headers <stdio.h>, <string.h>, and
they are using printf in all tests.

I am curious to see how far Mes will get :-)

>> Posibly.  Christopher Webber mentioned PreScheme to me so I guess he's
>> a fan.  Mes is currently prototyped in C, if we could move that to
>> [Pre]Scheme that would be great!
>>
>> However, my first priority is to close the bootstrap loop, i.e. get
>> either GCC or Guile compiled from what's Mes now. 
>
> Absolutely agreed. And in the mean time, I'll be making tools to help
> your bootstrap become ever easier. I'm looking at following the C
> evolutionary path and implementing the META II compiler compiler and a
> couple similiar tools.

It's good to hear my plan makes sense to you (see below).  What's the
META II compiler compiler?

>> The one thing holding me back to attempt glueing your stage-N LISP to
>> Mes is performance (and well, being terribly busy working to release Mes
>> :-).  Currently mescc takes 2h30' to compile itself.  Compiling tcc is
>> still a lot of work and is 10x as big...
>>
>> I fear that running mes on stage-N's LISP adds another 2 factors of
>> perfomance penalty...
>
> How about an easier problem? If your mes was written in lisp, why not
> write a lisp compiler capable of compiling the lisp and thus solving the
> performance problem.

Indeed, that would be great!  Writing mes.c in Scheme fairly easy of
course; I've done almost that a couple of times already.  Being able to
compile [some] Scheme to native code would be very nice in itself too,
not just for bootstrapping.

> As once an interpreter is made, you are already 30% done writing a
> working compiler.

I was hoping for that, I still need some inspiration here.

>> It seems you're asking all the right questions...THANK!  However,
>> although this full source bootstrapping endeavor has been a lot of fun
>> until now, one of the biggest difficulties has been to reduce the number
>> of open questions...almost anything seems possible.  So I was hoping to
>> get more answers and all I get is more questions ;-)
>
> How is this for some answers.

Yes, thanks a lot!  When I started Mes it looked like an almost
impossible task and what needs to be done can still look daunting.
Questions are great, but some balancing with answers is very helpful.

> We are not smarter than all of the great minds of computer science that
> have used teams of hundreds to create the foundation of tools upon which
> we now stand.
>
> But we have something they didn't... The answers of what worked well.

Yes, I see.  That's the knowledge that must somehow regain.  It's
probably a good thing that not everything works well :-)

> From that I assert that the correct course of action for us is the
> following:
> Build simple, easy and fun tools that simplify the task of solving the
> problem.

Check!

> Your lisp interpreter, actually is closer to becoming a lisp compiler
> than mine is. Should that interest you, it would solve your performance
> problems.

Hmm...It would make sense to write this lisp compiler in lisp, of
course.  No need to write it in C.  Hmm.  I wonder if someone would want
to help transforming the mes.c interpreter into a mes.scm compiler?

> Thank you as always,

Greetings,
janneke

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl