Reducing code size

Hi,

I am using a 96KB ROM for my system but my code size now is exceeded the limit. I have tried to reduce the size by avoiding global variables however it did not help much. Appreciate if someone can point me what else I could do with the C language coding in order to fit the ROM.

Thanks in advance.

MC.

Reply to
tatto0_2000
Loading thread data ...

On 17 Apr 2007 19:04:09 -0700, tatto0 snipped-for-privacy@yahoo.com wrote in comp.arch.embedded:

What processor? What kind of program? What tool set? What are the requirements?

Based on the information you have provided, the best recommendation anybody could give you is to remove some of your code until the rest fits.

--
Jack Klein
Home: http://JK-Technology.Com
 Click to see the full signature
Reply to
Jack Klein

You're pretty light on information about your tool set.

If your tool set generates a map file, it is often instructive to look in there -- it will tell you about memory usage to at least some degree. Most linker/locators will generate a fairly detailed map file, which you can use to hunt down the biggest targets for code reduction.

Compile some of your code to assembly -- most compilers have a flag that lets you do this. If you're lucky you'll see C code interspersed with assembly, so you can get a feel for what doesn't take much room and what does. If you can make a tradeoff in your code of a simpler algorithm that takes longer, and if you can afford the extra time, change it.

See if your compiler optimizes for size. The Gnu tool chain lets you optimize for size or speed -- choosing to optimize for size may get you a few percent, or it may do no good at all depending on how well written your compiler back end is.

See if you have similar functions in different places that can be combined, possibly with an if-else to do the variant part. Sometimes good structured programming not only makes the code better, but makes the footprint smaller.

Check to see if you have a little bit of functionality that takes up a huge amount of space. If you have one printf call in your whole application, you can save a bunch of space by replacing it with simpler calls.

Check to see if there's any old code that's not doing anything any more. Are there obsolete features that you can safely remove? Debugging checks in code that hasn't misbehaved for years? A Doom port that no one ever uses any more :)? If you find them, remove them.

Good luck. A co-worker of mine used to call this "shaking the box" (contents may settle during shipping). She was good at it. Better her than me...

------------------- Tim Wescott Control systems and communications consulting

formatting link

Reply to
Tim Wescott

Tim's advice is good but I would add that it might be worth looking at any floating point airthmetic you might be using. If your processor can't handle it natively then the compiler will add in code to simulate it and that can take up a good bit of space. If you look at the calculation then, with a bit of thought, you can often keep the numbers as integers if you scale them up for the calulation and then scale them down again afterwards. This will be faster as well as smaller.

Of course, if you don't use floating point then this won't help much :-)

Reply to
Tom Lucas

Use -Os instead of -O[23] to optimize for size instead of speed. Add -ffunction-sections and -fdata-sections to the compiler command line, and add --gc-sections to the linker command line. That will discard any unused functions or variables.

You'll probably have to add a few --undefine= linker directive to make sure your startup code and maybe interrupt vectors don't get discarded.

--
Grant Edwards                   grante             Yow! You can't hurt me!!
                                  at               I have an ASSUMABLE
 Click to see the full signature
Reply to
Grant Edwards

In order of increasing cost/effort, the best thing to do is to:

  1. Remove all debugging code that can be defined out
  2. Select compiler/linker/library options to optimise for codesize
  3. Drop a non-essential feature from your code
  4. Buy a better compiler
  5. Rewrite parts of your code to minimise codesize

Wilco

Reply to
Wilco Dijkstra

And what exactly would be keeping you from going up to, say, 128 KB ROM?

What made you believe that reducing globals would help reduce code size?

Impossible to tell from what you write. You named neither the controller architecture, nor the controller, nor what the code is with those 96K right now.

Reply to
Hans-Bernhard Bröker

If you don't need floating point often a compiler will offer an integer version of things like printf, (in newlib its iprintf) these will have a significat savings.

Paul

Reply to
pbreed

The components are soldered on the PCB and I guess if I change it to

128KB, I will need to change the PCB.

I am sorry to make you confuse, I was refering to 'constant' global variable. :-)

I am using 68K microcontroller. The microcontroller controls the I/O and a bitmap LCD.

Thanks for reply.

Reply to
tatto0_2000

So you have three 32 KiB ROMs to get 96 KiB ROM, so it must be a quite old design. Where do you get such small memories these days ?

With any significant production volumes, it would make economically sense to redesign the board for a single 128 KiB or even 256 KiB ROMs and also get rid of some chip select logic.

With very small production volumes, you might find a chip with larger capacity but similar pin connections (e.g. extra address lines instead of extra chip selects) and the problem can be solved with a few track cuts and soldering a few jumpers.

For non-structured variables (such as bytes and words), a good compiler would use immediate addressing modes instead of loading from a constant global value. For structured types, creating some non-zero initial values into RAM once at the initialisation phase before main() would be more cost effective than using separate initialisations at function entry, if the same structure is used in many functions.

Paul

Reply to
Paul Keinanen

... and while at it, you'll probably even save some money. Memory chips this small hit the "minimum usefully producible size" a long time ago. Odds are a single 256 KiB flash will be cheaper than the 3 32KiB ones you're using right now --- and save PCB space while at it.

Well, bitmap graphics is memory-hungry. Depending on details (mainly on how much CPU horsepower you've got left to burn), it may be possible to substitute bitmap constants (icons, fonts, whatever) by vector graphics.

C coding tricks are unlikely to help you with achieving considerable code size reduction. But be sure to have a close read of your compiler's manual, and maybe even consider changing compilers.

Reply to
Hans-Bernhard Bröker

OM?

s=20

Besides, if this memory has to be used for the bitmap storage, it can be =

implemented as an external serial flash. This is a minimum hassle.

n=20

=20

=2E

The bitmaps can be stored in the compressed form and unpacked only as=20 needed. Bitmaps are very compressible as a rule. Even the simplest RLE=20 or LZSS will provide for the significant space saving. This is much=20 faster and simpler compared to the vector graphics.

Well. There are amazingly many people who know of only one way of code=20 reuse: copy and paste :-)

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

I can attest to the difference RLE makes - and it's really pretty simple to implement too. This link helped me when I did it -

formatting link
- although it seems to have rotted somewhat since I last looked at it. I would guess most of your pictures are whitespace and RLE chops those down really well. I found RLE8 easier and faster to render than RLE4 mainly because it fits more nicely into byte variables.

Reply to
Tom Lucas

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.