Hi Ian,

> have been met.  Some trivial additions are required to the win32 tree to
> make it work, but they're outside the tree that I checked out.  If you're
> curiosity is instatiable then I could check out my modified win32 tree

    My curiostity is  instatiable  ;-)

    Please let me know where I can find it.
    (Does it build out of the box )

    Cheers,

    PhiHo.

----- Original Message -----
From: "Ian Piumarta" <ian.piumarta at inria.fr>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Monday, February 17, 2003 8:08 PM
Subject: Re: Jitter


> On Mon, 17 Feb 2003, Eric Merritt wrote:
>
> > Hello All,
>
> Hi Eric,
>
> > Just out of curiosity does anyone know where development of the Jitter
> > is at?
>
> It's stalled.  I wanted make a version that worked on Mac for Dan to play
> with and the easiest route appeared to be to make it work on OS X which he
> was planning to install.  Making j5 work on OS X meant making the Unix VM
> work on OS X, but that particular "subproject" got slightly out of hand
> and finally turned into a significant part of the hacking I've done during
> the last 5 or 6 months.
>
> The current non-optimising compiler generates native code with all the
> hooks, profiling, recompilation triggers and support in place to do
> adaptive compilation based on runtime type feedback.  (I was about to
> embark on the first round of adaptive compilation when I became distracted
> by OS X.)  The emphasis is on reducing compilation time to an absolute
> minimum: what's important is generating code for lots of methods quickly
> (compilation shouldn't introduce any detectable pauses in execution) but
> which includes profiling (to record type, sender and frequency information
> to drive an optimising compiler).  The real benefits come from
> recompilation using this optimising compiler, once runtime type behaviour
> is known, whose emphasis is on producing the fastest possible code at the
> expense of compilation time.  Since this compiler is invoked far less
> frequently than the non-optimising one, its longer compilation times
> shouldn't introduce detectable pauses either.
>
> The non-optimising compiler already produces stable code (where "stable"
> means I don't know how to crash the code by writing bizarre methods,
> abusing contexts or exceptions, etc., within the image) for PPC and 386.
> The first part of the optimising compiler was the next thing on the to-do
> list when OS X came along and preempted it.
>
> > I heard that Ian was working on J5 and I did a quick search of the
> > archive and couldn't find anything interesting.
>
> I don't think there's been any discussion of it here.
>
> > I am really just curious about it.
>
> To satisfy your curiosity I checked it out for you here:
>
>   http://www-sor.inria.fr/~piumarta/squeak/unix/j5
>
> Although I don't suggest you try this at home, the above could be dropped
> into a 3.2 tree (next to the "platforms" and "src" dirs) and will build a
> working j5 (provided the regular VM has already been built in a dir called
> "bld" at the same level).  It generates code for PPC on Unix and 386 on
> Unix or Windows.  (It probably works with the 3.5 tree too, modulo the
> Quartz code not bothering to look for "j_interpret" before launching the
> interpreter, so my objective of making it work on Mac OS might already
> have been met.  Some trivial additions are required to the win32 tree to
> make it work, but they're outside the tree that I checked out.  If you're
> curiosity is instatiable then I could check out my modified win32 tree
> too.)
>
> The above directory contains the answers to any and all questions you
> might have regarding j5, albeit in an _extremely_ undigested form. ;)
>
> I'm hearing encouraging things about Anthony's latest run at his closure
> work.  When I get round to picking up j5 from where I left off I'll
> probably start by looking at what he's been up to and adapt j5 to work
> with it instead of with an unmodified "traditional" image.
>
> Regards,
> Ian
>
>