lua-users home
lua-l archive

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


Jay,

Excellent info!  Here's some points:
MCrowe@MCrowe lib $ nios2-elf-size /tmp/lua.o
   text    data     bss     dec     hex filename
 111152    1261       0  112413   1b71d /tmp/lua.o
MCrowe@MCrowe lib $ nios2-elf-size --total `flib c` | tail -1
 153213    3066     748  157027   26563 (TOTALS)

Therefore (I think), most of the uClibc is getting pulled in, right?
Since this is an embedded system, I was trying to determine what flash memory size lua was going to take up.
I see what you mean about sprintf and the -nm command.  I'm looking through that now.

uClinux does not have an MMU, so I'm stuck with static, I guess.  Currently, we only offer C/C++ as languages, and I wanted to offer a higher level language, and lua appears to be it. 

I'm hoping that Lua + compiled lua-code will be better than porting a JVM to language.  Thoughts?

Thanks, Jay!
Mike

Jay Carlson wrote:
Mike Crowe writes:

  
MCrowe@MCrowe lua $ l lib
total 128
-rw-rw-rw-    1 MCrowe   mkpasswd   130638 Oct 19 21:59 liblua.a
-rw-rw-rw-    1 MCrowe   mkpasswd    92316 Oct 19 21:59 liblualib.a
MCrowe@MCrowe lua $ l bin
total 395
-rw-rw-rw-    1 MCrowe   mkpasswd   403948 Oct 19 21:59 lua
MCrowe@MCrowe lua $
    
"I don't see the problem." 

Oh, you mean that it's much bigger than you expected?  My guess is that it's
pulling in substantial parts of libc and libm.  That's not surprising, given
that one of Lua's informal missions is to use every part of ANSI libc and
libm.

I'm guessing your architecture doesn't have dynamic loading for shared
libraries.  FWIW, it's not that hard to write a dynamic loader; I did one
for mipsel-linux for PDAs a while ago.  Lemme know if you want hints.
Dynamic linking, OTOH, is No Fun.

....ohhh, you don't have an MMU.  Ugh.  Shared libraries are going to need
toolchain support if not source modifications.  I can get paid for that
level of work since it, as well, is No Fun.

(I believe my last message to the list included criticism on the basis of
fun, so I feel like I'm allowed to spam that word some more.)

For fun, try running these commands:

# Find the absolute path of a shared library
flib () { nios2-elf-gcc -print-file-name=lib$1.a ; }
# Partially link lua and lualib, resolving all internal references
nios2-elf-ld -r --whole-archive `flib lua` `flib lualib` -o /tmp/lua.o
# Get the actual linkable size of that
nios2-elf-size /tmp/lua.o
# Compare with libc:
nios2-elf-size --total `flib c` | tail -1
# Browse through the functions Lua is calling for in libc
nios2-elf-nm /tmp/lua.o | grep ' U ' | more

After that, you'll have to start hunting through linker maps to see how Lua
calling for sprintf drags in huge chunks of other libc stuff.  

In general, you get more geek points if you complain about bloat via the
size command rather than ls, which includes lots of other overhead which may
or may not affect execution size.

Did you already get rid of the libm dependencies?

Jay

  


--
Signature
In Him, Mike
Fish