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