Whats possible in asm vs HLL, I can think of a few things:
1. You can specialize your code at the instruction level
That really sums up the remaining points I was about to type.
On second thoughts, maybe I can finish the remaining points:
2. You have the chance to write programs at the smallest level, meaning, the absolute smallest level possible.
3. Self modifying code that evaluates instructions as it progresses, not possible in hll.
4. Instruction level optimization in a different way than normal (Optimization in a bizarre way I can't talk about now)
5. Customizing your executable in a more technical way than possible in hll
6. Customizable stack frames beyond the known calling conventions
7. Ability to feed the processor instructions in an order to maximize parallel execution (Between the V and U pipe for example, not possible in hll, only in a very general way)
8. Ability to align code and data in any way using nop or any other byte. In HLL this is somewhat limited.
9. Ability to go outside standards of structure definitions, constants (You can perform instruction level bit tricks on operating system constants to optimize, which depends on the actual instructions being used, not solely on the bits)
10. You get the ability to write a true computer program. A hll language is just a human language, it's not a computer language.
11. You can mix fpu and x86 instructions in a way not possible in hll. Sometimes it doesn't pay off to use pure fpu.
12. You can go beyond the data type "rules" of a hll language and put floating point values inside integer variables and treat that variable as any type you want, which can be beneficial because sometimes you can reuse a variable for other purposes, in a hll language you have to declare a new variable for that, in assembly you can reuse "free" variables for other data types.
13. You can perform arithmetic on an integer and a float at the very same time without "signalling" the compiler to treat it in a fpu register, if you know how floats are made up you can mix it up.
14. You can mess with return values on the stack the way you want to.
15. If a procedure have no locals, you can omit the stack frame, saving at least 8 memory writes every call.
16. In assembly you can write programs for future processors and ship the program before that cpu is on the market.
17. Similarly, in assembly, you can immediately take advantage of future cpu technology that isn't on the market yet.
18. In assembly you will be able to do errors without being corrected by the compiler. There are no annoying parents. Except for your uncle, and he seldom complain about anything but some rare syntax problems, a missing square bracket for example.
19. HLL is absolutely dependent on programs that are compartmented into functions and objects. In assembly, you can code the entire program as one very large and compact "string" and it will still run. (Some may say you can do that in c++ too, but in practice, you can't do that)
20. HLL languages makes you technically blind after awhile. When you look at your data definitions in a hll language, you'll eventually believe that data types actually exist, because you've been staring at it for so long. In assembly you'll learn that data types are just instruction choice. There are no data types, just instructions.
21. In assembly you don't really need a ton of reference, in c++ you live and feed on help files and documents. You eat them for dinner.
It is better understood when you get to understand what C++ actually is. C++ is a very advanced macro system on top of an assembler. When you realize that, you also realize that c++ is a just a very complex macro assembler. nasm is a somewhat complex macro assembler, but not very complex. So anything you can do one layer above, is also possible at one layer below. Anything you can do in a very complex macro system, you can also do on the basis that forms up that macro system, which is the assembler. But vice versa isn't necessarily true.
I almost forgot: And another thing you can do in assembly is to produce much faster code and the reason is usually very understandable; compiling a hll language program and expecting it to become faster than an equivalent assembly program, is like trying to put chinese text into google translate and then expect the end result to become perfect english. It can't become perfect, and that is why we need an assembler, we need it to get perfect translation between chinese and english.
In almost every case I read about why hll language programmers prefer c++, the reasons can be narrowed down to "time being saved" which basically means he makes more money every day than he would if he used assembly.
But that is not an argument in support of claiming that hll is better than assembly. Money-wise, if you're after making money, c++ is better. If you are a technical guy, a programmer, assembly is better. Saying that c++ is better because it makes you code faster is a bad reason. If you are a business man, c++ is better, if you are a programmer, assembly is better. It's just that easy.
It can be better understood if you consider any other fields than programming. If you're a marathon runner and you discover than you'll reach the finish line much faster if you use your car rather than running. Sure, you'll reach the end line faster, but you aren't a marathon runner if you do, and so there are no arguments in the field of marathon. Similarly, using the phrase "money saved" isn't an argument in favor of programming. It has nothing to do with programming.
I could give an example in a case where assembly outperforms hll. Consider nasm and fasm (netwide assembler) and (flat assembler). Nasm is written in HLL and fasm is written in assembly. Nasm's %rep preprocessor performs 100 times slower than fasm's equivalent rep preprocessor directive. Fasm completes a million repetitions in the same time that nasm does 10,000 repetitions. Fasm outperform Nasm by 100 times in their respective preprocessor rep directives.
I don't even have to look at nasm's source code, I know why it produce so much slower code without even looking at it. Because I'm so familiar with computers from my assembly experience, I can pinpoint the problem without even looking at the source code. Let me know and I will tell you why it is slower. (If you're interested)
