New implementation of squeak

[Guillermo Adrián Molina]

> 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
> _______________________________________________
> Exupery mailing list
> Exupery at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
>
Thanks a lot for the info.
I asked all that because I have read many papers, mails an all that. In
many of them, I saw that exupery had to be more complex in order to comply
with the Squeak's implementation.
I am designing a smalltalk VM, so I have the freedom to choose. In my
design I generate assembler directly. Every CompiledMethod has x86 code in
it. I use SmaCC and Refactoring Browser, with the Squeak's new
ClosureCompiler. With that (and some Class tweaking) I generate assembler
(.s text, no code yet). Then I compile that with my VM. So, i don't need
an interpreter. Just a few functions for method finding and primitives.
Exupery (I hope) will replace my ParseNode to assembler implementation. It
will give me translation to machine code, optimization, PIC's, and all the
wonders that it includes.
I started my design with 1 tagged SmallInts, basically because much of my
ST knowledge comes from Squeak, and because I had no idea, how a 0 tagged
smallint would be implemented.
In my design, as I was focusing on simplicity of the code, an object
header has:
object: