I don't want to be blunt, but you always seem to miss the point. Assembler is great for producing small and/or fast programs. But the programs will only be small and/or fast if the programmer is skilled enough. If I have access to a programmer that can produce a 10kB working and sellable program in C, or can produce a 3kB broken disaster in assembler, then it really does not matter if the real solution could be fitted into 1kB of carefully crafted assembler. I go for the 16kB chip and collect the money from the customer.

Look around you: Even if you wanted to, you can't employ truly talented and experienced developers for ASM jobs, if your goal is to go 100% assembler. A tiny fraction of the programmers of this world can write anything at all in assembler. And a tiny fraction of them will produce "good" code. That is a huge reason why it doesn't matter what you say that you can do in assembler. What matters is what tools that will end up in food on the table.

A C solution may consume 300% more processor capacity to solve a problem. But most probably the hw cost will be the same. And the delivery times will be faster. And the original developer can be replaced. The only loser might be the environment, in the form of slightly higher energy costs. Most companies accepts that.


You may write a top-of-the-line assembler implementation. And you may still produce the larger solution if the C developer went for a little byte-coded virtual machine - each byte of a byte-coded VM can be specifically optimized for a problem and hence contain more problem-related information than assembly instructions.

Yes, after thinking about the VM, you can rewrite it in assembler and cut away a few percent of the total size. But if you didn't think about it, then you lost on algorithm - not on language.

I prefer a developer who always selects the best algorithm for a job, than a developer who always writes the smallest, or the fastest code.

I worked with a couple of products programmed in PLM-51. Two years later, they had quite a lot of new features, but more free space than when I got them in my lap. I have worked with C projects where I got a full unit, and then regularly got requests to add new featues. Yes, I know what it means to run out of space. But this is not applicable to all projects. And the skill of the original developer does affect the code size a lot - in any language. I often take the cost of fighting for the last bytes of code when I know that that is the only acceptable solution to the problem.

I'm not trying to be difficult. I have written huge amounts of code in assembler. And I have rewritten the code again for another processor. And again for yet another processor. And in several cases I have failed to sum up any real gain from the original use of assembler. The total life-time bottom line for the product has indicated that I should have written the code in C. How fun is it to deliver a product and five or ten years later still have the same product on your table because it contains assembler, and if the code is shown to another developer they look like a deer in the headlight? How fun is it to fight a critical deadline with one project and then find out that this old product needs a new feature added now and no one who can do it?

Companies thinks bottom-line, not number of bytes or clock cycles saved. And they do not like one-man-shows, where they get stuck if someone gets run over by a truck.

So yes, I still claim "Maybe". Maybe if the developer is good enough. Maybe if the developer is even possible to find. Then ASM may produce a smaller and/or faster program. Probably without any receivers who cares.