[M3devel] [M3commit] CVS Update: cm3

[Daniel Alejandro Benavides D.]

Hi all:
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
Thanks in advance


--- El vie, 8/6/12, Dirk Muysers <dmuysers at hotmail.com> escribió:

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



 

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