That deserves a story, too. Why not?
[Note: this is the early 80s. A computer with a large amount of memory might have 64K in this period. I think a 64K ROM cost about four dollars, and 64K of RAM was about fifty bucks]
The Atari ST's operating system (TOS, and no I don't want to talk about what that stands for) was written in C and assembly language.
Initially the ST was going to have 128K of ROM; we wanted to one-up the Macintosh (which hadn't shipped yet, but there were rumors and we had copies of Inside Macintosh that were simply fascinating to read) and put both our OS and a version of BASIC in ROM. Most home computers at the time came with some version of BASIC, and the Mac did not; we were hoping that would be a differentiator. Trouble was, nobody had actually sized our software yet (the only things even remotely running were on the 8086, not the 68000 we were going to use, and Digital Research wasn't exactly forthcoming about details anyway).
So mid-October (the project started in earnest in July 1984, and FWIW we shipped in late May 1985, a whole new platform starting from zero in less than ten months) we realized that just the OS and GUI would be 128K, and that the BASIC we were thinking of using was like 80K (but could probably be shrunk). So the hardware guys added two more ROM sockets, for 192K of ROM. A month went by. Wups! -- it turned out that the OS and GUI would be like 170K, with little hope of shrinkage. No, make that 180K. Would you take 200K?
The code topped out at 210K or so, and that wouldn't even fit into the six ROM sockets we now had. No chance in hell of getting another 64K of ROM -- that stuff costs real money -- so we shrunk the code. The team from Atari came from a background of writing things that fit into really tiny amounts of ROM, so we went about this with a fair amount of glee. We got about 1K per programmer per day of tested code savings by ripping out unused functions, fixing all the places where people had "optimized" things by avoiding the expense of strlen or whatever, and coding some common graphics calls with machine trap instructions instead of fatter JSRs. For about a week, the hallway in engineering was full of people calling out to other offices, "Wow, get a load of this stupid routine!" and in a codebase that had been tossed together as quickly as GEM/TOS had been, there was no lack of opportunity for improvement. We found a fair number of bugs doing this, too.
Additionally, the C compiler we were using was not very good, and even its "optimized" code was terrible. Fortunately it had an intermediate assembly language stage, so we wrote some tools to optimize that intermediate code (mostly peephole stuff, like redundant register save/restores) and got a relatively easy 10-12 percent savings. I think we had a few hundred bytes of ROM left on the first release.
I remember that 192K pretty darned well. Though they're fun to talk about, I honestly don't miss those days much; today I wrote the equivalent of
void *p = malloc( 1024 * 1024 * 1024 );
and I didn't even feel bad.