tiny ram patch and luac cross question

[Dean Hall]

Bogdan, I understand a little about how the tiny ram patch works, but  
not fully.  My question is, does the luac cross-compiler (luac) need  
to know about the tiny ram changes (my intuitions says yes)?  If so,  
the script cross-lua.py seems to be missing the new source files from  
the tiny ram patch that are in src/lua.  Also, I would appreciate it  
if you could explain how to use cross-lua.py.

!!Dean

[BogdanM]

Hi,

Interesting question, I didn't try this. It shouldn't matter at all,
as the bytecode is exactly the same, only its interpretation differs
with LTR. But of course, we need to test this first.
As for the instructions on cross-lua.py, look at the attached file. It
used to be in the docs/ subdirectory, but something wrong happened to
it after we converted the docs (it's still in the PDF, only very well
hidden and with a very bad formatting).

Best,
Bogdan

On Wed, Jan 28, 2009 at 4:59 AM, Dean Hall <dwhall256 at gmail.com> wrote:

> Bogdan, I understand a little about how the tiny ram patch works, but
> not fully.  My question is, does the luac cross-compiler (luac) need
> to know about the tiny ram changes (my intuitions says yes)?  If so,
> the script cross-lua.py seems to be missing the new source files from
> the tiny ram patch that are in src/lua.  Also, I would appreciate it
> if you could explain how to use cross-lua.py.
>
> !!Dean
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>

-------------- next part --------------
(NOTE: view this file with a monospaced font)

Cross-compiling Lua programs
================================================================================
"Cross compilation" is the process of compiling a program on one system for a
different system. For example, the process of compiling the eLua binary image on
a PC is cross-compiling. Lua can be cross-compiled, too. By cross-compiling Lua
to bytecode on a PC and executing the resulting bytecode directly on your eLua
board you have two advantages:

- speed: the Lua interpreter on the eLua board doesn't have to compile your Lua
  source code, it just executes the compiled bytecode
- memory: this is more important. If you're exectuing bytecode directly, no more
  memory is "wasted" on the eLua board for compiling the Lua code to bytecode.
  Many times this could be a "life saver". If you're trying to run Lua code
  directly on your board and you're getting "not enough memory" errors, you
  might be able to overcome this by compiling the Lua program on the PC and
  running the bytecode instead.

But for this cross-compilation to work, the two Lua targets must be compatible
(they should have the same data types, with the same size, and the same memory
representation). This isn't completely true for Intel and ARM targets, as gcc
for ARM uses a very specific representation for double numbers (called FPA
format) by default, which makes bytecode files generated on the PC useless on
ARM boards. To overcome this, a "Lua cross-compilation" patch was posted on the
Lua mailing list a while ago, and it was further modified as part of the eLua
project to work with ARM targets. This is how to use it (the following
instructions were tested on Linux, not Windows, but they should work on Windows
too with little or no tweaking):

- first, make sure that your PC has already a build system intalled (gcc,
  binutils, libc, headers...). You'll also need "scons". The good news is that
  you should have it already installed, since otherwise you won't be able to
  build even regular eLua.

- from the eLua base directory, issue this command:

  $ scons -f cross-lua.py

  You should get a file called "luac" in the same directory after this.

- to compile your Lua code (in <source>.lua), issue this command:

  $ ./luac -s -ccn float_arm 64 -o <source>.luac <source>.lua
  if you're using "regular" (floating point) Lua, or:

  $ ./luac -s -ccn int 32 -o <source>.luac <source>.lua
  if you're using int-ony Lua.

- that's it! You can use the resulting file (<source>.luac) in two ways:

  - "recv" it (docs/the_elua_shell.txt)
  - copy it to the ROM file system (docs/the_rom_file_system.txt)

[jbsnyder]

Does this cross-compiler know how to compile things correctly  
depending on the endianness of the target?  If so, is that implicit by  
the target?

I assume most of the ARM targets are running in little endian mode  
(though, at least some should support data in either direction), but I  
seem to recall that AVR32 is big endian.

-jsnyder

On Jan 28, 2009, at 2:29 AM, Bogdan Marinescu wrote:

