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

Tue Jul 5 01:58:28 CEST 2011

Hi all:
later, Dr Xavier Leroy developed a type-theoretical modular module system for "core-ML" and "small-C" or "core-C".
He mentions important influence of Cardelli's Quest (a super set of Girard Fw) language machine on it:
http://pauillac.inria.fr/~xleroy/modmod/

http://lucacardelli.name/Papers/QuestSem.pdf

http://archive.numdam.org/ARCHIVE/ITA/ITA_1994__28_6/ITA_1994__28_6_513_0/ITA_1994__28_6_513_0.pdf

This was the case also for an extended version [1] in:
http://www.cs.cmu.edu/~rwh/papers/sharing/popl94.ps

I kept looking for something like that, perhaps the most related concept is a small-C, for 8080 computers if we are able to match this two subsets something may come of it with C-- approach, again, the most simple of it may come in it:
http://en.wikipedia.org/wiki/Small-C

I guess a good combination of features of this calculus might give us a good sign of hope here [1] further work came to semidecidable type inference, it could be that some rework could make things smarter:
http://www.cs.cmu.edu/~rwh/theses/lillibridge.pdf

Thanks in advance

[1] R. Harper and M. Lillibridge, “A Type-Theoretic Approach to Higher-Order Modules with Sharing,” 1994.

--- El lun, 4/7/11, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribió:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: Re: [M3devel] JIT [WAS: Google Benchmark - anyone interested in an Modula 3 version?]
> Para: m3devel at elegosoft.com, "Hendrik Boom" <hendrik at topoi.pooq.com>
> Fecha: lunes, 4 de julio, 2011 12:08
> 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
> >
> 