 |
lua-l archive |
|
|
||
|
|
Hi Sam
My C Source code generator doesnt currently output a matching header file, but yes your suggestion would work too. I did think of doing it that way, I might well go that route when I get around to doing the modification. > , and not really faster to load (and if you are loading > code in a critical speed path, you probably shouldn't be). The reason I am doing this is because I am using a slow embedded processor, it should give me a noticeably faster load time. I cant quote any figures yet but I am sure it will be a reasonable improvement. My flash read speed isnt that stellar, so just the fact of halving the amount of data to be read from flash will give a good speed up during the load time. (with additional benefit of saving some flash space) Jeff > From: vieuxtech@gmail.com > To: lua-l@lists.lua.org > Subject: Re: Need a bit of help with a lua loading problem please > > On Tue, Jun 5, 2012 at 10:31 AM, Jeff Smith <spammealot1@live.co.uk> wrote: > > its a bit of a pain to resolve neatly as I think I need to rewrite my > > external conversion utility so that if its input file is a lua source file > > (text) then it writes the C file out as Null terminated string (in source > > code form). Conversely if it sees the input file is a lua binary chunk it > > It can write both the .c and the .h as output from the processing: > > .h: > > #define MY_FILE_NAME "/whatever" > #define MY_FILE_SIZE 192 > extern char MY_FILE_DATA[]; > > > Btw, you didn't say why you are doing this. The only reason to > pre-compile chunks, really, is because you've stripped the parser out > of your lua vm. byte code is less portable, harder to deal with (as > you've found), and not really faster to load (and if you are loading > code in a critical speed path, you probably shouldn't be). > > Cheers, > Sam > |