I'm focussing on code written in C... So... If you have a project *just exceeding* 1024 Bytes, some of these ideas may be useful for squeezing a little more outta it.
Before looking here, maybe check this document first. (Thanks, [Volt], in the comments!)
The following may just be utterly-ridiculous... I'm no expert, here... And this list is in no way sorted, nor all-inclusive, and may in fact be missing some *really* important things like using lookup tables rather than math, and using direct register-writes rather'n libraries (e.g. see @Radomir Dopieralski's logs over at #Nyan Board and #Mechatronic Ears)
Take the ideas here with a grain of salt!
I'll probably aim my efforts at AVRs, but there are *definitely* some
concepts, here that apply, as well, to other architectures (and some
that don't apply *at all* to AVRs) So... steal some ideas!
Oh, and, Good Lord... @Yann Guidon / YGDES pointed out something quite important...
This shizzle is in *no way* intended to be considered "good practice". Don't get into these habits! Don't use these as general-purpose guidelines of any sort! And, for goodness sake, don't use these techniques in any sort of "product" (library, operating-system, pace-maker, or anything else) unless you've *really* thought-through *all* the potential-consequences, slept on it for months, then thought through them again. But, realistically, that goes for any sort of coding, whether you use these techniques, or not.
Fergodsakes, we're talking about a friggin' contest, here. It's supposed to be *fun* and encouraging of creativity. And this "project-page" is intended for no other purpose than to allow a creative person to continue with their fun project once they've hit what might otherwise seem like a show-stopping ceiling.
Calculate your (AVR) project's program/flash-memory requirements via "avr-size":
Squeeze some bytes out of your project by (in no particular order):
- Moving to a similar, but slightly-different architecture (E.G. AVR "Tiny" -> "Mega") https://hackaday.io/project/18574-limited-code-hackstips/log/49537-avr-project-doing-nada-58bytes-and-some-experimentsresults (The same miniscule amount of code (100 Bytes) compiled for a TinyAVR requires 4 Bytes (4%!) less code-space when compiled for a MegaAVR! A larger project may scale accordingly, e.g. a 1000Byte TinyAVR project may require only 960 Bytes on a MegaAVR, plausibly even less, given other functionality such as Mult-instructions)
- Considering whether you really need both initialized and "uninitialized" globals/statics -- a bit ridiculous, just an interesting discovery. https://hackaday.io/project/18574-limited-code-hackstips/log/49537-avr-project-doing-nada-58bytes-and-some-experimentsresults (Save up to 22 Bytes by *really* analyzing all your globals/statics)
- Making Certain that stdio is not linked into your project -- This is probably a requirement, if you intend on fitting in 1K... Though, it most-likely is already be the case if your project is anywhere *near* fitting in 1K. https://hackaday.io/project/18574-limited-code-hackstips/log/49498-avrs-stdio-printf-etc (This could save your project nearly 1kB (1024 Bytes!), or even more!, of program-space, if you're lucky, and it's done-correctly!)
- Reconsidering Multiplication/Division -- Poorly written, the basic jist is to have an idea of how these calculations work and think of ways to make them more efficient (do you really need x/65, or would x/64 work well-enough? Save a *lot* of code-space by doing-so!) https://hackaday.io/project/18574-limited-code-hackstips/log/49548-multiplication-division
- Considering your usage of volatiles -- If you're *certain* you don't need them you could save a lot of code-space. https://hackaday.io/project/18574-limited-code-hackstips/log/49551-volatiles (This is NOT to be taken lightly!)
- Using separate Numerator/Denominator variables, rather than floats...