[M3devel] LINUXLIBC6

Daniel Alejandro Benavides D. dabenavidesd at yahoo.es
Tue May 22 02:47:59 CEST 2012


Hi all: 
none interpreter product I have seen lately, that tries such a way C, I know there was a product of 25+ years called C-terp, but they don't do it anymore.  
I don't think they just tried to debug code and safely execute but execute it safely and prudently fast but none else have seemingly been keen to that, so if they thought was a good idea way before all this, I guess we can try to do that. Seems a good one. Which compiler does that, just C--?
They distributed some gcc freely and had MS VS4 versions and all of that.
Thanks in advance


--- El lun, 21/5/12, Jay K <jay.krell at cornell.edu> escribió:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] LINUXLIBC6
> Para: hendrik at topoi.pooq.com, "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 21 de mayo, 2012 17:50
> 
> 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
> >
> >
>     
>         
>           
>   



More information about the M3devel mailing list