I just watched [1] on Gemstone's object format and was interested to see how it uses 000 in the low order bits for direct in-memory object pointers. I presume Spur does something similar but was curious how it specifically compares.
[1] http://www.youtube.com/watch?v=BAFUafgEwvw
Also, probably not a good idea but I wondered what pros/cons there might be to just adopting Gemstone's object format.
cheers -ben
Hi Ben,
On Sat, Nov 2, 2013 at 5:57 PM, btc@openinworld.com wrote:
I just watched [1] on Gemstone's object format and was interested to see how it uses 000 in the low order bits for direct in-memory object pointers. I presume Spur does something similar but was curious how it specifically compares.
I developed the SmallDouble format for 64-bit VisualWorks with help from Martin McClure :-). The idea is essentially the same. But in Spur theres' both a 32-bit and a 64-bit version. The 32-bit version currently doesn't use the 2nd bit, confining its tags to bits 0 & 1. Further, the 32-bit system has 31-bit SmallIntegers, so if the lsb is 1 the pointer is a SmallInteger, if the ls 2 bits are 10 it is a Character, otherwise it is a pointer to an object header.
Bit in 64-bit Spur there will be 3 tag bits and indeed SmallInteger, Character and SmallDouble are the tagged types. Making nil true & false tagged types IMO doesn't make much sense; it just complicates the fetchClassOf code. IMO it is better to have nil-true & false be normal objects, albeit at locations where they'll never move. So no tagged nil, true & false. Otherwise its the same basic set of ideas on object representation.
HTH, Eliot
Further, there's no object table in Spur, only flat pointers.
[1] http://www.youtube.com/watch?v=BAFUafgEwvw
Also, probably not a good idea but I wondered what pros/cons there might be to just adopting Gemstone's object format.
cheers -ben
vm-dev@lists.squeakfoundation.org