[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
|