lua-users home
lua-l archive

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


 
> Your emulator will no doubt emulate the endianness of the target, the
> idea is that it should work or fail just like the real thing.

nope, its an emulator of the os system calls, it doesnt emulate the endianess of the target board, so I need to live with both endianisms !
 
I just need to make sure that any app code I write is endian agnostic, which is a good principle to follow anyways
most of the time its a non issue, this is the first area I have got to tackle some problems.
 
Next thing I might try is to debug the standard Lua pc build that runs the binary file OK, side by side against the same binary running on the PC Target emulator that doesnt work
 
I have got a clue how the VM works, but at least I should be able to see where the two programs start to diverge. Maybe that will give me clue
 
Its an interesting if frustrating problem :)
 
Regards Geoff

 
> Date: Thu, 6 Oct 2011 18:49:53 -0500
> From: javier@guerrag.com
> To: lua-l@lists.lua.org
> Subject: Re: Byte code compiling question
>
> (Sorry for top-posting, this stupid phone doesn't let me do it right)
>
>
> If your target is big-endian, your port of Lua is big endian too, both
> on the emulator and the target. Thus, the bytecode compiled with luac
> on the PC will have to be byte-swapped at some point.
>
> Wouldn't it be easier to port luac to your target too and run it in
> the emulator? The resultant bytecode should run without any further
> swapping on both emulator and real hardware
>
>
>
>
> On 10/6/11, Jeff Smith <spammealot1@live.co.uk> wrote:
> >
> > Hi
> > > > As this is fundamentally still running on a big endian PC.....
> > Oops typo, I meant to say Little Endian I compiled the binary using standard
> > Luac on PC using Visual Studio 2008. Then ran that on PC target Simulator
> > again using VS2008, so it should have worked fine unless the bytecode
> > compiler does something silly like encode the absolute address of the print
> > function within the binary, but I am pretty sure it wouldnt encode in that
> > manner. I must be missing some other subtlety I believe both VS Studio and
> > the Target Compiler (CodeWarrior) are both IEE754 compliant, but I have got
> > to get past this first problem before its worth trying on the Target board.
> > Regards Geoff
> >
>
>
> --
> Javier
>