Subjective Squeak

Bryce Kampjes bryce at kampjes.demon.co.uk
Fri Dec 13 18:06:33 UTC 2002


Tim Rowledge writes:
 > 
 > On Tuesday, December 10, 2002, at 01:34  PM, Stephen Pair wrote:
 > 
 > > Stephane Ducasse wrote:
 > >> Hi anthony
 > >>
 > >> If you want by any chance that the blockclosure gets accepted in the
 > >> Squeak kernel
 > >> as I would like. PLEASE do not mix research ideas with that. Fix all
 > >> the problems you know
 > >> or others know (decompiler....) first
 > >
 > > I kind of agree with Stephane here.  I *really* would like block
 > > closures in Squeak.  But even the stack optimizations that are in VI4
 > > concern me a bit.  It seems like that goes too far into the research
 > > realm and jeopardizes the acceptance of the work done on block 
 > > closures.
 > > Everyone knows what block closures are and why they are needed; there 
 > > is
 > > a much greater chance of them getting into the base VM if they don't
 > > come with extra stuff that's less well understood and proven.
 > I pretty much agree with this; I'd much rather get functioning closures 
 > into the system with absolutely minimal VM changes and accept even some 
 > performance hit if necessary (and remember I probably live with the 
 > slowest machine of any of us) and then do VM changes for performance 
 > later. Although Anthony's work on a linearized stack is very good I 
 > still feel most uncomfortable having it in the image rather than the 
 > VM. LPD taught me "you can cheat but don't get caught" and it feels 
 > like having been caught.

Unfortunately I haven't had time to really explore
Anthony's work but I do wish I could. In general
it sounds incredibly promising.

Just a few points:

1) Block Closures would be very very cool.

2) The stack may not have a noticeable speed improvement
with a state of the art dynamic compiler. (OK, we don't
have one yet.)

"Dynamic compilation with type feedback" will reduce the 
number of calls, enough zero cost calls and the gains
might not be noticeable.

A dynamic compiler isn't likely to use the stack. After
all it is faster to keep the values in registers. Simplicity
is more important to make it easy to maintain the context 
objects/stack as well as a native register representation.

3) Changing the integer tag from 1 to 0 would have a big
speed improvement for compiled code. With the current
scheme it takes 10 instructions to do a small integer
add, with tag of 0 it would take 6 instructions. 4 of
the instructions in both cases are tag checks and can 
sometimes be removed even with a simple tree traversing 
optimizer.

This improvement is probably only available by compiling
direct to assembly. I don't think you can access the flags
from C for overflow checking.

Bryce



More information about the Squeak-dev mailing list