Slashdot Mirror
Smallest Possible ELF Executable?
taviso writes "I recently stumbled across this paper (google cache), where the author investigates the smallest possible ELF executable on linux, some interesting stuff, and well worth a read. The author concludes, 'every single byte in this executable file can be accounted for and justified. How many executables have you created lately that you can say that about?'
It isn't amazing until its also palindromic!
The only good weather is bad weather.
I just heard the news on slashdot -- Frodo Baggins, the smallest elf, was just executed! No other details were available.
Last time I read this on slash dot was less than a year ago. I imagine in 4 or 5 months we'll see it again.
The article is great. It really is a good intro to refresh that assembly / understand ELF / do neat stuff. I still have the tiny assembler installed on my machine from the last go round.
I've heard of a guy who is trying to make the world's smallest 'cat' program. I wonder how many other utilities have been similiarly "optimized"
I seem to remember making some damn small Turbo Pascal .COM files. Under 4096 bytes, IIRC.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
... wanting to execute the smallest possible elf. You Americans and your bloodsports. Barbarians.
If you guys go ahead with your cold-hearted plan to execute this elf, the Olsen twins better watch their backs next time they're in Ireland, if you catch my drift.
- SMJ - (It's not just a name: it's a bad aftertaste.)
in assembly: RET
:(
All this one byte program does is terminate execution. If it's infected by a virus you'll see soon enough if the size has increased.
ofcourse with todays macroviruses this doesn't work anymore
Privacy is terrorism.
Linux software is horribly bloated, like even "ls" is above 30k, thats just insane for a program thats supposed to just list files in a directory. About time someone did something about it.
This makes my new 100-gig hard drive seem WAY too big.
I've always wondered what all the glibc overhead (compared to f.i. uClibc) does. I've never noticed any functional difference when setting up a initrd image by using uClibc instead of glibc.
There isn't much practical here more than it is an ELF education. But it was a very interesting read... and being able to stuff a payload into the header. Nicely done. But given that, in most cases, disk space is vast, and memory is plentiful, there isn't much in the way of usefulness. Maybe in some niche' applications running on tight hardware... but running Linux.
Basically what the other is saying is that by default, C is somewhat bloated (you need to include massive libraries just to use one function). Writing system level calls in assembly can replace the unnecesary bloat of a library that's only being used by one function.
I remember this trick wehn I was learning x86 assembly. I wrote a hello world program in assembly. Assembled, it came to something like 35 bytes. In C++, it took over 10K.
Now, also see the statement that he is abandoning portability, because he's using linux-specific system calls. So, in a nutchell, C++ makes big code that's portable, assembly makes tiny code that's static.
Did I miss something or was this a long winded article about why assembly is better than C++?
There is no reasonable defense against an idiot with an agenda
:wq
Well, someone will point it out soon, so I might as well do it myself.
nasm is the name of the assembler, not tiny.
You can make a 45 byte version of the 'true' and 'false' utilities by changing the output to 1 or 0 respectively. Some shells implement these as builtin functions, but it does show a pratical (albeit odd) way to save a few bytes of disk space.
This guy clearly doesn't get the point!
67% of Americans are overweight. They can't account for most of the bites they use. By developing software that is just as bloated, the users feel good about themselves.
This kind of skinny programming is very insensitive to the fatass society we Americans live in! Hopefully the U.S. Congress hears of this soon, so that they may legislate this kind of software right off the face of the earth.
Masque, head of the Sensitive Programming Foundation*
[*A division of Maxtor Corporation; come check out our new 320GB drives, featuring room for tomorrow's applications...today.]
Cas, or StorageReview.com's forums, created a 324 bytes Windows 2000 PE executeable. It completely blew away all of mine, the smallest of which were about ~700 bytes.
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
every single byte in this executable file can be accounted for and justified
The author's sanity, however, cannot.
moto411.com
My sincere apologies,
I read this article months ago, but it was not a Slashdot link. It was a link from another tech news source.
I think there are quite a few. It's seen as a challenge, and does have practical uses. Have a look at Toms Rootboot disk - it includes a web server, a telnet server, a telnet client, an nfs client, wget, gzip, bzip2, vi, a whole load of network drivers, and a tonne of other stuff, all compressed down onto one floppy disk. Only I've never quite been able to find the source code for any of it despite spending a small amount of time looking - possibly someone would be able to put me right on that one.
There are also lots of interesting articles on linuxassembly.org.
Andrew
But I'd like to see them get a Breakout clone in 1K
None are more hopelessly enslaved than those who falsely believe they are free. Johann Wolfgang von Goethe.
While the program would be completely useless.
You could make it even shorter by having it return absolutely nothing (Just having it execute and finish.)
It could be useful to catch when anything starts to modify programs on your computer, because if the "thing" just modifies programs, it will recognize it as a program, and increase the size notably.
I really like the 45 byte program though, too bad that after you passed 100 bytes, it became totally non-compliant.
~ kjrose
Harddrive sizes being what they are now, the smallest sector size I see is 512 bytes. If the file stored in that sector is smaller than 512, it still takes up 512 bytes. Very intersting article however.
Soon I realized that smaller programs are not the end-all goal of programming. If a slightly bigger program is easier to understand for the next person who modifies/maintains it, then that is the new "Right Thing" for that application... and I realized the efficient progamming of the PDP days was a biproduct of necessity more than anything else. It's seldom needed with today's blazing hardware capabilities.
This isn't to say that many of today's programs are over-bloated, but just to reinforce the trade-off between small and easy to understand.
Reminds me of one of Bill Gates' first programs - Micro-Soft's 1975 Altair BASIC. Unfortuantly the page I wanted to link to has gone, but this is something from the register at the time: http://www.theregister.co.uk/content/4/18949.html
. org.uk/altair/4k/index2.html
:p )
Finally found a web archive of the page I wanted: http://web.archive.org/web/20011031094552/www.rjh
A real pity that standards have slipped so much since then.
(I refuse to post anonymously even though I have mentioned Microsoft in a thread about Small Exes. So there
We really need more efficiant programming in OSes today. Look at the system requirements for OSes over the past few years. It's gone crazy. Check out the requirements for NT Workstation 4.0, Windows XP Pro and Windows 2000 Pro.
Doesn't something seem messed up? What have we really gained since 4.0 that causes 4x the memory, 3x the procecssor, and almost 15x the harddrive space? Is USB and Firewire support really that big? And have you ever tried to run XP on the min system? It doesn't work so well. I remember being able to tweak a system to run Windows 95 on a 386 with 5mb memory and a 45mb harddrive. It wasn't pretty but it could run. Today if you aren't going 1ghz+, then they want to leave you behind.
They are just using really fast hardware as an excuse for bloating the code.
Even Linux (redhat moreso) is guilty of this.
Remember when awesome games could fit on a handful of floppies? I think that could fly today if they tried. Look at the Demo scene. 64k can do alot of graphics. The most awesome games like Betrayal at Krondor were only a few floppies. Sure, if you have big hardware use it, but don't waste it. Programmers are just getting slack and including (literally) everything in the world, and not writing anything for themselves. They aren't looking to optimize stuff, just to kick it out and make money (obviously open source isn't guilty of the money or the fast kickout thing)...
Tibbon
tibbon.com
You know -- the bullshitters that say: "Optimizing C compilers write small/better/faster code than hand-tuned assembly."
Hand-tuned assembler is always faster/smaller/better than C code, except when it comes to portability.
And this just goes to show that fact again!
Now, the author has to shrink the cluster size of his hard drive, and make up some new indexing structure that is more efficient so any shrinking of the executable actually matters.... It doesn't help if the executable is 32 bytes or 4096 bytes if you only have 4k clusters, you're still eating the same amount of space.
Karma: SELECT `karma` FROM `users` WHERE `userid`=138474;
The nasm assembly compiler site that he mentions in the article seems /.'d, theres a sourgeforge project site instead.
WIN2KSP3.exe 124.68MB
GW6SP2M.EXE 302.10MB
Favorite_ISO.zip.exe 700MB
w
The colon on the first line is an older version of the #! line, but only works for sh. And of course, `w' is one character less than `ls'.
On systems that automatically use /bin/sh on unknown files, the smallest possible shell script is:
wYes, a single character.
WWTTD?
I remember years ago writting a run-length decompressor in Z80 asm that was 32 bytes. I think the compressor was 50 something bytes!
I also recall adding up the clock cycles for all of this to try and find the fastest implementation!
I'm over it now though!
I'm just glad to forget those cassette-tape based, hand coded assembler days, but it is kind of a shame to see how bloated code has got. If only I'd had a macro-assembler on my Sinclair ZX Spectrum (Timex something or other in the US) in those days... oh the world could've been mine!!
Linus wept.
linuxdoc.org
Chapter 11
Verse 35
You've got an easy breezy wind at your back...most of the time.
Nero-burning ROM for Linux!
The current state of elf proccessors demands an astounding amount of system resources. When combined with dwarf co processor, it provides for unparalleled carnie access.
Its not so much the executable size that really matters (when talking about bloat), its the memory consumption of the program that really matters.I could write a very small program size wise that would drain your memory and crash your system, or make it slow down to a crawl.
-- "Perceptions create reality. By changing your perceptions you change your reality."
On a similar topic, MenuetOS is a full OS written in assembly and fits on a floppy. Yeah, lots of OS's used to fit on floppies, but it's still cool. It's amazing what all you can fit into a small space if you're careful.
Who said Freedom was Fair?
Well this reminds me the golden days of DOS (not Denial Of Service but Disk Operating System... well, anyway it didn't made a difference). Back then people fought for every bit of code. And assembler was as popular as C or Pascal.
However, using assembler this way is not the most optimal resource. Frankly this piece of code is only useful if you need some real tiny program and you are running out of space and speed. But, today, 99.99...% of tasks don't need it. The optimal way to use such tricks is to concentrate in tasks that really need "the best and fastest code ever". These are drivers and situations where speed's price costs gold. Usually this is done by injecting the necessary asm directives into C or any other language. Writing everything in pure Assembler is unpractical and the result may become harder to understand than the Rosetta Stone.
However the article is making a point - how unoptimised are the present compilers. For example, GCC is mostly C in C. It makes it highly portable, but, if anyone decided to repeat Turbo Pascal feat (most of its base code was Assembler), I know that binary code would shrink to the impossible. Right now we may not be feeling this drawback as bloatness still doesn't clog everything. In the future this situation may change if speed and reliability turn to higher priorities.
Some note for the bloat FUDders: This is not a reason for Linux distros being bloat. First learn to be rational on your needs and don't install everything in one box. Second, learn a little bit of administration, maybe some programming and kick that (mega_kernel) + (some_highly_featured_libs) + (several_unuseful_apps) out of your box. Then you will know that Linux can help fry eggs on your processor with lightning speed. Till then, keep the flame for yourself and read "Why I switched from Mac to Windows".
it may not be all TOO practical, since a lot of people try to ensure that their program runs on multiple architectures and platforms, but I also miss the old (DOS) days when the demo scene tried to optimize their intros to fit a half an hour of entertainment into 64k, with full sound blaster support. the registers of the vga cards were abused to no end, lightening fast assembler procedures were optimized either for size, or for speed by unrolling loops, etc.
:)
while that isn't practical anymore these days, a LOT of code has become very sloppy. More than once have i stumbled over some college kids c app that was supposed to demonstrate linked lists, and instead, it was using one class with an array.
programming is an art, like acting. many try and are good enough for some purposes, but only a selected few are masters. sounds pretty damn philosophical, don't read too much into it
On Red Hat 8.0 I get:
/bin/true /bin/true
$ wc -c
9752
That's thousands of extra bytes - eek.
Looking through the comments here I see two main threads : (1) Squeezing out the last few overhead in a program leads to hard to understand / maintain program and thus is not worth the effort. (2) Whats the big deal anyway in this era of 100 GB disks and 2GHz processors?
While both these criticisms are valid, they miss the point. Firstly, it wasnt the objective of the author to squeeze the last few bytes out of that program to save resources. He was just putting his hard-earned knowledge to use. He was doing it because he could! This is the same motivation for people who climb mountains : because the mountain is there, and because they can climb it. Indeed, if the author were seriously looking into saving resources, he'd hardly be wasting his time on a trivial program, would he?
Secondly, one of the authors intentions was to demonstrate the limits to which austerity could be taken to. Certainly, this was a trivial program - but the same principles could be used to shrink larger non-trivial programs, and it those cases, the savings could possibly be larger. Of course, it those cases, the largest savings would come from a good optimizing compiler rather than crunching the headers together. More importantly, the author has exposed whole new ideas and lines of possibilities to programmers.
There is no such thing as luck. Luck is nothing but an absence of bad luck.
That's it. I'm no longer part of Team Sanity.
Beyond some point, the article is really just silliness, interesting or not. Below 512 bytes, your not going to save anything on any system. Ok, there are filesystems that compress things further for squeezing into flash memory and such, so maybe there are some marginally useful applications, but still the header overlapping is a bit much to be worth considering.
Some of the 4K demos I've seen written for ASM competitions completely blow my mind... check out this one, it's basically a flythrough of the first level of Descent, with texture mapping, source lighting, animated lava and recharger field, a MIDI soundtrack, etc... all in 4095 bytes!!!
Here is Sanction's home page, it contains a couple more very impressive 4K demos.
"Mind, as manifested by the capacity to make choices, is to some extent present in every electron." -Freeman Dyson
To be compared with the non-optimized gcc version at 3,998 bytes.
I wonder how small you can make a Windows EXE..
Beware: In C++, your friends can see your privates!
In fact, just apply this fact iteratively and you'll find that any program can be written in zero bytes!
www.linuxassembly.org/ - Go there, its free and fun :-)
http://linuxassembly.org/asmutils.html
Check it out, download it and assemble it.
They create the smalles set of binaries for the basic linux tools that I have found and they employ a good portion of the stuff mentioned in this paper.
They make busybox look bloated by comparison.
Another neat trick is to use the ld options "-Wl, gc-sections" when linking a static binary -- it tries to weed out all the unused portions of the libraries it links against.
The last trick I usually use is to link against uClibc or dietlibc rather then glibc. Makes a noticeable difference. RedHat has been working on a program called "newlib" which is supposed to do the same thing as uClibc or dietlibc but better (for embedded stuff).
where's your spoiler alert?!!?!?
Tiny, compact code is neat but I don't care about it. Folks here complain about bloat constantly but unless a program's size is actively interfering with your ability to do work and the program's functionality (and I don't mean taking an extra 2 seconds to load) who really cares? If it won't run on your machine, that is one thing. If it's just big, there are probably more important things to worry about. For example I don't really care that Mozilla is big compared to some other browsers. My machine can handle that and it's speed is adequate to my needs. I do care that the program is functional, reliable, easy to use and maintainable, which fortunately it is.
Just because a program or executable file is smaller, doesn't necessarily mean it's more efficient. For instance, some compiler optimizations actually produce larger executables. If you unroll a loop, it actually generates code for each iteration of the loop, but saves time because it's faster to keep going forward than to branch backwards to run through the code again.
Similarly, you can have inline functions that insert the inline function directly into the function calling it. Every function that calls an inline function would get a copy of it, which produces larger code, but saves a lot of time since it doesn't need to push the arguments on the stack, branch to the new function, and return with the value.
Finally, the biggest speed gains you can get are generally algorithmic in nature. You can do a bubble sort with just a few lines of code. It's a lot simpler code and smaller than the larger and more complicated quick sort or merge sort. I know which one I'd rather wait for with a million items to sort.
So remember, just because something is bigger, doesn't mean it's more bloated, and just because something is smaller doesn't mean it's faster or more efficient.
Looking for a computer support specialist for your small business? Check out
not an elf.
Rumors of his being a fairy persist, however.
KFG
-Kevin
The first few examples are quite noteworthy, but when the author starts to put code inside the ELF header, it gets really ugly..
Saying that these bytes are "only padding anyway for future extensions" doesn't feel that good. :-)
This remembers me of early attempts on AmigaOS to shorten and fasten executables where people could be sure that all available Amigas would only use the lower 24 bits of 32 bit address registers since the machines could only address 24 bits physically. So they put application data into the upper 8 bits of registers. Worked fine.
Then came newer machines which really used the full set of 32 address lines and all those dirty programs crashed without obvious reason..
The author says "if we leave compatibility behind.." but what he's doing is not only leaving inter-OS compatibility behind - what he creates isn't even an ELF executable anymore. It's just something that happens to work with this special Linux version.
So since this isn't even an ELF executable any more, there's no reason not just to write "exit 42" in bash (which would be an amazing 8 bytes in size *g*).
Don't misunderstand me, I really like those hacks. But I myself will never, ever again code something that is prone to break in the future just because I didn't follow standards.
One could say that this is what programming is about. :-)
No offence meant.
42. Easy. What is 32 + 8 + 2?
the real reason to obfuscate through efficiency! :)
(context for mods) let's see... ELF... elves... races in fantasy and science fiction:
No. Trolls
Look at that troll. Isn't it Qt?
are completely different creatures from hobbits and elves.
let's see... among (semi) intelligent roughly-humanoid races, the fantasy multiverse has at least humans, dwarves, elves, hobbits, ents, weebles, smurfs, cyclopes, gnomes (pronounced g; 90 cm tall), gnomes (silent g; 15 cm tall), trolls, orcs, merfolk, selkies, marsh-wiggles, nerdlucks, jawas, tuskens, wookiees, ewoks, teeks, borrowers, morlocks, and eloi.
Saturday, Saturday, Saturday! Watch the Race Race at the Motor Speedway!
Be there.
--
define MAX_CHRISTS 5
Will I retire or break 10K?
$ cat >a.pl
./a.pl
#!/usr/bin/perl
exit(42);
$ chmod +x a.pl
$
$ echo $?
42
$ ls -l a.pl
-rwxr-xr-x 1 bcrowell bcrowell 26 Oct 19 12:41 a.pl
Only takes up 26 bytes on my hard disk!
Find free books.
CPU is cheap, hard disk is cheap.
Maybe on PCs, but not on embedded systems, handheld systems, or game consoles. The Game Boy Advance, for instance, has only 384 KB of RAM, and all but 32 KB are 16-bit bus width with muchos wait states. Many microcontrollers inside such things as microwave ovens are as powerful as an Atari 2600 VCS, with 128 bytes of RAM and about 12 bytes of VRAM (if that).
Will I retire or break 10K?
The author concludes, 'every single byte in this executable file can be accounted for and justified. How many executables have you created lately that you can say that about?'
Heck, Microsoft fits that profile. Every byte accounted for? "One enormous pile of garbage."
May we never see th
I saw this years ago. Sometime in the late 90's. It's very interesting and cool stuff, thouhg.
--
If I actually could spell I'd have spelled it right in the first place.
You may say, yeah but how often will you printf more than 1024 bytes? Exactly,- practically never. Which is why this sort of crap is not showing up in testing and DOES show up when people are trying to crack it.
1) The increase in OS requirements is partially due to the increase in OS functions. XP provides a lot more eye candy than NT, which needs more processor power to handle. You may not think it's a good idea, but most people like it.
2) The increase in OS requirements is mainly due to an increase in software requirements as a whole. An OS is worthless if you can't run anything on it, so you need to set your requirements with software in mind. MS made this mistake with Windows 95. Yes, technically IT would run with 4MB of ram, but that wasn't enough to load anything else. XP's stated minimum isn't the actual minimum, but a practical one wheny ou account for applications.
3) As others have mentioned, compact code comes at the price of maintainability. Sure, I can write a program in 100% assembly, and then if I'm realyl good tweak the machine code to make sure it is as efficient as possable. Now try and maintain that. This is hard enough if it's a tiny app, but if it is something large like, say, Mozilla even the orignal programmer would find matenence very difficult and anyone else would find it almost impossable.
4) Along those line, portability requires that you code in a higher level language, and often that you make some changes that increase your code size. If you do everything in optimised assembly, well it's a one platform thing. I can gaurentee that you have to do a massive rewrite of an assembly Windows app if you want to make it run on x86 Linux just because of the API differences. If you are talking another hardware platform, then it's a total and complete rewrite.
5) Your 64k demo thing I'm assuming is refering to the now infamous Farbrausch demos. It is simply stunning what they can get done in 64k BUT it comes at a huge price. First there is the memory usage, look at your task manager sometime when one of those is running, they use like 80MB. Because of their tiny disk usage they can to decompress to memory. Second their compatibility is horrable, their newer one FR22 works properly on my sytstem at work, but not at home, the only big difference being at home a have a geForce 4 at work I have a GeForce 3. Finally, these thigns are only made possable by the "bloated" Windows framework with things like DirectX to simplfy low level access.
6) Most people see little point in trying to make things run well on a 386 when you can get an entire system running at over 1ghz for about $500.
I remember in the "good old days" (tm) on the Amiga, when some (well, quite a lot actually :) people managed to make small intros with sine-scrolling multi-colored text in less than 512 bytes, all done in the bootblock which also had a loader for whatever game/demo was on the disk.
/ The Arrow
"How lovely you are. So lovely in my straightjacket..." - Nny
Wired 1995 Surprize coding compo :
.com program that does the following :
:-)
:-)
Write the smallest possible
1, Input a number from the keyboard, call it N
2, Go in mode 13 (vga), draw N 3x3 squares without the central pixel (N * 8 pixels to draw), no square should be adjascent to another.
3, Wait for Enter
4, Exit
Results were
1: Walken/Impact Studios, 48 bytes
1: (ex aequo) Paranoia, 48 bytes
2: KLF, 51 bytes
For info, Walken's version was drawing the squares at different positions every time his program was ran (don't ask me how)
Our own attempt (aegis) yielded 52 bytes, but we were disqualified because we did not support the key "0"
ahh... fun...
lone, dfx.
$ cat>a.sh ./a.sh ; echo $?
#!/bin/sh
exit 42
$ chmod +x a.sh
$
42
$ wc -c a.sh
18 a.sh
flossie
Write now. Defend liberty
No. The 45th byte of the resultant program is required to be there as part of the ELF header (Linux won't run the program otherwise). The code which generates the value 42 occurs way before the 45th byte of the program in an unused portion of the header. In fact, the return value could be a couple of bytes longer without changing the length of the overall program.
flossie
Write now. Defend liberty
$ wc -c /bin/true /bin/true
9704
That's 9659 wasted bytes!
flossie
Write now. Defend liberty
...nobody has yet said whether the smallest elf is executable or not? I would imagine that unless he's a water bear, we're probably still going to be able to execute him.
http://saveie6.com/
"Ah, kamisama! Ore no atama ni ono ga arimasu yo!" is quite correct. To my ears, the use of "wa" makes the rhythm of the sentence quite lethargic. Though it may not be correct textbook Japanese (the use of the word "yo" already makes it conversational, and thus, some leeway in grammar is allowed), between peers, this usage will be quite acceptable.
Yes, I do speak Japanese fluently :-P
This one went around the internet a thousand times already, but in case you haven't seen it:
True in a Nutshell
Make it even smaller by doing this:
/usr/bin/perl /p
cp
and editing your shabang to be #!/p
While it's true that quite a few optimizations not only improve the runtime but also reduce the code size, this is not generally true. An important optimization, for instance, is loop unrolling - which more than doubles the codesize of a loop. Its purpose is to reduce the number of branches, as jumps in superscalar out-of-order processors are performance killers.
Small executables are important for machines where the program is stored in flash (like microcontrollers). The compilers for those architectures are optimized to produce small code (as a matter of fact some of them are gcc-based). When storage is cheap, program size is rather irrelevant (keep in mind that OSs do paging, they only keep a working set of the program in memory).
The Raven.
The Raven
While nostalgic, this kind of minimalism is misplaced in modern operating systems. When you write an application, even a small application, think of everything that goes on behind the scenes:
1. Using a single function in shared library brings in the entire library.
2. You're at the mercy of the code in shared libraries and drivers. Even if you write code in hand-optimized assembly language, what's the point when you have to call the OS or a driver in order to do graphics and I/O?
3. There's a relatively large cluster size under most filesystems, so saving a few bytes or even a few K can often be irrelevant.
4. Even simple things like memory access can cause interrupts during which the virtual memory system intervenes.
All the posts about "returning to the days of performance" and all that rubbish are completely off the mark.
The point was that if you have binutils installed, you already have gas, and practically anyone using a Linux box for development will have bintuils installed, so why bother with nasm?
Speaking as a compiler developer, who as a contractor has done major compiler work in recent years for HP, Microsoft, SGI, etc, I strongly disagree.
The speed of generated code is very important to hardware vendors (because it is essential to the speed of their hardware), to software developers (because the easiest way to get faster code is with zero effort -- buy a compiler that generates better code), and to compiler developers because they sell to the other two camps. (Or often, are also one of the other camps.)
Sure, we all know that programmers in general don't care about speed of generated code the way we did back when it was truly critical to literally count every cpu cycle burned. But don't blame us compiler guys -- we're the good guys!
On the other hand, you've a more legitimate complaint in talking about no one caring about the size of generated code. If you check the literature, you'll find that the almost the only famous reference on the subject of compilers minimizing code size was the landmark Bliss compiler, circa 1970.
It's almost never been a concern. (I know there have always been exceptions to that, but I can't remember any exceptions that were famous, whereas issues of code speed are extremely famous.)
Professional Wild-Eyed Visionary