four byte integers

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

four byte integers

Vincent Lesbros-2
May I ask a question ?

16r20746D66 = 16r20746D66 true

16r20746D66 == 16r20746D66  false

Why this value, coded into 4 bytes is greater than SmallInteger maxVal ?
or why SmallInteger maxVal has been set to 16r1FFFFFFF ?
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: four byte integers

Steven Kelly
Vincent Lesbros wrote 22. Feb 2012 1:34
> 16r20746D66 = 16r20746D66 true
> 16r20746D66 == 16r20746D66  false
>
> Why this value, coded into 4 bytes is greater than
> SmallInteger maxVal ?
> or why SmallInteger maxVal has been set to 16r1FFFFFFF ?

For implementation efficiency, the VM internally uses a 4-byte object
representation that can either be a pointer to the real object's info,
or an immediate value like an integer or character. A couple of bits are
used to distinguish whether this is a standard object or some kind of
immediate one, leaving 30 bits for the SmallInteger range. Half of that
range is positive, so maxVal is 2^29 - 1.

Some general discussion on this in various Smalltalks is here:
http://marianopeck.wordpress.com/2011/10/26/memory-addresses-and-immedia
te-objects/

Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: four byte integers

Holger Guhl
In reply to this post by Vincent Lesbros-2
SmallInteger "instances" are so-called immediate objects, i.e. the bytes
are the object. As Steven said, some reserved bits tell whether a 4-byte
word is an immediate (and what kind of). These reserved bits make the
value range for SmallInteger smaller than 4 bytes  allow. This is the
reason why 16r20746D66 is represented by a LargePositiveInteger which is
a "real" object, an instance with its own identity.
Comparing LargePositiveInteger instances with #== will most likely
return false - unless you really compare a LargePositiveInteger with
itself. The same consideration is true for "1.0 == 1.0" which is always
false. For each "1.0" in this tiny piece of code, the compiler creates a
new Float instance. They are equal but not identical. Comparing with #=
returns true, comparing with #== returns false.
For comparing number values you better use #=. There is no reason to
optimize on your coding level since the VM and its primitives do the
optimized computation.

- Holger

Vincent Lesbros schrieb:
> May I ask a question ?
>
> 16r20746D66 = 16r20746D66 true
> 16r20746D66 == 16r20746D66  false
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc