lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

I forgot to add, this is all done with lua 5.0.2

Andreas Stenius wrote:


Kein-Hong Man skrev:


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       [1]     LOADK           0 -1    ; 2.1436356971487e-228
       2       [1]     RETURN          0 1
constants (1) for 0x148f7a:
       1       2.1436356971487e-228
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.
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..
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 generator. 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!

//Andreas




[snip]
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.