# [Vm-dev] positive32BitValueOf: fail with LargePositiveInteger

Mariano Martinez Peck marianopeck at gmail.com
Fri Oct 8 22:02:35 UTC 2010

```On Fri, Oct 8, 2010 at 11:47 PM, David T. Lewis <lewis at mail.msen.com> wrote:

>
> On Fri, Oct 08, 2010 at 07:12:13PM +0200, Mariano Martinez Peck wrote:
> >
> > So....I don't understand...how can I have a LargePositiveInteger but that
> is
> > less than 32 bits?  Wouldn't that  be a SmallInteger?
>
> SmallInteger maxVal hex ==> '16r3FFFFFFF'.
>
> The largest positive two-compliment integer that fits into 32 bits is
> 16rEFFFFFFF, so any Integer in the range 16r4000000 through 16rEFFFFFFF
> is a LargePositiveInteger that can fit into a signed 32-bit C int.
>
> Thus the number of LargePositiveInteger values that fit into a 32-bit
> twos-compliment representation is (16r4000000 to: 16rEFFFFFFF) size ==>
> 3959422976
>
> Note that a SmallInteger is represented internally as a 31-bit value,
> which accounts for the difference. It's a bit confusing when you are used
> to thinking of 32-bit int values.
>

Thanks Dave for the clarification. This was exactly my question and my
problem.
I do know that SmallInteger are 31 bits sine the last bit is used to
distinguish from oop.
What I didn't understand is how can I have a LargePositiveIntener in 32
bits.....because less than that it would be a SmallIntegr.

Then, I didn't understand why positive32BitValueOf:  has this part:

self assertClassOf: oop is: (self splObj: ClassLargePositiveInteger).
successFlag ifTrue: [
sz := self lengthOf: oop.
sz = 4 ifFalse: [^ self primitiveFail]].
successFlag ifTrue: [
^ (self fetchByte: 0 ofObject: oop) +
((self fetchByte: 1 ofObject: oop) <<  8) +
((self fetchByte: 2 ofObject: oop) << 16) +
((self fetchByte: 3 ofObject: oop) << 24) ].

values between being 31 and 32 bits and this is how I can have LargePositive
integer with 32 bits.

Thanks Dave.

Mariano

>
> Dave
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20101009/68791a5d/attachment.htm
```