Dear Squeakers,

Meta: 

I have some understanding and some practical problems.

I haven't worked for years at ParcPlace/Disney/Cincom and I haven't written
an ST interpreter. Possibly some of these things would be a good foundation
to go deeper here... ;-)

I don't think, I'm stupid in principle, but sometimes I get this feeling
*here*...

Possibly I shouldn't go too deep into this stuff, because it is quiet
special and needs deep insights to become productive here; but currently I'm
interested in it and motivated to go a little deeper... And I think some of
mine problems are resulting from a lack of existing or found documentation.
BTW: It is natural, that in this special area there isn't so much doc as in
more common areas: Not everybody is interested in looking into the
mechanisms of compiling and VMs; and more less in improving this stuff...


Concrete:

Squeaks ST80 implementation of BlockContexts without any BlockClosures is
far away from Eliot's paper. I think I need an understanding of
BlockClosures first and have just searched for papers about BlockClosures,
without success.

With platform dependent I've meaned the 'hybrid context' together with
'native frame' stuff, introduced to support just in time compilers. To use
this we need a Jitter. Am I correct here?

I'm thinking (not working! (would be interesting, though)) about a less
ambitious solution with the current 'normal' VM.

I have a non commercial VW:

sr at Klaus:~ > vw5i -version
Copyright © 1999 Cincom Systems, Inc.
All Rights Reserved.
Release identification ...
        OE   version: 51 platform: 168 release: 51.4 flags: 0
        VI   version: 0 minor: 0 release: 0 variant: 0
        From version: 0 platform: 0 release: 0.1 flags: 0

; there is some documentation, but to get an understanding of 'classical'
BlockClosures some kind of paper related to an earlier version of VW without
so much optimizations would be better.
Moreover I don't fully understand the VW-VM definition: E.g. when which
temporary variables are pushed why onto the stack before calling a BC and
how they are pop'ed thereafter. In short: the logic of compiling by the
Compiler and interpreting the compiled result by the VM; especially in
regard to BCs. Just looking with an inspector onto CompiledMethods and
CompiledBlocks and jumping around from method to method isn't sufficient to
get deeper insights.


Vassili Bykov wrote:
> 
> Stephan,
> 
> The only thing I can add to what Tim already said is you can read "Lisp in
> Small Pieces" or SICP.

Thanks for the hint; is this somewhere in the net?


Greetings,

Stephan

> They explain in detail some things Eliot's paper
> assumes the reader knows.  (Though I still can't see how it is not "platform
> independent"--unless you want a Smalltalk VM on a Turing machine or
> something).
> 
> --Vassili
> 
> --
> Vassili Bykov
> VisualWorks development
> vassili at parcplace.com
> 
> > -----Original Message-----
> > From: Stephan Rudlof [mailto:sr at evolgo.de]
> > Sent: Saturday, July 29, 2000 8:43 AM
> > To: squeak at cs.uiuc.edu
> > Subject: Re: Block closures
> >
> >
> > Vassili Bykov wrote:
> > >
> > > Eliot's OOPSLA paper describes that improvement, as well as
> > gives a good
> > > intro to closure implementation in VW in general:
> > >
> > > http://www.squeak.org/oopsla99_vmworkshop/oopsla99-contexts.pdf
> >
> > I have to put some water into the wine here... ;-(
> >
> > The paper is interesting and stands in the tradition of and
> > is related to
> > earlier VW implementations, which have extended the ST80
> > specification.
> > It addresses the realization of very fast block closures, so
> > far so good.
> >
> > But to reach this goal, native stack layout is used and
> > different kind of
> > mappings of ST contexts to native stack frames. I think this
> > fits good into
> > JIT-Compiler work, but
> >
> > *** this isn't a platform independent approach ***.
> >
> > Moreover I don't see a realization just by changing the
> > interpreter and ST
> > contexts, methods and related things.
> >
> > To reach platform independence, we should use a slower, but compatible
> > realization of block closures. More sophisticated techniques should be
> > applied after a working common variant.
> >
> > BTW: Are there any papers describing BlockClosures without
> > referring to
> > native stack layout?
> >
> >
> > Greetings,
> >
> > Stephan
> >
> >
> > > --
> > > Vassili Bykov
> > > VisualWorks development
> > > vassili at parcplace.com
> > >
> > > > -----Original Message-----
> > > > From: Tim Rowledge [mailto:tim at sumeru.stanford.edu]
> > > > Sent: Thursday, July 27, 2000 2:29 PM
> > > > To: squeak at cs.uiuc.edu
> > > > Subject: Re: Block closures
> > > >
> > > >
> > > > Mats, if you're serious about this, do yourself a big favour
> > > > and talk to
> > > > Eliot Miranda about his recent (as in a year or so ago)
> > > > improvements to
> > > > block handling in VW; he's explained it to me but I
> > couldn't for the
> > > > life of me explain it to you and get it right. Basically I
> > > > think it ...
> > > > oh hell, get him to explain it.
> > > >
> > > > And don't forget to talk with Ian Piumarta to make sure he isn't
> > > > duplicating the work (he said at ECOOP he'd tackle it soon)
> > > > and that you
> > > > don't do anything that will break the jitter. Craig Latta did some
> > > > pretty serious planning with Ian some time ago on this
> > subject so he
> > > > might some useful input for you as well. And don't forget the
> > > > VM changes
> > > > you'll need.
> > > >
> > > > And don't forget to work out howto get there from here; the
> > > > bit that has
> > > > always put me off trying anything. I'd suggest using the
> > > > SystemTracer to
> > > > clone a new image with BlockClosures rather than trying
> > to manage with
> > > > both styles. At least with Squeak you can simulate the
> > new system and
> > > > have a decent debugger.
> > > >
> > > > tim
> > > >
> > > > --
> > > > Tim Rowledge, tim at sumeru.stanford.edu,
> http://sumeru.stanford.edu/tim
> > > To err is human; to forgive, beyond the scope of the Operating System.
> > >
> 
> --
> Stephan Rudlof (sr at evolgo.de)
>    "Genius doesn't work on an assembly line basis.
>     You can't simply say, 'Today I will be brilliant.'"
>     -- Kirk, "The Ultimate Computer", stardate 4731.3

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3