On 06/03/14 17:34, DJ Delorie wrote: > >> Even if you have the smallest mps430 with 512 bytes flash, it does >> not matter if your program is 24 bytes or 511 bytes - all that >> matters is that it fits in the chip you have. > > If the startup is more than 512 bytes, it matters a lot. If you only > have 512 bytees of code space and you discover your project doesn't > fit because of a couple hundred bytes of Java support, is that OK? > Probably not. This is the type of thing we're trying to avoid. The > GCC runtime supports *everything* GCC could do, but most project don't > need everything.
OK, if it is /that/ much space then it's a completely different matter. I thought we were just talking about clearing the bss and setting the initialised data, which should just be a couple of short simple loops. > > Er, that reminds me, I missed some stuff in the doc about removing > Java support... sigh. It never occurred to me that there might be java support there - I doubt if anyone will miss it. Perhaps more relevantly, what about C++ support? msp430 developers will need some basic C++ support, including global constructors - but can usually do without global destructors, support for unhandled exceptions (or any exceptions or RTTI), etc., which can otherwise take up a lot of code space. And I expect Ada support is on your things-to-do list as well, in case you get bored! > >> But if there /are/ costs - which can include lots of confusing >> unnecessary symbols in map files and debugger sessions - then it is >> not clear that saving a couple of bytes is worth it. > > There are already a lot of confusing symbols in the raw dumps, but > they won't confuse the debugger or the programmer. The ones that > confuse the debugger are definitions of symbols, whereas these are > references to symbols. Fair enough. Sometimes I have occasion to look through map files and other "raw dumps" in my embedded development, such as to figure out why lots of library code has been linked in, so I dislike extra symbols if they are not important. But if this system saves as much startup code as you say, then the extra symbols are a very small price to pay. > >> And since most embedded programs do not return from main(), then >> size optimisations based on that are worthwhile. > > Especially since an ISO-compliant exit() has a lot of work to do. Indeed. On some systems (not gcc on the msp430), I have had to resort to making empty stub functions for exit() and a few other library functions in order to avoid massive library imports. > >> Ultimately, rather than having compiler flags "optimise for space" or >> "optimise for speed", what we /really/ want is "give me the fastest >> possible code that takes no more space than I have on the chip". Maybe >> that will come in gcc 5.0 :-) > > Given that the compiler (which does the optimization) and the linker > (which knows how big the image is) are separate projects, I doubt > you'll ever see this. Yes, I know - even if they were combined, the task would be impossible. > >> Will the __intN stuff ever make it into mainline? > > That's the plan. It's been officially deferred until 4.10's cycle but > the reviews so far have been positive. Fantastic. Thanks for all your work here. I haven't started using the new port - I don't like to change toolchains in the middle of a project - but I am looking forward to it for the future. The fact that Red Hat and TI are working together on this has bumped up the msp430 significantly as a processor choice at my company. David ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
