Re: Lua Cross Compiler

[Steven Barth <steven@...>]

Am Freitag, 4. April 2008 10:04:45 schrieb Asko Kauppi:
> How about just defining LUA_INTEGER to be 'int' (not ptrdiff_t) on the
> AMD64?
>
> That would make lua_Integer go 32-bit, which should be enough for full
> bytecode compatibility. Am I right?
Thanks for this idea.


If I am right the following conditions have to be equal to be fully binary 
compatible (lundump.c/luaU_header):

> h+=sizeof(LUA_SIGNATURE)-1;
> *h++=(char)LUAC_VERSION;
> *h++=(char)LUAC_FORMAT;
Irrelevant 

> *h++=(char)*(char*)&x;                         /* endianness */
I found this lundump.c-patch by lhf regarding this issue:
http://lua-users.org/lists/lua-l/2006-02/msg00507.html

> *h++=(char)sizeof(int);
Int should be 32bit on any platform as definied in C99 standard.

> *h++=(char)sizeof(size_t);
This is more of a problem as it's the pointer size.

> *h++=(char)sizeof(Instruction);
Is unsigned int (by default) so should also always be 32bit.

> *h++=(char)sizeof(lua_Number);
lua_Number defaults to double which should always be 64bit.

> *h++=(char)(((lua_Number)0.5)==0);             /* is lua_Number integral? */
should be irrelevant as well


If I had not confused anything there is only the size_t issue left. So in what 
way does size_t (the pointer size) affect the byte-code files and how could 
we make this platform-independent and hmm the final question:

* Make LUA_INTEGER 'int'
* Endianess-aware LoadMem (patch see above)
* size_t issue

Is there anything left to think of?