Quantcast

InterpreterProxy>>signed64BitIntegerFor: badly broken

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

InterpreterProxy>>signed64BitIntegerFor: badly broken

Andreas.Raab
Hi Guys -

I don't know if you ever used the above method but it's horribly,
horribly broken. I wrote a little test primitive (see below) that simply
used signed64BitIntegerFor(signed64BitValueOf(oop)) and then a loop like
here:

        0 to: 63 do:[:i|
                n := 1 bitShift: i.
                (self test64BitInt: n) = n ifFalse:[self halt: i].
        ].

Starting from i = 31 Every. Last. Result. Is Wrong. Can you imagine?

It gets even better, since it's broken in different ways: For i=31 the
result is negated, for everything beyound 31 the resulting large integer
is non-normalized (and therefore not comparing correctly).

Any ideas?

   - Andreas

PS. The primitive:

TestPlugin>>testSigned64BitInt
        | oop |
        self export: true.
        interpreterProxy methodArgumentCount = 1
                ifFalse:[^interpreterProxy primitiveFail].
        oop := interpreterProxy stackValue: 0.
        oop := interpreterProxy signed64BitIntegerFor: (interpreterProxy
signed64BitValueOf: oop).
        interpreterProxy failed ifFalse:[
                interpreterProxy pop: 2 thenPush: oop.
        ].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: InterpreterProxy>>signed64BitIntegerFor: badly broken

Andreas.Raab
PS. Once we fix that, let's increase the VM_Proxy's minor version. I
need that function to work correctly.

Cheers,
   - Andreas

Andreas Raab wrote:

> Hi Guys -
>
> I don't know if you ever used the above method but it's horribly,
> horribly broken. I wrote a little test primitive (see below) that simply
> used signed64BitIntegerFor(signed64BitValueOf(oop)) and then a loop like
> here:
>
>     0 to: 63 do:[:i|
>         n := 1 bitShift: i.
>         (self test64BitInt: n) = n ifFalse:[self halt: i].
>     ].
>
> Starting from i = 31 Every. Last. Result. Is Wrong. Can you imagine?
>
> It gets even better, since it's broken in different ways: For i=31 the
> result is negated, for everything beyound 31 the resulting large integer
> is non-normalized (and therefore not comparing correctly).
>
> Any ideas?
>
>   - Andreas
>
> PS. The primitive:
>
> TestPlugin>>testSigned64BitInt
>     | oop |
>     self export: true.
>     interpreterProxy methodArgumentCount = 1
>         ifFalse:[^interpreterProxy primitiveFail].
>     oop := interpreterProxy stackValue: 0.
>     oop := interpreterProxy signed64BitIntegerFor: (interpreterProxy
> signed64BitValueOf: oop).
>     interpreterProxy failed ifFalse:[
>         interpreterProxy pop: 2 thenPush: oop.
>     ].
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: InterpreterProxy>>signed64BitIntegerFor: badly broken

timrowledge
In reply to this post by Andreas.Raab

On 7-Jun-06, at 6:58 PM, Andreas Raab wrote:

> Hi Guys -
>
> I don't know if you ever used the above method but it's horribly,  
> horribly broken. I wrote a little test primitive (see below) that  
> simply used signed64BitIntegerFor(signed64BitValueOf(oop)) and then  
> a loop like here:
>
> 0 to: 63 do:[:i|
> n := 1 bitShift: i.
> (self test64BitInt: n) = n ifFalse:[self halt: i].
> ].
>
> Starting from i = 31 Every. Last. Result. Is Wrong. Can you imagine?
>
> It gets even better, since it's broken in different ways: For i=31  
> the result is negated, for everything beyound 31 the resulting  
> large integer is non-normalized (and therefore not comparing  
> correctly).
>
> Any ideas?

Well for starters the signed64BitIntegerFor: code assumes an 8 byte  
large integer no matter what the value being converted so that's  
going to cause your non-normalized problem. I'm fairly sure you can  
work out how to fix that bit quickly enough.

I'm not absolutely sure(and I can't be bothered to look it up right  
now) but wouldn't 1<<31 be a negative value when treated as a 32 bit  
word? It looks to me as if signed32BitInteger might be the wrong  
thing to use in signed64itInteger, with positive32BitInteger a bit  
more plausible.

I have vague memories of when this code was written, mostly of it  
being related to long file pointers in OSs I wasn't running at that  
time. Thus I would have relied upon testing by involved parties and  
taken their word as to the viability of the code. I guess that once  
again the value of good tests is demonstrated.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: VMB: Verify, then Make Bad


Loading...