Programmers working with modern compilers and tools and in what are comparatively resource-rich environments often haven't had to bum instructions and bum bytes.
In (most) modern environments, the optimizations are toward maintenance and support and speed of programming. Not toward memory optimizations.
All sorts of bizarre constructs can be commonplace when you are looking to stuff an application into a tiny ROM or tiny RAM; into 32 KB main RAM memory that was commonplace on a number of systems years ago, for instance. This using instructions as data storage for constants, modifying the return pointer in the call stack, using instruction side-effects, and otherwise.
When you're at the edge of needing a bigger (and then far more expensive) ROM or falling out of available memory or needing to switch over to overlaid segments or other run-time hackery, getting a dozen bytes back somewhere could be a big deal.
Some of these coding techniques can be appropriate in and still show up in very tight loops and embedded applications, but they're far less common now.
And thankfully, cheap "large" physical memory and virtual memory means we seldom have to deal with anything like TKB and its overlays:
I recently had to do this for an embedded processor. 1920 bytes to fit some controller code in. It was a ton of fun, to the point where one of my cow-orkers found himself compelled to help out. I think we're at around 20 bytes free right now.
"I managed to save three bytes here."
"My God, you're a sick person. I love it."
Then I went back to my "day job" data mining a couple dozen terabytes of stuff in a database.
This is called "code golf". You try to get the final program with the minimum of "shots" (bytes, lines, tokens or characters). It's amusingly addictive.
And I really hope you misplaced that hyphen in "cow-orkers".
Even today, squeezing your code and data so it fits within your processor's L1 cache can give you a very significant performance boost.
When I was developing educational software for Apple II computers in the mid-80's, one program we did had, at a given moment, 43-and-half bytes of free memory in the whole machine. The half byte is there because we were using that byte, but the counter wouldn't exceed 12, so we had 4 bits we could use for something else.
But my most impressive feat there was a graphics window-overlay library that used RLE to store obscured regions and was implemented in less than 1K of 6502 code. If you didn't want to preserve color information, it would shave one bit off every byte of screen data (increasing RLE efficiency)
In (most) modern environments, the optimizations are toward maintenance and support and speed of programming. Not toward memory optimizations.
All sorts of bizarre constructs can be commonplace when you are looking to stuff an application into a tiny ROM or tiny RAM; into 32 KB main RAM memory that was commonplace on a number of systems years ago, for instance. This using instructions as data storage for constants, modifying the return pointer in the call stack, using instruction side-effects, and otherwise.
When you're at the edge of needing a bigger (and then far more expensive) ROM or falling out of available memory or needing to switch over to overlaid segments or other run-time hackery, getting a dozen bytes back somewhere could be a big deal.
Some of these coding techniques can be appropriate in and still show up in very tight loops and embedded applications, but they're far less common now.
And thankfully, cheap "large" physical memory and virtual memory means we seldom have to deal with anything like TKB and its overlays:
http://wjh.conflux.net:16080/RSTS-V9/documents/DEC/AA-5072C-...