> Assembly language yields maximum control and execution speed.
It yields the only control and execution. Almost programs are generated through an assembler and assembly language. How could it possibly not be relevant?
I read that line as suggesting that when using HLL the programmer generally does not have control over the assembly that is generated. I guess that is why sometimes, as the author suggests, the programmer may write part of a program in HLL and another part in assembly in order to achieve increase execution speed.
It's more than just execution speed. It could something as simple making a function using assembly that swaps the virtual memory page table on a processor. That's not something you gonna find in a high level language.
Yea done that myself, save all the register states, save the stack pointer, and then set a new stack pointer and load all that tasks register states.
Although doing the same on windows is kinda annoying. Also the amount callee saved registers is kinda like what the heck. Here is some code I wrote doing that for window's ABI.
https://pastebin.com/jnxeMRcV
There are a huge number of software engineers today, dare I say most, who cannot read or write assembly and are isolated from it by multiple layers of abstractions.
I would probably struggle to write assembly without difficulty and blowing something up but... is most macro assembler really that hard to read? The examples the author of the article gave seemed reasonably easy to parse out for anyone who has a conceptual model of control flow, variables, memory locations, and basic operations.
You can generate machine language without an assembly language intermediate phase, if you just directly put bytes into a file. But most compilers have some kind of assembler in them.
I could be mistaken, but, don't JVM languages avoid assembly steps? They use bytecode and are translated directly to machine code; I'm not sure there is an translate-to-assembly step. I'm also not sure how much of this confusion is semantics vs actually different components of the compilation and running process.