<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=unicode" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.19222"></HEAD>
<BODY style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px"
id=MailContainerBody leftMargin=0 topMargin=0 CanvasTabStop="true"
name="Compose message area">
<DIV><FONT face=Arial>That would be relatively easy. <A
title="http://www.gnu.org/software/dotgnu/libjit-doc/libjit_1.html
CTRL + Click to follow link"
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
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></BODY></HTML>