New implementation of squeak

[bryce at kampjes.demon.co.uk]

Guillermo Adrián Molina writes:
 > Hi to all, I am a Smalltak VM enthusiast. I found this list an interesting
 > reading. But I was wandering a few things. If you could rewrite the
 > Squeak's object memory from scratch, in order to simplify and accelerate
 > exupery, what would you do?

My list would be:
 * Integer tags as 0.
 * Use a card marking memory barrier
 * Get rid of short classes to simplify type checking.
 * Store the size of variable objects in a word at a known position
   not in one of 2 locations. This is to simplify range checking.
 * A much faster GC which may be needed once Exupery starts providing
   a good general speed improvement.

But Exupery works with Squeak's current object memory, any changes
to the object memory would involve making similar changes to Exupery.

I'm not sure how much value changing integer tagging would bring.
"a := a + 1" is now compiled to the same instruction sequence as a
0 tag would use. There is a single instruction overhead for tagging
with 1 not 0 in most cases. The trick is to realise that if you don't
detag one of your arguments you will not need to retag the result and
that constants can be tag manipulated at compile time.

I'm happy with boxed floats. Personally I think tagged floats are
likely to be slower than a good optimizing boxed float solution. I'd
rather have floats stored in float arrays then optimism away the
boxing and deboxing. The problem with tagged floats is you need to
detag them and that's much more expensive than tag manipulation on
integers which is annoying as modern hardware has about the same
floating point bandwidth as integer bandwidth.

Booleans as proper objects is fine. There is one true object and one
false object so there's no need to create an object which is the
expensive part. And again, it's easy to remove intermediate boolean
values from the code.

I wrote an article for my Smalltalk Solutions presentation that 
covers what Exupery currently does and analyses the code it produces
which should be worthwhile reading if you want to figure out out 
expensive the operations are.

  http://goran.krampe.se/exuperyDesign.pdf

May I ask what you're trying to do? Practically, it's hard to evaluate
how important any object memory changes will be to Exupery because
often it's possible to optimism away the overhead in many cases. Until
Exupery has a high quality optimizer it's impossible to do experiments
to see what overhead is left.

Bryce