[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: and/or missbehaviour in embedded lua 5.1
- From: Andreas Stenius <kaos@...>
- Date: Thu, 16 Mar 2006 19:48:16 +0100
Kein-Hong Man skrev:
Something is most certainly broken. I'm still poking around to find out
where, and I can't really let go of the idea it lies some where in
the lua sources.. I do get the correct value when used with variable
lookup (as shown earlier). Part of my struggle is that I unfortuanetly
doesn't have a
debugger for my target, so I can't step through the c-code, and it's
quite tedious process downloading after each recompile, so it all adds
up and takes quite alot of time..
Andreas Stenius wrote:
Interesting, I implemented luac into my monitor to see the output,
and get this:
> c"local a = true and 0"
main <(string):0,0> (2 instructions, 8 bytes at 0x148f7a)
0+ params, 2 slots, 0 upvalues, 1 local, 1 constant, 0 functions
1  LOADK 0 -1 ; 2.1436356971487e-228
2  RETURN 0 1
constants (1) for 0x148f7a:
locals (1) for 0x148f7a:
0 a 2 2
upvalues (0) for 0x148f7a:
> c"local a = true or 0"
Looking at the bit patterns for double values,
1.0890312344636e-60 = E0FFFFFF05007C33
2.1436356971487e-228 = 000000001100AA10
The first 4 bytes look mighty suspicious... since the expression is
essentially the same but your earlier sample (=true and 0) gave a
different value, I guess something is broken. Without more
information, it's almost impossible for anyone on the list to diagnose
what had caused it; we would be only speculating.
I did miss to point out that I got the different strange value after a
recompile. Which, as you say, suggests something weird with the code
But it still would be in interaction with the lua sources how the code
is used that generates bad code (which would be a bug in the compiler
non the less, but
it should be able to come to a work-around for that).
it's little endian, and lua_Number is double.
Thanks for your input!
The sizes for the various data types is as:
["char"] = 1,
["void *"] = 4,
["int"] = 2,
int is the only data type that is different compared to x86. What
lua_Number and endianness are you using? Assuming no modifications,
ldump.c doesn't look like it can introduce such funny values, so I
guess the values are produced by the code generator.