> 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. Er, that reminds me, I missed some stuff in the doc about removing Java support... sigh. > 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. > 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. > 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. > 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. ------------------------------------------------------------------------------ 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
