[M3devel] [M3commit] CVS Update: cm3

[Daniel Alejandro Benavides D.]

Hi all:
interesting someone did that (see others in web search engine):
http://compilers.iecc.com/comparch/article/98-03-247

Besides a partial JVM.
It would be a selling point for CM3 to be readily implemented and efficient.
Thanks in advance


--- El vie, 8/6/12, Hendrik Boom <hendrik at topoi.pooq.com> escribió:

De: Hendrik Boom <hendrik at topoi.pooq.com>
Asunto: Re: [M3devel] [M3commit] CVS Update: cm3
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 8 de junio, 2012 09:55

On Fri, Jun 08, 2012 at 02:13:02AM +0000, Jay K wrote:
> 
>  > I'd like to, if I only knew how.  I'd be really interested in having the
>  > low-level infrastructure for JIT code generators
>  Would you be satisfied with a Modula-3 interpreter that interpreted a 
> mostly-compiled form?It shouldn't be difficult.

That would be lovely, for all the reasons and opportunitied you 
mentioned, but it's mostly orthogonal to what I want.

I want to write JIT implementations for other languages, languages that 
have their own methods for defining data structures, but I want them to 
be interoperable with the Modula 3 I know and like.

I don't mind writing a code generator or two, if necessary.  But an 
interpreter would provide poratbility instead of efficiency.  Having 
both could be useful.

For example, I'd like to implement a formalism that enables me to 
download code from the net, formally verify its safety and then be able 
to execute it really fast.  Yes, I might be comiling it all at once 
instead of a line at at time, but I do want to be able to add it to an 
existing running program, and saying "JIT" is about the easiest brief 
summary.

I'm quite aware that doing more than a half-assed version of this would 
be a big project, and that's probably an understatement.
  
> I don't know if our intermediate code was designed with interpretation 
> in mind, but it seems like it wouldn't be particularly difficult. 
> You'd want a "linker" that just zips all the files and puts it "in" or 
> "next to" the stub executable.  This would solve the distribution 
> format problem, partly.The existing intermediate code is 
> platform-specific, but not by much (again: jumpbuf size, word size, 
> endian,win32 vs. posix).

> But I have to admit, I'm keener on generating C than a JIT or an 
> interpreter, and interpreter is not JIT.
>  Um. What do you hope to gain from JIT?

The ability to dynamically add code to an existing program and have it 
run fast.  Possibly to have the program generate additional code to add 
to itself.

> A big reason I ask..is 
> because..well, do you want to ship some portable-executable that 
> relieson JIT being already installed/available? Or do you want to 
> carry the JITer and its code together?Or do you want to target an 
> existing widely deployed JITer such as CLR or Java?  In my opinion, 
> the biggest advantage of JIT is portable-executable, depending on 
> widely deployed JITer.But targeting CLR or Java isn't as easy as 
> targeting your own custom thing.  I understand there are other 
> advantages -- faster compilation, optimization very specific to 
> runtime environment.But I think portable-executable is most important. 
> That's why I like "script". :)There are disadvantages to JIT: slower 
> execution/startup, maybe harder to debug, easy to reverse engineer (if 
> you care).  Heck, at some point you just ship the compiler and 
> portable-executable is source code.There are pluses and minuses all 
> around.

JIT is for speed.  Otherwise, interpretation would suffice, and could 
even be portbale.  But even an interpreter would like to be able to add 
new garbage-collectible types, which is what I'm asking for at the 
moment.

    - Jay                           
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120608/41f82938/attachment-0002.html>