[M3devel] LINUXLIBC6

[Jay K]

Is C-- adequately maintained? I don't think so.
I'm also not super keen on depending on other projects.
We'll see..


Regarding runtime designed for garbage collection... in the interest of simplicity, correctness,
and laziness-ignoring-performance, I'd initially try something like this:

 - don't optimize, or at least make all writes volatile 
   or make everything volatile 
While currently we have some support for the gcc optimizer, and we don't make everything volatile,
we also had a long history of using a lot of volatile. I think nobody but me and possibly Tony
noticed the poor codegen and probably
 
 - form all frames as structs 
  - so that the frame layout can be known by the frontend


We already do something similar to the last, I think.


One of the wierd points here..and I really really really really have to get on and code instead of talk,
is "what our C would look like".
It would look strange.


Consider all the inserted "probes" (I forget what they are called).
Consider as I said that there are no field references from the backend's point of view, just variable + offset + cast.


Anyway..later...


 - Jay



----------------------------------------
> Date: Mon, 21 May 2012 17:10:45 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] LINUXLIBC6
>
> On Mon, May 21, 2012 at 02:43:17PM -0400, Hendrik Boom wrote:
> > On Mon, May 21, 2012 at 07:50:49AM +0000, Jay K wrote:
> > >
> > > Nevermind..I'm not making a clear point..
> >
> > Maybe this point will do:
> >
> > So regardless of whether the production compiler generates machine code
> > or anythine else, it would be possible to have a single, portable
> > interpreter written in C to use as a bootstrap tool to avoid having to
> > bootstrap from machine-dependent machine code whenever installing (or
> > packaging) foor another platform? The build-dependency of the real
> > Modula 3 compiler could then be itself OR the interpreter.
> >
> > And the interpreter could be made to interpret some kind of efficient,
> > intermediate code that is easy to interpret fast. Does the existing
> > codebase have anything that sould be used for this? OR could easily be
> > changed into this?
> >
> > -- hendrik
>
> C--, I believe, is implemented as a compiler for several platforms, and
> also as an interpreter. So generating C-- code would satisfy our
> requirements for a bootstrap. If we want to hook into a run-time
> system that has at least thought seriously about the issues of
> garbage-collection and stack-walking, this might be it. But I don't
> know to what extent these essential features have beein implemented.
>
> OCAML also had an interpreter and compilers to several machine codes.
> This would seem to be a viable mechanism.
>
> I've been using an OCAML-written Algol W compiler using the interpreted
> OCAML implementation, and it still compiles Algol W to C faster than
> the C compiler translates its output code to machine code.
>
> -- hendrik
>
>