I don’t think that’s actually true. Compilers write machine code that’s often much more efficient than anything you could think up by hand, and the bulk of the disk space/memory used by a modern executable is for resources/strings, not instructions. Stereotypical assembly code - extremely lean routines that accept minimal user input and don’t create human-readable output - is indeed smaller than a stereotypical compiled executable, but you’d have trouble beating the compiler 1:1 on the same problem.

But you won't be writing the same code as the code that you would write in a high level language, and that is sort of the point. You're going to do your utmost not to write such code because then you might as well break out the C compiler.

Assuming that such code is suitable or even feasible for the problem you're attempting to solve. High-level languages were created specifically for the purpose of writing large, complex software systems. We don't see assembly being used for those systems. Isn't there an argument that high-level languages are simply more fit for that purpose?

I don't think so, modern high level languages tend to be linked to huge runtimes that are usually load entirely in memory. Assembly programs don't.

If you're not linking to those runtimes and system libraries you're reimplementing them. The functionality has to come from somewhere.

That's what assembly programmers do, they re-use code. They just don't need to ship huge runtimes to be then loaded into memory.

> Your executables will be a small fraction of the size that you expect,

No they won't. There is no way that you can write more compact code than a modern optimizing compiler for anything except the most extreme edge cases.

Yes you will. Because you can't afford to write code like a modern optimizing compiler. You're going to have the same kind of linecount that you have in your high level language projects and those lines will compile down to a few bytes each at most.

Assembly language binaries tend to be extremely small compared to equivalent code written using a high level language. But: you'll easily spend 10x the time on them. The 'modern optimizing compiler' argument is at the function level: where you write a function using assembly and then write a similar function using a high level language (but still a compiled one, obviously). Yes, the compiler will probably win that race. But an assembly language programmer isn't going to write their code like that at all.

They will reduce the task to the point where it is manageable and that alone will save far more code than the compiler can ever remove. Assembly is (and assembly language based applications are) utterly bloat free, you do what you have to do and nothing more. You can use registers in ways that a compiler would never even think of because you can globally optimize.

No stack frames if you don't need them. No memory accesses if you don't need them.

But code that is hard to maintain and that likely will not be easy to work on with multiple people. 100 KLOC (including comments) -> 16Kb output. No high level language would even begin to approach that.

> They will reduce the task to the point where it is manageable

If they don’t even solve the problem, then it is no competition.

It's trivially easy.

One low hanging fruit: Compilers are handicapped by ABIs and language semantics, they must adhere to calling conventions, alignments, paddings, exceptions/stack unwinding, etc.

If you don't have to care about any of that you can save a lot of useless instructions.

And secondly when it comes to size optimizations, compilers are pretty bad (or they tend to still value some speed over pure size). Wont find any modern compiler emitting lodsb/stosb (the non-rep kind) on x86 for example.

> Compilers are handicapped by ABIs and language semantics, they must adhere to calling conventions, alignments, paddings, exceptions/stack unwinding, etc.

I believe most of these are only at potential “extern C” points. Usually these conventions are upheld because they don’t have a huge cost, but to give you a trivial example: inlining is literally about dropping all that in favor of optimizing at a larger scope.

I remember claims that compilers are going to emit better machine code than humans when pipelined and speculative execution was first implemented in intel processors. It turned out to not be true. It is still not true as of today. Humans are still better at this, and still by humongous margin. LLMs are going to change that soon however.

Lol at both of these claims.

Humans are better at tiny hot loops. Not at all at anything larger than that.

And call me back once LLMs successfully solve a Sudoku first, before they attempt at spewing out code.

Rather than argue about it, why don't you find an equivalent demo bit of code in both ASM and any other language you choose, and compile both into a static (no linking of libraries) binary?

You should be able to use the Rosetta Code web site to find equivalents written in ASM and say, Rust or C++... then you can easily demonstrate that what you say is factually correct.

Surely we are talking about real applications not toy educational snippets. Or are you claiming that what works for the dozen or so lines in a typical Rosetta code example works just as well for million line, multi-user, multithreaded, object oriented simulators and optimizers of electrical machines?

At risk of moving the goal posts, I suspect that actually writing such a program in assembler might well be impossible simply because it would probably take too long to write and debug.

If assembler tooling were improved perhaps this could change but who will do it. There have been assemblers with object oriented extensions, perhaps other developer aids could be created. But who will expend the effort?

Many instructions in assembly is simply “logistics” of where should this or that byte go. Machines are eons better at it at large scopes than humans, you surely don’t have enough hair to sit through and carefully examine every register. Also, will you decide on a case by case basis to “inline” a function’s body? What if the function’s body changes? Will you go back to every “inlined” part? What if that makes a more efficient register allocation possible, rewrite the whole function where the inline happened?