RE: Byte code compiling question

Hi

I was pondering another related question on this topic that someone might be able to shed some light on ?

In my system I have 2 Lua tasks that run totally independently, they are mutually exclusive however, so when the other Lua state needs to run, I shut down the current task and Lua state and start up a new task and a new Lua state. This simple scheme works OK, but now both my 2 Lua scripts are getting quite large, it is not a very efficient way of doing things, as every time I need to toggle between tasks, I have to spend 2 seconds or so reloading from flash and recompiling the Lua script.
Lets assume for a moment, I am not switching to use binary files so I was wondering, is there a way I can cache the compiled script to ram so that the 2nd and subsequent times I toggle I can just reload a chunck of memory from a ram cache and save most of the 2 seconds ? I dont know if this is possible, as I dont know where the first compilation stores the compiled program in ram and how many bytes in length it is (assuming it compiles to one contiguous block)

Is this a sensible approach, or are there better ways to make this more efficient ? Thanks for any suggestions

Regards Geoff

From: spammealot1@live.co.uk
To: lua-l@lists.lua.org
Date: Fri, 7 Oct 2011 23:44:36 +0100
Subject: 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