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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Oct 27 20:13:32 UTC 2010


2010/10/27 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Wed, Oct 27, 2010 at 7:43 AM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
>>
>> 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.
>
> I think the only sensible solution is to call them words and have them be
> 32-bits in both 32-bit and 64-bit images.  There's no necessary
> correspondence between the size of an oop and the field-width of a
> variableWordSubclass:.  So we have variableByteSubclass: and
> variableWordSubclass: with widths 1 byte and 4 bytes respectively.  We could
> conceivably add variableHalfWordSubclass: and variableDoubleWordSubclass:
> for 2 bytes and 8 bytes field widths respectively.
> Varying the width of any of the non-oop subclasses between the 32-bit and
> 64-bit images will simply break applications because when porting code from
> 64-bits to 32-bits values won't fit in the smaller 32-bit interpretation.
>  This is analogous to C's float and double datatypes on 32- and 64-bit
> architectures.  Irrespective of the system being 32- or 64-bit float is
> 32-bit and double is 64-bit.  So byte == 8 bits, halfWord == 16 bits, word
> == 32 bits and doubleWord == 64 bits irrespective of the underlying width of
> the machine.
> Hence better names might be
> variable8BitSubclass:
> variable16BitSubclass:
> variable32BitSubclass:
> variable64BitSubclass:
> because then one doesn't have to think.
>> Eliot
>

That's more inline with what i thought it could be...
It would then be easier to have st-source compatibility.
As I understand this is currently not the case of FloatArray
ShortIntegerArray etc...

Nicolas

>>
>> - Bert -
>>
>>
>
>
>
>
>



More information about the Squeak-dev mailing list