3 ms·
> I feel like there must be a better way to express the same thing that wouldn't lead stuff looking like one word all caps alphabet soup. Yes, that's called a
by chc4 7y ago
> I feel like there must be a better way to express the same thing that wouldn't lead stuff looking like one word all caps alphabet soup.
Yes, that's called a programming language :^)
Assembly is usually essentially a macro engine over the actual instructions you are emitting for your processor, and the Intel x86 chip manuals or whatever you're targeting use the outrageously long proper names, so your assembly will too. Heck, the author mentions specifically reading assembly too, so knowing what you're reading is 1:1 with the actual instruction stream is helpful, no matter how bad the official names are.
Actual programming languages just abstract away some complex instructions like SSE vectorizing (which have famously terrible names) to some high-level API and intrinsic functions. And you should too.
- zokier 7y ago> the Intel x86 chip manuals or whatever you're targeting use the outrageously long proper names, so your assembly will too. I don't see why that has to be the case; why I'd must use Intel specified mnemonics instead of my own syntax? While not as radical, the att vs intel syntax demonstrates that the vendor syntax is not the only option. As long as the syntax captures all the details of instructions to be completely unambiguous then it should be perfectly interchangeable. I specifically do not desire higher level of abstraction because I want to maintain that 1:1 relation with the actual machine code. Heck, even Intel mnemonics do not truly have 1:1 relation to machine code, because the instruction (encoding) can depend on operand types.