On 27.10.2010, at 16:09, David T. Lewis wrote:

> On Wed, Oct 27, 2010 at 03:15:05PM +0200, Bert Freudenberg wrote:
>> 
>> On 27.10.2010, at 13:30, David T. Lewis wrote:
>> 
>>> On Tue, Oct 26, 2010 at 07:17:16PM +0000, commits at source.squeak.org wrote:
>>>> Nicolas Cellier uploaded a new version of Kernel to project The Trunk:
>>>> http://source.squeak.org/trunk/Kernel-nice.508.mcz
>>>> 
>>>> ==================== Summary ====================
>>>> 
>>>> Name: Kernel-nice.508
>>>> Author: nice
>>>> Time: 26 October 2010, 9:17:01.308 pm
>>>> UUID: f75f55d1-4fc4-4ba7-8790-248dea6d3136
>>>> Ancestors: Kernel-ul.507
>>>> 
>>>> Correct #isWords comment. There is no such thing as 16-bit variables.
>>>> Don't know what would be the answer in a 64 bit image...
>>> 
>>> On a 64-bit image, we have this:
>>> 
>>> Smalltalk wordSize ==> 8
>>> Bitmap isWords ==> true
>>> String isWords ==> false
>>> CompiledMethod isWords ==> false
>>> Array isWords ==> true
>>> FloatArray isWords ==> true
>>> IntegerArray isWords ==> true
>>> 
>>> The result for String looks like a bug in the 64-bit image or VM (a 32-bit
>>> version of the same image answers true). The other results are the same
>>> as for a 32 bit image.
>>> 
>>> For a 64-bit image, the word size is 8 and the things in the slots after
>>> the object header may be either 64 bits (object points, float values)
>>> or 32 bits (e.g. the elements in a FloatArray).
>>> 
>>> For example, if you have (FloatArray with: Float pi with: Float pi),
>>> the object has a single 64-bit word containing two 32 bit float values.
>>> However, if you have (Array with: Float pi with: Float pi), the object
>>> will have two 64 bit words containing the object pointers for two Float
>>> objects.
>>> 
>>> Dave
>> 
>> Since in the 64-bit image nothing really has changed except oops being
>> 64 bits instead of 32 bits wide, and oops not being directly accessible,
>> I wonder if #wordSize shouldn't still answer 4 (to be in sync with
>> #variableWordSubclass etc). Maybe we need a new method #oopSize which
>> would answer 8.
> 
> Actually I like the current use of the term "word" because it conveys
> the idea of the object memory being made up of words of uniform size.
> The contents of a word might be an oop, or a portion of an object header,
> or some data component of the object. But in all cases (in the current
> Squeak designs) the words are the same size, and the location of the word
> in object memory is an object pointer. If the object pointer happens to
> point to an object header, then it is an oop. Simple, although not
> terribly obvious at first glance.
> 
> So in a 32 bit or 64 bit (or 16 bit, etc) object memory the #wordSize
> is important for various reasons, regardless of whether the word
> contains an oop or something else. I think that this also helps
> convey the important idea that the wordSize in object memory has
> no direct relationship to sizeof(int) or sizeof(void *) or any of
> that other platform specific stuff. After all, this is the reason
> that we can run our 64-bit images on 32-bit platforms.
> 
> Dave

But what do you call the elements in a variableWordSubclass in a 64 bit image then? Half-words? Because 64 bit words are not exposed at all in the image. Nowhere, AFAIK. 

- Bert -