RE: Byte code compiling question

Hi again

Thanks for the help and the suggestions guys.

I have just found what the problem was on the PC Simulator not running the binary test file. It turned out to be a trivial problem in the end, I will explain what it was for anyone interested to know.

My target board uses a proprietary file system that is similar to the standard Ansi file system, but not identical.  Two significant differences are that it doesnt distinguish between opening a file for read in "r" or "rb" mode. (All files are opened in binary mode") and secondly it has no freopen() function.

This meant I had previously needed to modify this little bit of code in lauxlib.c to remove the unnecessary freopen()

if (c == LUA_SIGNATURE[0] && filename)
{ /* binary file? */
    lf.f = freopen(filename, "rb", lf.f); /* reopen in binary mode */
    if (lf.f == NULL)
       return errfile(L, "reopen", fnameindex);
    /* skip eventual `#!...' */
   while ((c = getc(lf.f)) != EOF && c != LUA_SIGNATURE[0]) ;
    lf.extraline = 0;
}

The silly mistake I had made was to not notice I needed to rewind the file pointer back a char so that the while loop afterwards doesnt miss the LUA_SIGNATURE[0] byte.
The fix was easy, I just added a ungetc(c, lf.f); line.

This bug was a good example of how having a PC based simulator can save a lot of time, this mistake would have taken me much longer to find on the real target board.

Just the build and download to the target takes about 45 seconds, compared to VS build and run time of less than 1 second ! The OS Simulation is accurate enough to simulate the "deficiencies" of the Target OS, and hence showed up the same bug I would have hit on my target board.

Now I am past this silly, next week I will have a look at the lundump.c and dump.c from LuaPlus and see if I can get the endian swap working correctly on the target board.

Regards Geoff

From: bogdan.marinescu@gmail.com
Date: Fri, 7 Oct 2011 12:56:14 +0300
To: lua-l@lists.lua.org
Subject: Re: Byte code compiling question

On Fri, Oct 7, 2011 at 12:35 PM, Patrick Rapin <toupie300@gmail.com> wrote:

> Are you quite sure about this? It seems very weird to have an emulator that can't
> actually run your target's binaries (which is obviously the case since the endianness is different).

Of course, he is. Probably that the term 'emulator' is incorrect for
this case. This is more a firmware simulator.
I have developed something similar for Olivetti printer firmware. It
is possible to compile a subset of the firmware classes in a Windows
program, to test non mechanical related things like the printer
language emulation.
But the environments are very different: MIPS processor, big endian,
GHS compiler and uCos RTOS on one side, and Intel processor, little
endian, Microsoft compiler and Windows OS on the other side...

I understand now, thank you.

Next question for Jeff: is your host (Windows) system a 32-bit build or a 64-bit build? If you're compiling for 64 bits with VS2008, but the standard luac you're using is compiled in 32-bit mode you'll get into trouble.

Best,

Bogdan