In my salad days, I used self-modifying code for mutexes or spinlocks, don’t remember all the details.
I also did quite a bit of reverse engineering on utilities and device drivers, and found an exotic RAM-saving trick somewhere in DEC RT-11: a successful completion of a command produced a message that something (don’t remember what) was CORRECT; if the command failed, the code would patch two bytes in the same message, changing CORRECT to CORRUPT.
Sure, but I was talking about doing it in C.
In that case you use __builtin_popcount().
The compiler cannot be more clever than the compiler writer.
Whilst that’s obviously true, the compiler can produce totally incomprehensible assembler that would be unmaintainable if it was source. Some of the SIMD examples he gives in the video illustrate perfectly what I mean.
In that case you use __builtin_popcount().
the compiler can produce totally incomprehensible assembler that would be unmaintainable if it was source.
Asm is unmaintainable by almost anyone coding today 
But if you were coding in asm you would not do what compilers do, which tends to be a pretty random (though usually efficient, after optimisation) mess.
I don’t think we disagree on anything. The reason I am counter-arguing here is because I’ve spent a whole load of time dealing with weird stuff which compilers and linkers do and which is badly documented. A little example: a function in a lib (.a) cannot override a weak function in your code. Only a function in an object module (.o) can do such an override. Wasted a few days of my time, and it was only with the help of the EEVBLOG forum that I identified that. Compared with the time wasted on crap like that, I’ve found esoteric “optimised” code to be worthless, except for code size saving. This is a little sample:
-O0 produces 491k (no optimisation)
-Og produces 342k (general opt, just about usable for debugging)
-O1 produces 338k
-Os produces 305k (optimise for minimum size, at the expense of speed)
So, yeah, the basic optimisation levels are worth using.
Asm is unmaintainable by almost anyone coding today
For sure x86 assembler is. Back in the day when it was common to write assembler, the machine instructions were a lot simpler. I recently got hold of a PDP-11 assembler program I wrote in 1974, and it was crystal clear what it was doing. The 11 had instructions like MOV and ADD.
The x86 has instructions like VMADDMULRTQ7BXZ (OK, I made that one up). It’s anybody’s guess what they do. They are only meant to be produced by compilers.
I can even still read Elliott 903 assembler. That had the unique “feature” that there were no instruction names. You had to just know that 4 was load accumulator, 5 was store accumulator, etc. But since it only had 16 possible instructions, it wasn’t too hard.
Yes it depends on the era.
When I started, people were coding not even always in asm but sometimes in hex. They left spaces for functions to expand! Stupid? Yes.
The IBM PC era saw very little asm for applications. I coded various DOS apps (including a nice terminal emulator, which is still used at work on test rigs) in asm. But most people were coding in C/C++ (mostly Borland but there were many others) plus Basic, etc, etc.
And everything after the 1980s was in C/C++. In mid 1980s at my then company I was doing a lot of asm but others all used IAR C, which was awful crap on speed; I used to hand code critical stuff in asm.
Today, asm is mostly gone. My current project, ARM32, uses asm in startup code (mostly stuff like filling BSS with 0×00 although you could do that in C but I inherited that, and in fact I do use C in other places like setting up a boot loader) and uses asm where it is impossible to avoid: FreeRTOS task switching code, and specific (minimum) timing delays.
