Re: and/or missbehaviour in embedded lua 5.1

[Kein-Hong Man <mkh@...>]

Andreas Stenius wrote:
> Kein-Hong Man skrev:
> > Andreas Stenius wrote:
> > [snip]
> > 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..

Since the problem is due to the code generator producing a 
funny-looking constant, debugging information would be the most 
helpful thing now. We have pinpointed the problem, we just need to 
know why those constants are generated. Even if there is a config 
workaround, I think it's worth getting to the bottom of this and 
finding out exactly why it happens. It would be valuable to other 
users on the list who use Lua in embedding.

> 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.

It should be like x86 except for int... hmmm... yeah, the 
debugging nightmare would be if it's a problem with the C 
compiler. So it could be any one of the following:
(a) some place in the code generator doesn't like an int of 2 and 
it borks
(b) C compiler miscompiles the code generator due to the way it 
interprets C, some lack of information, some kind of shortcut 
taken or an internal bug
(c) double type problem due to math library or conversion
(d) ???

Without a debugger, peppering lcode.c with printfs should be fine.

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia