Reducing code size of eLua
Locked
12
12
|
Hi
I'm investigating how to reduce the size of the flash-rom image of eLua for a 128KB platform with 120KB available. I've already made some optimizations and found some size-reducing configurations, and would appreciate some input as to which parts of Lua are not relevant when the interpreter is running stand-alone instead of as a scripting language inside a larger program. I'm new to Lua and eLua and wouldn't want to remove some feature just because I don't understand it. My current list of hacks is: - configs: build lualong (no FP, saving 46KB!) - optram=0 - allocator=newlib (=simple is smaller but takes 5 seconds to start up) - enable CCFLAGS = ['-DLUAC_TRUST_BINARIES'] - reduce the huge number of strings in the Lua interpreter by simplifying some of the more verbose error messages (example: "too many results to unpack" and "too many results to resume" both become "too many results", which generates a single copy of the string) - replacing strerror with something that just prints the value of errno, so that the 3KB table of Unix system call error messages is not pulled in from the C library - disable lua 5.0 and 4.9 compatability flags - disable things which seem only to be used when Lua is included in a larger C program as an embedded scripting language: - parts of the debug interface (lua_{getupvalue,setupvalue,setlocal} - the hook interface Also, is the dump/undump code likely to be used in Lua applications? It seems to be used to write/read compiled Lua code to files or for transmission over the net, and to load precompiled Lua applications. Lastly, are the "bit", "pack" and "term" modules specific to eLua, hence unikely to be used in existing Lua applications? Other? Thanks M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Tue, Nov 30, 2010 at 4:34 PM, Martin Guy <[hidden email]> wrote:
> Hi > I'm investigating how to reduce the size of the flash-rom image of > eLua for a 128KB platform with 120KB available. I've already made some > optimizations and found some size-reducing configurations, and would > appreciate some input as to which parts of Lua are not relevant when > the interpreter is running stand-alone instead of as a scripting > language inside a larger program. I'm new to Lua and eLua and wouldn't > want to remove some feature just because I don't understand it. > > My current list of hacks is: > - configs: build lualong (no FP, saving 46KB!) Hmmm, only 46k? Is this coming from the absence of libm alone, or the compiler's floating point support is also not linked in the image? It shouldn't be, as I specifically tried not to use floats or doubles in the eLua source code. But it might be worth checking anyway, errors are always possible. > - optram=0 This is going to hurt you on the RAM side, big time. Also many modules from the eLua distribution don't work at all in this mode. How much space are you saving with this setting anyway? > - allocator=newlib (=simple is smaller but takes 5 seconds to start up) This is a bug, it doesn't have any good reason to do that. I'll take a look at it when I have some time. Might be something related to AVR32 being a big endian architecture, I never tested the simple allocator on big endian targets. > - enable CCFLAGS = ['-DLUAC_TRUST_BINARIES'] Thanks for this tip :) > - reduce the huge number of strings in the Lua interpreter by > simplifying some of the more verbose error messages (example: "too > many results to unpack" and "too many results to resume" both become > "too many results", which generates a single copy of the string) Does the linker optimize this globally? I thought this happens only at file object level. > - replacing strerror with something that just prints the value of > errno, so that the 3KB table of Unix system call error messages is not > pulled in from the C library Nice (and see my remarks at the end of this e-mail). > - disable lua 5.0 and 4.9 compatability flags Again, thanks for the tip. > - disable things which seem only to be used when Lua is included in a > larger C program as an embedded scripting language: Such as ? I'm curious. > - parts of the debug interface (lua_{getupvalue,setupvalue,setlocal} You might want to remove registration for the "debug" module altogether, it might save even more space. > - the hook interface If you remove the hook interface you won't be able to use Lua interrupt support on your platform. Which probably won't fit anyway :) so you're probably OK. > Also, is the dump/undump code likely to be used in Lua applications? > It seems to be used to write/read compiled Lua code to files or for > transmission over the net, and to load precompiled Lua applications. This is exactly what it is used for. You need it for romfs='compile' mode, for cross-compiling and maybe for LuaRPC (not sure about this last one). > Lastly, are the "bit", "pack" and "term" modules specific to eLua, > hence unikely to be used in existing Lua applications? "bit" and "pack" are taken from lhf's page (http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/) and chances are there are used in Lua applications, especially the "bit" module. "term" is 100% eLua specific. > Other? Did you remove all the BUILD_xxxx stuff that you don't need from platform_conf.h? What about all the modules that you don't need? In the end you can always restart what I tried to do a while ago and rewrite the C library, at least partially :) You don't even have to rewrite it. I was planning to include the Minix libc (you can find it in the Minix source tree) in eLua, as it is very small (and BSD licensed unlike other small libcs out there). It's perfectly doable, I just don't have the time to do it right now. Actually you started this yourself when rewriting strerror, so why not continue it? :) It always helps to have a size report on this. Try something like 'find . -name "*.o" | xargs avr32-size' and we can analyze that. Also, are you doing this for Mizar32? If so, is executing code from RAM not an option for you? Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
uOn Tue, Nov 30, 2010 at 3:52 PM, Bogdan Marinescu
<[hidden email]> wrote: > On Tue, Nov 30, 2010 at 4:34 PM, Martin Guy <[hidden email]> wrote: >> Hi >> I'm investigating how to reduce the size of the flash-rom image of >> eLua for a 128KB platform with 120KB available. >> ... >> My current list of hacks is: >> - configs: build lualong (no FP, saving 46KB!) > > Hmmm, only 46k? Is this coming from the absence of libm alone, or the > compiler's floating point support is also not linked in the image? It > shouldn't be, as I specifically tried not to use floats or doubles in > the eLua source code. But it might be worth checking anyway, errors > are always possible. libm is absent, yes, and looking at the binary I don't see any floating point emulation library functions, so you seem to have succeeded. >> - optram=0 > > This is going to hurt you on the RAM side, big time. That's ok, we have 32MB of RAM but only 120K flash. > Also many modules > from the eLua distribution don't work at all in this mode. How much > space are you saving with this setting anyway? Thanks. Do you know which and why? The saving is 4096 bytes. >> - reduce the huge number of strings in the Lua interpreter by >> simplifying some of the more verbose error messages (example: "too >> many results to unpack" and "too many results to resume" both become >> "too many results", which generates a single copy of the string) > > Does the linker optimize this globally? I thought this happens only at > file object level. It does. >> - disable things which seem only to be used when Lua is included in a >> larger C program as an embedded scripting language: > > Such as ? I'm curious. The following points were a list of them. I'm wondering if there are others. >> - parts of the debug interface (lua_{getupvalue,setupvalue,setlocal} > > You might want to remove registration for the "debug" module > altogether, it might save even more space. That's how I'm doing it, leaving the linker to optimise the unused functions and data out. >> Lastly, are the "bit", "pack" and "term" modules specific to eLua, >> hence unikely to be used in existing Lua applications? > > "bit" and "pack" are taken from lhf's page > (http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/) and chances are there > are used in Lua applications, especially the "bit" module. "term" is > 100% eLua specific. Good. They are relatively small. bit:1024 pack:2048 term: 2076 > Did you remove all the BUILD_xxxx stuff that you don't need from > platform_conf.h? What about all the modules that you don't need? Yes and yes. > In the end you can always restart what I tried to do a while ago and > rewrite the C library, at least partially :) You don't even have to > rewrite it. I was planning to include the Minix libc (you can find it > in the Minix source tree) in eLua, as it is very small (and BSD > licensed unlike other small libcs out there). It's perfectly doable, I > just don't have the time to do it right now. Actually you started this > yourself when rewriting strerror, so why not continue it? :) > It always helps to have a size report on this. Try something like > 'find . -name "*.o" | xargs avr32-size' and we can analyze that. The libraries -lgcc and -lc add 25600 of text (tested by linking without -lc -lgcc and with -r). That's an interesting idea. It's difficult to analyse from the .o files because a lot of code is compiled into the .o's and then eliminated by the linker. > Also, are you doing this for Mizar32? If so, is executing code from > RAM not an option for you? Yes and yes; we are also working on a small bootloader to load the executable from SDcard instead of flash to allow full FP lua with all modules. M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Tue, Nov 30, 2010 at 6:27 PM, Martin Guy <[hidden email]> wrote:
> uOn Tue, Nov 30, 2010 at 3:52 PM, Bogdan Marinescu > <[hidden email]> wrote: >> On Tue, Nov 30, 2010 at 4:34 PM, Martin Guy <[hidden email]> wrote: >>> Hi >>> I'm investigating how to reduce the size of the flash-rom image of >>> eLua for a 128KB platform with 120KB available. >>> ... >>> My current list of hacks is: >>> - configs: build lualong (no FP, saving 46KB!) >> >> Hmmm, only 46k? Is this coming from the absence of libm alone, or the >> compiler's floating point support is also not linked in the image? It >> shouldn't be, as I specifically tried not to use floats or doubles in >> the eLua source code. But it might be worth checking anyway, errors >> are always possible. > > libm is absent, yes, and looking at the binary I don't see any > floating point emulation library functions, so you seem to have > succeeded. > >>> - optram=0 >> >> This is going to hurt you on the RAM side, big time. > That's ok, we have 32MB of RAM but only 120K flash. Yes, I realised that after sending the e-mail :) > >> Also many modules >> from the eLua distribution don't work at all in this mode. How much >> space are you saving with this setting anyway? > > Thanks. Do you know which and why? The saving is 4096 bytes. I can make you a list if you want, or (even better) fix the ones that don't work. > >>> - reduce the huge number of strings in the Lua interpreter by >>> simplifying some of the more verbose error messages (example: "too >>> many results to unpack" and "too many results to resume" both become >>> "too many results", which generates a single copy of the string) >> >> Does the linker optimize this globally? I thought this happens only at >> file object level. > > It does. > >>> - disable things which seem only to be used when Lua is included in a >>> larger C program as an embedded scripting language: >> >> Such as ? I'm curious. > > The following points were a list of them. I'm wondering if there are others. > >>> - parts of the debug interface (lua_{getupvalue,setupvalue,setlocal} >> >> You might want to remove registration for the "debug" module >> altogether, it might save even more space. > > That's how I'm doing it, leaving the linker to optimise the unused > functions and data out. > >>> Lastly, are the "bit", "pack" and "term" modules specific to eLua, >>> hence unikely to be used in existing Lua applications? >> >> "bit" and "pack" are taken from lhf's page >> (http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/) and chances are there >> are used in Lua applications, especially the "bit" module. "term" is >> 100% eLua specific. > > Good. They are relatively small. bit:1024 pack:2048 term: 2076 > >> Did you remove all the BUILD_xxxx stuff that you don't need from >> platform_conf.h? What about all the modules that you don't need? > Yes and yes. > >> In the end you can always restart what I tried to do a while ago and >> rewrite the C library, at least partially :) You don't even have to >> rewrite it. I was planning to include the Minix libc (you can find it >> in the Minix source tree) in eLua, as it is very small (and BSD >> licensed unlike other small libcs out there). It's perfectly doable, I >> just don't have the time to do it right now. Actually you started this >> yourself when rewriting strerror, so why not continue it? :) >> It always helps to have a size report on this. Try something like >> 'find . -name "*.o" | xargs avr32-size' and we can analyze that. > > The libraries -lgcc and -lc add 25600 of text (tested by linking > without -lc -lgcc and with -r). Interesting. I would've guessed at least 50k. I believe you can do better with the lib from Minix, but I can't estimate how much better. > It's difficult to analyse from the .o files because a lot of code is > compiled into the .o's and then eliminated by the linker. True, but it still might give us some clues. > Yes and yes; we are also working on a small bootloader to load the > executable from SDcard instead of flash to allow full FP lua with all > modules. This is definitely what I'd do. Compiling eLua in less that 128k of Flash is an achievement, unfortunately what you're going to end up with is not a very useful product. It might work extremely well for very specific tasks, but for generic development you'll most certainly want more features. Which reminds me: another thing you might want to remote is the Lua parser. You'll end up with something that can only execute bytecode, but that might be acceptable for some. Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
> I can make you a list if you want, or (even better) fix the ones that
> don't work. Better indeed :) > Which reminds me: another thing you might want to remote is the Lua > parser. You'll end up with something that can only execute bytecode, > but that might be acceptable for some. That would mean that people would have to cross-compile Lua code on their PC, with all the system-dependent installation of the cross-compiler and framework. At present, they can just connect via serial port and type Lua code in; our objective is to let them write programs in Lua on an SD card in autorun.lua, put it in the board and have it work, thereby reducing the technical overhead, while loading precompiled code seems to me to be one of the things that can be removed at present for the 128K version. It's like a return to the late 1970s. You remember? When you turned the computer on and, even before the screen had warmed up, the computer was ready to use? That's my personal vision anyway. M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by BogdanM
On Tue, Nov 30, 2010 at 4:52 PM, Bogdan Marinescu
<[hidden email]> wrote: > On Tue, Nov 30, 2010 at 4:34 PM, Martin Guy <[hidden email]> wrote: >> Hi >> I'm investigating how to reduce the size of the flash-rom image of >> eLua for a 128KB platform with 120KB available. I've already made some >> optimizations and found some size-reducing configurations, and would >> appreciate some input as to which parts of Lua are not relevant when >> the interpreter is running stand-alone instead of as a scripting >> language inside a larger program. I'm new to Lua and eLua and wouldn't >> want to remove some feature just because I don't understand it. >> >> My current list of hacks is: >> - configs: build lualong (no FP, saving 46KB!) > > Hmmm, only 46k? Is this coming from the absence of libm alone, or the > compiler's floating point support is also not linked in the image? It > shouldn't be, as I specifically tried not to use floats or doubles in > the eLua source code. But it might be worth checking anyway, errors > are always possible. Heh. I found two places where references to floats/doubles are present even in lualong mode: the pack module (lpack.c) and the DumpNumber in ldump.c. I'll commit the patches soon (after I recheck that there aren't even more of those places). Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Tue, Nov 30, 2010 at 8:36 PM, Bogdan Marinescu
<[hidden email]> wrote: > Heh. I found two places where references to floats/doubles are present > even in lualong mode: the pack module (lpack.c) and the DumpNumber in > ldump.c. Cool. I didn't hit those as I have pack and dump disabled at present M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Tue, Nov 30, 2010 at 9:48 PM, Martin Guy <[hidden email]> wrote:
> On Tue, Nov 30, 2010 at 8:36 PM, Bogdan Marinescu > <[hidden email]> wrote: >> Heh. I found two places where references to floats/doubles are present >> even in lualong mode: the pack module (lpack.c) and the DumpNumber in >> ldump.c. > > Cool. I didn't hit those as I have pack and dump disabled at present The fixes are now on trunk. One thing that I forgot about and that might make a large impact on the code size is a printf/scanf library without floating point support. If you don't feel like replacing the whole libc, you can start with these two functions, I'm sure the effect will be quite visible. That said, even if you find some non-floating point printf/scanf code and write your own, I have no idea how easy is to persuade newlib to forget about its internal functions and use yours instead. I looked at some point and I found a long chain of calls related to prints/scanf in newlib, a chain that might be very hard to break (sorry, I don't remember the details right now). Note that you'll probably have to replace other functions (like strtod). Might be worth trying anyway. Before doing something so radical though, it could be easier to check if Newlib itself has a way to compile integer-only printf/scanf at least. I _vaguely_ remember that you could do this with Newlib by setting some macros at compile time. Damn it, I distinctly remember seeing a page (probably a wiki page) that listed the libc functions used in Lua, but I can't find it right now for the life of me. This might be very helpful. I'll try again tomorrow after I get some rest. Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Martin Guy
On Tue, Nov 30, 2010 at 13:17, Martin Guy <[hidden email]> wrote:
Or we could offer this as a simple web service too, targetet to all eLua supported platforms. The eLua Web Builder already offers the option to compile programs on ROMFS when generating the final binaries. It wouldn't be hard at all to offer only the compilation (byte code generation) step for the files. But yes, it is not as simple as to type a program directly into an SD/MMC. At present, they can just connect via ... or transfer a file via XMODEM. But unless you add some custom code to store them on an SD/MMC, the code currently goes only to RAM and is lost upon reset or power down. Remote File System, to be released on the next version of eLua, will add a lot to this scenario. our objective is to let them write thereby reducing the technical overhead, Right. But still mentioning the web-based dev, the future eLua Web Builder versions will likely offer a simple text editor to allow users to type directly their programs into the web service. But like you, I see this as an extra and not as a replacement of directly-on-the-MCUs based dev. while loading I don't see exactly how we could do that, unless we loose dofile(), dostring() ...... It's like a return to the late 1970s. You remember? I certainly do :) but Bogdan had not been link edited yet :) :) When you turned Sync. The new File Systems and other ways to remotely update code in them will add a lot to this too.
Thankssssssssss Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Wed, Dec 1, 2010 at 4:19 AM, Dado Sutter <[hidden email]> wrote:
> > > On Tue, Nov 30, 2010 at 13:17, Martin Guy <[hidden email]> wrote: >> >> > I can make you a list if you want, or (even better) fix the ones that >> > don't work. >> >> Better indeed :) >> >> > Which reminds me: another thing you might want to remote is the Lua >> > parser. You'll end up with something that can only execute bytecode, >> > but that might be acceptable for some. >> >> That would mean that people would have to cross-compile Lua code on >> their PC, with all the system-dependent installation of the >> cross-compiler and framework. > > Or we could offer this as a simple web service too, targetet to all eLua > supported platforms. > The eLua Web Builder already offers the option to compile programs on ROMFS > when generating the final binaries. It wouldn't be hard at all to offer only > the compilation (byte code generation) step for the files. > But yes, it is not as simple as to type a program directly into an SD/MMC. > >> At present, they can just connect via >> serial port and type Lua code in; > > ... or transfer a file via XMODEM. > But unless you add some custom code to store them on an SD/MMC, the code > currently goes only to RAM and is lost upon reset or power down. > Remote File System, to be released on the next version of eLua, will add a > lot to this scenario. I have a few ideas of how to make the ROM file system "less read-only", but I don't really like them. Then again, in the next release (not 0.8 that is due this month) we'll most likely have a new flash R/W file system. > >> >> our objective is to let them write >> programs in Lua on an SD card in autorun.lua, put it in the board and >> have it work, > > Yep. It works already for autorun.lc (Lua compiled bytecodes) too. > >> >> thereby reducing the technical overhead, > > Right. > But still mentioning the web-based dev, the future eLua Web Builder versions > will likely offer a simple text editor to allow users to type directly their > programs into the web service. That's nice, but I don't think it would work well in practice. I mean OK, you type them, but what about testing? The idea (well, MY idea :) ) behind eLua is to have a develop-run-test development cycle: write a small part of your program, test it on the spot, fix errors, continue. I don't personally see a real advantage in writing your programs inside the Web Builder as opposed to using a simple text editor. Sure, you skip the manual cross-compiling step, but you still can't test it properly. Which reminds me. I'm currently working on a standalone computer based on eLua, with video output, PS/2 keyboard support and (hopefully) a lot of other nice features. It's in early stages of development, but the main features are already planned. One of them is an integrated text editor, so the user will actually be able to use the forementioned develop-run-test cycle properly directory from his eLua board. This will not run properly on small boards, as it will require a lot of RAM, but it's very well suited towards system with external RAM such as the STM3210E-EVAL (which is what I'm currently using), ATEVK1100 and of course Mizar32 :) So I'm going to try to make this editor as generic as possible. Don't hold your breath though, it will be a long while until it's ready. > But like you, I see this as an extra and not as a replacement of > directly-on-the-MCUs based dev. > >> while loading >> precompiled code seems to me to be one of the things that can be >> removed at present for the 128K version. > > I don't see exactly how we could do that, unless we loose dofile(), > dostring() ...... He was talking strictly about _loading_. Lua will still work with bytecodes internally, you just won't be able to load them from a file system. > >> >> It's like a return to the late 1970s. You remember? > > I certainly do :) but Bogdan had not been link edited yet :) :) :) That's a nice way to put it. You're right; my earliest memories are from the late 80s, when my father managed to build me a HC-85 (a local clone of the ZX Spectrum) after quite a bit of struggle. I was in the second grade back then, and man, I had loads of fun with that machine, and I learnt a lot. I guess I'm somehow trying to replicate that process with my eLua computer project. I really believe it would make a wonderful educational platform and an equally nice automation platform. > Sync. > The new File Systems and other ways to remotely update code in them will add > a lot to this too. Not really applicable for Martin though, unless not in his stripped down version of eLua. Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Wed, Dec 1, 2010 at 05:38, Bogdan Marinescu <[hidden email]> wrote: ............................. Well, it is just a front-end enhancement for when we have a web-based simulator, which can be actual boards connected to the service for remote experimenting. But it is just an idea for now. The idea (well, MY idea :) Sure. It is just that some users seem to be hightly web-biased and we're trying to please them too :) Which reminds me. I'm currently working on a standalone computer based Very cool (and I wish you win some contests with it too :). Of course we'll hear some complains about the editor, as each developer has one of his choice and hates to death all the others :) But hey, we still try to please everyone :)
It will. Can't wait to see the specs to see if we can add some hardware in a modular way. But I'm afraid we'll have to wait until it's revealed by some contest results :) .......... Best, Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by BogdanM
On Wed, Dec 1, 2010 at 12:25 AM, Bogdan Marinescu
<[hidden email]> wrote: > One thing that I forgot about and that might make a large impact on > the code size is a printf/scanf library without floating point > support. eLua, when compiling for integers, already does this. See src/newlib/stubs.c and search "printf" Yes, Lua/eLua only use [fs]scanf to convert decimal integers, so we could lose it by using strtol/strtoul, at some cost in code legibility M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Wed, Dec 1, 2010 at 4:56 PM, Martin Guy <[hidden email]> wrote:
> On Wed, Dec 1, 2010 at 12:25 AM, Bogdan Marinescu > <[hidden email]> wrote: >> One thing that I forgot about and that might make a large impact on >> the code size is a printf/scanf library without floating point >> support. > > eLua, when compiling for integers, already does this. See > src/newlib/stubs.c and search "printf" LOL. Thanks, I completely forgot about that :) And of course I wrote that code myself ... Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Heh, I found something else by mistake, or rather by side-effect.
While disassembling the AVR32 eLua image to figure out where the floating point-related calls come from (in an integer-only configuration) I discovered that all C function calls were compiled to absolute calls, no relative calls whatsoever. This (besides completely killing my dreams of having loadable binary module support in AVR32) didn't really make sense to me, so I did a quick search for 'avr32 gcc options' and found Atmel AVR32006 appnote (www.atmel.com/dyn/resources/prod_documents/doc32074.pdf). It turns out that the compiler emits long calls and the linker doesn't try to optimize this by default, but it does if two options (--relax --direct-data) are added to its command line. With these new compiler flags and the patches I did yesterday I can actually compile the trunk version of eLua for mizar32 without having to fiddle with the configuration (which wasn't possible before this, the linker was still 512 bytes short). I'll commit the fix right after I send this message, I wanted to explain what I did first. Martin, this will certainly help you, I just don't know how much, but it might be more than you expect :) The trunk version that I compiled has 112128 bytes in .text, a long way from "region flash overflowed by 512 bytes". Best, Bogdan On Wed, Dec 1, 2010 at 4:58 PM, Bogdan Marinescu <[hidden email]> wrote: > On Wed, Dec 1, 2010 at 4:56 PM, Martin Guy <[hidden email]> wrote: >> On Wed, Dec 1, 2010 at 12:25 AM, Bogdan Marinescu >> <[hidden email]> wrote: >>> One thing that I forgot about and that might make a large impact on >>> the code size is a printf/scanf library without floating point >>> support. >> >> eLua, when compiling for integers, already does this. See >> src/newlib/stubs.c and search "printf" > > LOL. Thanks, I completely forgot about that :) And of course I wrote > that code myself ... > > Best, > Bogdan > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Wed, Dec 1, 2010 at 9:07 PM, Bogdan Marinescu
> (www.atmel.com/dyn/resources/prod_documents/doc32074.pdf). Thanks! > It turns > out that the compiler emits long calls and the linker doesn't try to > optimize this by default, but it does if two options (--relax > --direct-data) are added to its command line. Thanks. However I just added these in src/platform/avr32/conf.py: comp.Append(LINKFLAGS = [...,'--relax','--direct-data']) and it has made no difference whatever to size of the resulting flash image. In there somethjing else I'm missing? I have: # Standard GCC Flags comp.Append(CCFLAGS = ['-ffunction-sections','-fdata-sections','-fno-strict-aliasing','-Wall']) comp.Append(LINKFLAGS = ['-nostartfiles','-nostdlib','-Wl,--gc-sections','-Wl,--allow-multiple-definition','-T',ldscript,'--relax','--direct-data']) comp.Append(ASFLAGS = ['-x','assembler-with-cpp','-c']) comp.Append(LIBS = ['c','gcc','m']) M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Thu, Dec 2, 2010 at 1:34 AM, Martin Guy <[hidden email]> wrote:
> On Wed, Dec 1, 2010 at 9:07 PM, Bogdan Marinescu >> (www.atmel.com/dyn/resources/prod_documents/doc32074.pdf). > Thanks! > >> It turns >> out that the compiler emits long calls and the linker doesn't try to >> optimize this by default, but it does if two options (--relax >> --direct-data) are added to its command line. > > Thanks. However I just added these in src/platform/avr32/conf.py: > > comp.Append(LINKFLAGS = [...,'--relax','--direct-data']) > > and it has made no difference whatever to size of the resulting flash > image. In there somethjing else I'm missing? I have: > > # Standard GCC Flags > comp.Append(CCFLAGS = > ['-ffunction-sections','-fdata-sections','-fno-strict-aliasing','-Wall']) > comp.Append(LINKFLAGS = > ['-nostartfiles','-nostdlib','-Wl,--gc-sections','-Wl,--allow-multiple-definition','-T',ldscript,'--relax','--direct-data']) > comp.Append(ASFLAGS = ['-x','assembler-with-cpp','-c']) > comp.Append(LIBS = ['c','gcc','m']) I think it is mandatory to pass them with -Wl, like this: comp.Append(LINKFLAGS = ['-nostartfiles','-nostdlib','-Wl,--gc-sections','-Wl,--allow-multiple-definition','-Wl,--relax','-Wl,--direct-data','-T',ldscript]) Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Martin Guy
On Thu, Dec 2, 2010 at 12:34 AM, Martin Guy <[hidden email]> wrote:
> comp.Append(LINKFLAGS = [...,'--relax','--direct-data']) > > and it has made no difference whatever to size of the resulting flash > image. Got it. LINKFLAGS = [...,'-Wl,--relax','-Wl,--direct-data'] 121624 -> 110360 Nice one! M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Thu, Dec 2, 2010 at 12:47 AM, Martin Guy <[hidden email]> wrote:
> Got it. LINKFLAGS = [...,'-Wl,--relax','-Wl,--direct-data'] > > 121624 -> 110360 comp.Append(CCFLAGS = [...,'-fno-common'] 110360 -> 109300 :) M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Thu, Dec 2, 2010 at 1:55 AM, Martin Guy <[hidden email]> wrote:
> On Thu, Dec 2, 2010 at 12:47 AM, Martin Guy <[hidden email]> wrote: >> Got it. LINKFLAGS = [...,'-Wl,--relax','-Wl,--direct-data'] >> >> 121624 -> 110360 > > comp.Append(CCFLAGS = [...,'-fno-common'] > > 110360 -> 109300 Interesting, -fno-common didn't make any difference for me. What version of avr32-gcc are you using ? (i'm on 4.3.2) Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
>> comp.Append(CCFLAGS = [...,'-fno-common']
>> >> 110360 -> 109300 > > Interesting, -fno-common didn't make any difference for me. What > version of avr32-gcc are you using ? (i'm on 4.3.2) The same. I was going to say that if the code size change does not cross a 512-byte boundary, you may not see the number change, though in my case it's a 1KB difference so you should be seeing it. You *did* remove all .o files before re-running scons? M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |