New implementation of squeak

> 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
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
>

>> 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
>> [hidden email]
>> 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:
>