> Hi,
>
> Interesting question, I didn't try this. It shouldn't matter at all,
> as the bytecode is exactly the same, only its interpretation differs
> with LTR. But of course, we need to test this first.
> As for the instructions on cross-lua.py, look at the attached file. It
> used to be in the docs/ subdirectory, but something wrong happened to
> it after we converted the docs (it's still in the PDF, only very well
> hidden and with a very bad formatting).
>
> Best,
> Bogdan
>
> On Wed, Jan 28, 2009 at 4:59 AM, Dean Hall <dwhall256 at gmail.com>  
> wrote:
>> Bogdan, I understand a little about how the tiny ram patch works, but
>> not fully.  My question is, does the luac cross-compiler (luac) need
>> to know about the tiny ram changes (my intuitions says yes)?  If so,
>> the script cross-lua.py seems to be missing the new source files from
>> the tiny ram patch that are in src/lua.  Also, I would appreciate it
>> if you could explain how to use cross-lua.py.
>>
>> !!Dean
>> _______________________________________________
>> Elua-dev mailing list
>> Elua-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
> <crosscompilation.txt>_______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev

--
James Snyder
Biomedical Engineering
Northwestern University
jbsnyder at fanplastic.org
http://fanplastic.org/key.txt
ph: [phone]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090128/ad11008c/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : https://lists.berlios.de/pipermail/elua-dev/attachments/20090128/ad11008c/attachment.pgp 

[BogdanM]

You need to tell him what architecture you're expecting on the command line:

bogdan at bogdan-virtual:~/work/elua/trunk$ ./luac
./luac: no input files given
usage: ./luac [options] [filenames].
Available options are:
  -        process stdin
  -l       list
  -o name  output to file 'name' (default is "luac.out")
  -p       parse only
  -s       strip debug information
  -v       show version information
  -cci bits       cross-compile with given integer size
  -ccn type bits  cross-compile with given lua_Number type and size
  -cce endian     cross-compile with given endianness ('big' or 'little')
  --       stop handling options

"type" in -ccn type can be "int", "float" or "float_arm" (this is needed for
ARM achitectures in FPA mode, which seems to be the default, the
documentation on this is pretty bad).

Best,
Bogdan

On Wed, Jan 28, 2009 at 10:03 PM, James Snyder <jbsnyder at fanplastic.org>wrote:

> Does this cross-compiler know how to compile things correctly depending on
> the endianness of the target?  If so, is that implicit by the target?
>
> I assume most of the ARM targets are running in little endian mode (though,
> at least some should support data in either direction), but I seem to recall
> that AVR32 is big endian.
>
> -jsnyder
>
> On Jan 28, 2009, at 2:29 AM, Bogdan Marinescu wrote:
>
> Hi,
>
> Interesting question, I didn't try this. It shouldn't matter at all,
> as the bytecode is exactly the same, only its interpretation differs
> with LTR. But of course, we need to test this first.
> As for the instructions on cross-lua.py, look at the attached file. It
> used to be in the docs/ subdirectory, but something wrong happened to
> it after we converted the docs (it's still in the PDF, only very well
> hidden and with a very bad formatting).
>
> Best,
> Bogdan
>
> On Wed, Jan 28, 2009 at 4:59 AM, Dean Hall <dwhall256 at gmail.com> wrote:
>
> Bogdan, I understand a little about how the tiny ram patch works, but
>
> not fully.  My question is, does the luac cross-compiler (luac) need
>
> to know about the tiny ram changes (my intuitions says yes)?  If so,
>
> the script cross-lua.py seems to be missing the new source files from
>
> the tiny ram patch that are in src/lua.  Also, I would appreciate it
>
> if you could explain how to use cross-lua.py.
>
>
> !!Dean
>
> _______________________________________________
>
> Elua-dev mailing list
>
> Elua-dev at lists.berlios.de
>
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>
> <crosscompilation.txt>_______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>
> --
> James Snyder
> Biomedical Engineering
> Northwestern University
> jbsnyder at fanplastic.org
> http://fanplastic.org/key.txt
> ph: [phone]
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090129/f8e0b82d/attachment.html