[M3devel] [M3commit] CVS Update: cm3

[Dirk Muysers]

That would be relatively easy. libjit offers an excellent infrastructure
for building just in time compilers. On the down-side: Slow program
start and a considerable waste of memory resources. Their code
generator is as good as non-optimised C. An example:
A JIT translator for Oberon.

--------------------------------------------------
From: "Hendrik Boom" <hendrik at topoi.pooq.com>
Sent: Friday, June 08, 2012 4:55 PM
To: "m3devel" <m3devel at elegosoft.com>
Subject: Re: [M3devel] [M3commit] CVS Update: cm3

> 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/f04821ce/attachment-0002.html>