[perl #33129] N registers get whacked in odd circumstances
Dan Sugalski
# Please include the string: [perl #33129]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=33129 >
I'm finding that the N registers are getting messed up with some
function calls, though I can't pin down exactly which ones yet.
(Working on that) However, here's a trace of one of the cases where
they do get messed up:
167 set N5, N15 - N5=411.400000, N15=22253.000000
170 set I0, 1 - I0=1,
173 set I1, 0 - I1=0,
176 set I2, 0 - I2=0,
179 set I3, 0 - I3=0,
182 set I4, 1 - I4=0,
185 returncc
# Back in sub '_MAIN'
*** switching to BYTECODE_reports/sorep.imc
# Calling meth '__set_number_native'
# in file '(unknown file)' near line -1
# Calling sub '__set_number_native'
# in file '(unknown file)' near line -1
*** switching to BYTECODE_classes/Money8.imc
303 set N30, N5 - N30=219.000000, N5=-21841.600000
306 interpinfo P30, 16 - P30=PMCNULL,
309 classoffset I30, P30, "Money8" - I30=6,
P30=Object(Money8)=PMC(0x413da718),
313 getattribute P15, P30, I30 - P15=PMCNULL,
P30=Object(Money8)=PMC(0x413da718), I30=6
317 mul N30, N30, 100 - N30=-21841.600000, N30=-21841.600000,
321 floor N30, N30 - N30=-2184160.000000, N30=-2184160.000000
324 set P15, N30 - P15=Integer=PMC(0x413d99f8), N30=-2184160.000000
327 set I0, 1 - I0=1,
330 set I1, 0 - I1=0,
You'll note that N5 is set to 22253 when the returncc's done, but
after the return the value is -21814.6. Looks like something's
stomping the N registers.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
>
> You'll note that N5 is set to 22253 when the returncc's done, but
> after the return the value is -21814.6. Looks like something's
> stomping the N registers.
The program below shows exactly the same behavior WRT
__set_number_native. The call comes from inside of the mmd_fallback
function, so I presume that in the part before the shown trace you are
having some kind of mathematical operation that leads to the change in N5.
leo
.sub main
.local pmc cl, o, p, q
newclass cl, "money"
addattribute cl, "n"
o = new "money"
p = new "money"
q = new "money"
o = 2.0
p = 3.0
q = o + p
print q
print "\n"
.end
.namespace ["money"]
.sub __init method
$P0 = new Float
setattribute self, "money\0n", $P0
.end
.sub __set_number_native method
.param float n
$P0 = getattribute self, "money\0n"
$P0 = n
.end
.sub __get_string method
$P0 = getattribute self, "money\0n"
$S0 = $P0
.return($S0)
.end
.sub __get_number method
$P0 = getattribute self, "money\0n"
$N0 = $P0
.return($N0)
.end
Leopold Toetsch
> At 10:56 AM +0100 12/21/04, Leopold Toetsch wrote:
>> The program below shows exactly the same behavior WRT
>> __set_number_native. The call comes from inside of the mmd_fallback
>> function, so I presume that in the part before the shown trace you are
>> having some kind of mathematical operation that leads to the change in
>> N5.
>
>
> Yep, that's it. Going back a page or so I see this is triggered by some
> math, and I assume that something's not preserving the N registers as
> part of the dispatch in there somewhere. I'll see about poking around
> the code and tracking it down tomorrow unless someone beats me to it.
You must have some additional features" in that piece of code. The
example below does preserve N5 around the overloaded object access. But
maybe you can extend it to what your code is doing at the failing place.
leo
.sub main
.local pmc cl, o, p, q
N5 = 100.0
newclass cl, "money"
addattribute cl, "n"
o = new "money"
p = new "money"
q = new "money"
o = 2.0
p = 3.0
q = o + p
print q
print "\n"
print N5
Dan Sugalski
>>
>>You'll note that N5 is set to 22253 when the returncc's done, but
>>after the return the value is -21814.6. Looks like something's
>>stomping the N registers.
>
>The program below shows exactly the same behavior WRT
>__set_number_native. The call comes from inside of the mmd_fallback
>function, so I presume that in the part before the shown trace you
>are having some kind of mathematical operation that leads to the
>change in N5.
Yep, that's it. Going back a page or so I see this is triggered by
some math, and I assume that something's not preserving the N
registers as part of the dispatch in there somewhere. I'll see about
poking around the code and tracking it down tomorrow unless someone
beats me to it.