Put some code-space in your "savings account"!

A project log for limited-code hacks/ideas

When you're running out of code-space... sometimes yah's gots to hack. Here are some ideas.

eric-hertzEric Hertz 11/28/2016 at 03:105 Comments

This may seem a bit ridiculous, but believe me, it's turned out useful *quite-often* when expecting a project might eventually reach code-space limitations...

Throw something "big" in your project that doesn't do anything important... At the very start of the development-process. E.G.:

char wastedSpace[80] = { [0 ... 78] = 'a' };

Hide it somewhere so you forget about it... Then when your project has gone from 512B to 960B, and suddenly in the next-revision it's gone from 960 to 1025... You'll go "oh sh**", then probably start looking at your code trying to figure out some ways to make it smaller... (maybe a good thing)... Then eventually you might step-back a bit frustrated and... eventually... remember that there's a sizable chunk you can take out with no consequences whatsoever, and continue your progress without having to change anything already-functional. Consider it a terrifying--and then relieving--warning.

This example works for both program-memory as well as RAM... But there are other ways to do similar, and may even be useful in the meantime. E.G. I usually throw in a fading "heartbeat" LED... That code can be removed, entirely, from my project by merely defining HEART_REMOVED, regaining a few hundred bytes on the spot, and rendering a project which would've stalled due to a few bytes to one which can [cautiously] continue development for quite some time thereafter.

(NOTE that SOME OPTIMIZERS might look at something like the above and recognize that it's never used, then "optimize it out". So, keep that in mind... Some other methods might be to e.g. throw something in PROGMEM. Might be a good idea to write an empty project, compile it, look at the code-size, then add your "savings account" and make sure that code-size increases as expected).

Another thing I regularly do that "uses up space" is to throw project-info into the Flash-memory in a *human-readable* format... That way I can, years down the line, read-back the flash-memory from a chip and determine things like which project it is, which version-number, and what date it was compiled on... That info is definitely useful later down the road, but not *essential*, so potentially hundreds of bytes can be removed by removing that information. (That information is automatically-generated into "projinfo.h" by my 'makefile', and projinfo.h is then #included in main.c... so to remove it, just comment-out that #include.)


Yann Guidon / YGDES wrote 11/28/2016 at 03:14 point

I agree about the "human format" data in EEPROM :-)

However I don't agree about the "savings account". Yet I suspect this explains why many software projects turn into bloatware. I'll have to find a developer from M$ to be sure. That, plus the Ballmer Peak should solve a few mysteries...

  Are you sure? yes | no

Eric Hertz wrote 11/28/2016 at 04:25 point

Oh man... You're spot-on about "bloatware"...

Good lord, if people used [m]any of these techniques for e.g. libraries or operating-systems... we'd all be screwed. (or already are). 

Though, I suspect much of the "bloatware" we experience has more to do with layer-upon-layer of feature-creep than people intentionally throwing in "savings accounts" (who'd do that unless they had a very specific *hardware*-limitation?). 

Remember the good'ol'days of "Easter-Eggs?" Now that was a golden era, and somehow they managed to fit 'em in programs that fit on floppy-disks! Whatever happened to those...?

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/28/2016 at 04:30 point

People don't have time for this anymore. Make it work, ship and get paid.

  Are you sure? yes | no

Eric Hertz wrote 11/28/2016 at 04:41 point

@Yann Guidon / YGDES ain't that an unfortunate metaphor (simile?) for life.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/28/2016 at 04:51 point

But... Code is Life !

  Are you sure? yes | no