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