<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>Olivetti M3 had one AST-based interpreter, Vulcan was AST-based environment I don't know which was better. Vulcan was heavily parallelized could be nice to make a Multi-Threaded Execution Engine. Olivetti M3 AST tk could be mostly like a good AST for doing extensible kind of meta-environment (and you could retarget C) so for instance use it to generate a portable environment in that sense and then execute it to on fast Vulcan parallel make fast JIT builder<br>Thanks in advance<br><br><br>--- El <b>vie, 8/6/12, Dirk Muysers <i><dmuysers@hotmail.com></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Dirk Muysers <dmuysers@hotmail.com><br>Asunto: Re: [M3devel] [M3commit] CVS Update: cm3<br>Para: "Hendrik Boom" <hendrik@topoi.pooq.com>, "m3devel"
<m3devel@elegosoft.com><br>Fecha: viernes, 8 de junio, 2012 10:37<br><br><div id="yiv471590332">
<div>
<div><font face="Arial">That would be relatively easy. <a rel="nofollow" title="http://www.gnu.org/software/dotgnu/libjit-doc/libjit_1.html
CTRL + Click to follow link" target="_blank" href="http://www.gnu.org/software/dotgnu/libjit-doc/libjit_1.html">libjit</a>
offers an excellent infrastructure</font></div>
<div><font face="Arial">for building just in time compilers. On the down-side:
Slow program</font></div>
<div><font face="Arial">start and a considerable waste of memory resources. Their
code</font></div>
<div><font face="Arial">generator is as good as non-optimised C. An
example:</font></div>
<div><font face="Arial"><a rel="nofollow" target="_blank" href="http://peterdn.com/files/A_JIT_Translator_for_Oberon.pdf">A JIT translator
for
Oberon</a>.<br></font><br>--------------------------------------------------<br>From:
"Hendrik Boom" <hendrik@topoi.pooq.com><br>Sent: Friday, June 08, 2012
4:55 PM<br>To: "m3devel" <m3devel@elegosoft.com><br>Subject: Re: [M3devel]
[M3commit] CVS Update: cm3<br><br>> On Fri, Jun 08, 2012 at 02:13:02AM +0000,
Jay K wrote:<br>>> <br>>> > I'd like to, if I only knew
how. I'd be really interested in having the<br>>> >
low-level infrastructure for JIT code generators<br>>> Would you be
satisfied with a Modula-3 interpreter that interpreted a <br>>>
mostly-compiled form?It shouldn't be difficult.<br>> <br>> That would be
lovely, for all the reasons and opportunitied you <br>> mentioned, but it's
mostly orthogonal to what I want.<br>> <br>> I want to write JIT
implementations for other languages, languages that <br>> have their own
methods for defining data structures, but I want them to <br>> be
interoperable with the Modula 3 I know and like.<br>> <br>> I don't mind
writing a code generator or two, if necessary. But an <br>> interpreter
would provide poratbility instead of efficiency. Having <br>> both
could be useful.<br>> <br>> For example, I'd like to implement a formalism
that enables me to <br>> download code from the net, formally verify its
safety and then be able <br>> to execute it really fast. Yes, I might
be comiling it all at once <br>> instead of a line at at time, but I do want
to be able to add it to an <br>> existing running program, and saying "JIT"
is about the easiest brief <br>> summary.<br>> <br>> I'm quite aware
that doing more than a half-assed version of this would <br>> be a big
project, and that's probably an understatement.<br>> <br>>> I
don't know if our intermediate code was designed with interpretation
<br>>> in mind, but it seems like it wouldn't be particularly difficult.
<br>>> You'd want a "linker" that just zips all the files and puts it "in"
or <br>>> "next to" the stub executable. This would solve the
distribution <br>>> format problem, partly.The existing intermediate code
is <br>>> platform-specific, but not by much (again: jumpbuf size, word
size, <br>>> endian,win32 vs. posix).<br>> <br>>> But I have to
admit, I'm keener on generating C than a JIT or an <br>>> interpreter, and
interpreter is not JIT.<br>>> Um. What do you hope to gain from
JIT?<br>> <br>> The ability to dynamically add code to an existing program
and have it <br>> run fast. Possibly to have the program generate
additional code to add <br>> to itself.<br>> <br>>> A big reason I
ask..is <br>>> because..well, do you want to ship some portable-executable
that <br>>> relieson JIT being already installed/available? Or do you want
to <br>>> carry the JITer and its code together?Or do you want to target
an <br>>> existing widely deployed JITer such as CLR or Java? In my
opinion, <br>>> the biggest advantage of JIT is portable-executable,
depending on <br>>> widely deployed JITer.But targeting CLR or Java isn't
as easy as <br>>> targeting your own custom thing. I understand
there are other <br>>> advantages -- faster compilation, optimization very
specific to <br>>> runtime environment.But I think portable-executable is
most important. <br>>> That's why I like "script". :)There are
disadvantages to JIT: slower <br>>> execution/startup, maybe harder to
debug, easy to reverse engineer (if <br>>> you care). Heck, at some
point you just ship the compiler and <br>>> portable-executable is source
code.There are pluses and minuses all <br>>> around.<br>> <br>> JIT
is for speed. Otherwise, interpretation would suffice, and could <br>>
even be portbale. But even an interpreter would like to be able to add
<br>> new garbage-collectible types, which is what I'm asking for at the
<br>> moment.<br>> <br>> -
Jay <br>></div></div></div></blockquote></td></tr></table>