|
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 = 000000001100AA10The 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.
[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.
-- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia