[M3devel] JIT [WAS: Google Benchmark - anyone interested in an Modula 3 version?]

[Daniel Alejandro Benavides D.]

Hi all:
yes, this sounds very good, there is certainly and ability developed for the Obliq (Abadi Cardelli) obejct calculus (a subset which by itself, called **imp**ç):
http://lucacardelli.name/Topics/TheoryOfObjects/Software.html

http://books.google.com/books?id=4xT3LgCPP5UC&lpg=PP1&pg=PA2#v=onepage&q&f=false

http://books.google.com/books?id=4xT3LgCPP5UC&lpg=PP1&pg=PA3#v=onepage&q&f=false

In last of the above it is referred in first of both of them Obliq and Modula-3 mention **imp**ç Chapter 10 and its typ einference algorithm in [1]

The actual approach to compile in an interpreted abstract machine way is through a machien called ZINC (acronym for Zync is not CAML), see:

http://www.brics.dk/RS/98/55/

or  the its previous version :
http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-429.html

They show the equivalent correspondence between source and  abstract machine using decompilation is small steps.

Both of their authors extend the Object calculus to an concurrent one, see [3] in:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.1159

as for I know the C-- FE is written in CAML, which is interesting, and there is a type inference algorithm implementation in Modula-3 of ML (Lazy ML via a Horn-logic and intermediate representation see [2]) for yet another language (graphical called cube, see [2] or a featured article in Dr Dobb's journal, here:

http://drdobbs.com/article/print?articleId=184409677&siteSectionName=

thesis manuscript here:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.27.1619&rep=rep1&type=pdf

)

So this time I'm happy to be wrong, we can do indeed JIT but we should measure the cost (as for type inference could for **imp**ç run O(n^3) and currently run O(n^5), it might be necessary do decompiling plus naturally compiling and forth inc ase of NetObj, etc

Thanks in advance

[1] T. Zhao, “Type matching and type inference for object-oriented systems,” Purdue University, 2002.
[2] M.-A. Najork, “Programming in three dimensions,” University of Illinois at Urbana-Champaign, 1994.
[3] A. D. Gordon and P. D. Hankin, “A Concurrent Object Calculus: Reduction and Typing,” 1998.



 


--- El lun, 4/7/11, Hendrik Boom <hendrik at topoi.pooq.com> escribió:

> De: Hendrik Boom <hendrik at topoi.pooq.com>
> Asunto: [M3devel] JIT [WAS: Google Benchmark - anyone interested in an Modula 3 version?]
> Para: m3devel at elegosoft.com
> Fecha: lunes, 4 de julio, 2011 08:23
> On Mon, Jul 04, 2011 at 02:51:24AM
> +0100, Daniel Alejandro Benavides D. wrote:
> > Hi all:
> > it
> > would mean to compete in such a way in a super
> computer an alternative
> > to run without garbage collection (not unsafe but
> ESC/Modula-3 RTError
> > and RTCollector disabled but for safe automatically
> collected objects,
> > again if we are strictly speaking of a naive
> implementation algorithm,
> > if parallelization is allowed under recursive or
> nested paradigms we
> > are set to compete too but not absolutely).
> > I mean, given the effort
> > they took to run the compiler and tune it for other
> languages and would
> > get same compiler effort plus ESC modelling to subsume
> the collector
> > for perhaps dynamic scripting like say e.g Obliq, we
> don't want to
> > compete with Obliq, but if we do I guess we can't
> compile JIT
> 
> JIT.
> 
> This is a missing feature in Modula 3 -- it would probably
> need to 
> be implemented as a library, and it would be a huge
> implementatino 
> project.  It would involve writing -- or finding --
> code generators for 
> many maching archtectures, and it would require careful
> integratio with 
> the garbage collector.  Both the data structures built
> by gennerated 
> code and the generated code itself would have to be
> garbage-collectible.
> 
> The JIT coder would have to accept relatively low-level
> instructions and 
> produce in-memory object code.  Ideally, unless you
> use the UNSAFE JIT, 
> it would have to perform suitable static and run-time 
> checking on and in the code it's generating.
> 
> People implementing currently interpreted languages would
> have the 
> option of calling this JIT coder instead.
> 
> I've been tinkering from time to time with bits of code in
> this 
> direction, but it's a huge job.  And, in my opinion,
> LLVM doesn't really 
> do this right.  C-- comes a lot closer, but it isn't a
> JIT.  Maybe 
> something like it could be?
> 
> -- hendrik
>