[squeak-dev] The Trunk: Kernel-nice.508.mcz

Bert Freudenberg bert at freudenbergs.de
Wed Oct 27 13:15:05 UTC 2010


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.

- Bert -


More information about the Squeak-dev mailing list