XlogicX

I have no objection to the utility of something like AAD. What I'm saying is that this same very instruction can do more at a machine level. AAD assembles to D5 0A, even though D5 is the part that refers to AAD, 0A is hardcoded for base 10. One could machine code something like D5 08 (to have base 8 conversions). You can really do just about any base. Even the Intel manual states you can do this, you just have to do it at the machine code level, you can't do it with the assembly level instruction of AAD (it's too high level or abstracted). This is all I meant by my comment.

I love x86 complications (ARM is way more elegant in comparison), and I WILL be bothered to walk through mov %eax, (%r12), or 41 89 04 24 ---- 41 - being the amd64 prefix that 'unlocks' rax to being interpreted as r12 ---- 89 - still the same MOV instruction as the first one in mov %eax, (%rax) ---- 04 - The ModR/M byte that specifies the %eax part, and [--][--] as the 'Effective Address', which is another way of saying that we need a SIB byte because this (%r12) doesn't already have a simple encoding with the ModR/M byte alone (the same would be needed even if it was a simple (%esp)). ---- 24 - A 'Scaled Index' of none and as simias stated, RSP (but R12 in the context of the 41 prefix for this instruction). ---- All of this is easier to visualize when using the ModR/M and SIB tables in Volume II of the Intel manual. In my copy of the manual it's pretty early on in Chapter 2 (2.1.5 Addressing-Mode Encoding of ModR/M and SIB Bytes))

The main (actual) theme of the series is focusing on non 1-to-1 mappings, for any reason (useful or not). It's a thing that fascinates me. The phrase "$x is too high level" is mostly satirical, a phrase I've used for more than just assembly language ($x = [asm, regex, scapy, inflate/deflate, zip, elf, burritos, etc...]).

lol "isn't permitted", "unsupported", "undefined", are all trigger words for me; when I see them, it's the only thing I can think of doing. I get that more than 90% of the time something fucky is going to happen, doesn't stop me from wanting to know exactly what will happen. And sometimes, rarely, something really cool happens. In this case, doing ROR r0, #0 is just useless (as documented), and my 'objections' to it are satire. With that context, my 'rant' at the end of the blog should be more clear. And here I thought my satire was obvious. That said, can't say I don't love the serious technical discussion in these comments ;)

It's MOV and LSL that have the same binary encoding; everything is identical with exception to the imm5 vs the hardcoded 0's. MOV and LSL share the same op2 field of '00'. ROR and RRX share the op2 field of '11'. ROR and MOV have a similar binary encoding, but the op2 field is distinctly different in this case.

As a note, I'm basing this off of the v7-A and v7-R manual.

I 100% prefer text/book learning to lecture/video. But I guess not everyone is like us, so I tried experimenting with a dual format. Regarding the font, I never thought to change the ugly gray small font. I changed the CSS to make all 'paragraph' text 18pt (across the blog), for that specific post, it is now black. But be warned, if someone complains that it's too big, I will make it 32pt Comic Sans.

To let everyone in on a little !secret, the 'objections' to these encodings is satire, something that was laid on a bit thick at the end of this post. There have been no real objections to ARM so far. x86 is a different story, the AAD/AAM instructions being the biggest example. In that case, being able to do something at the machine level that the assembly level abstracts away (converting bases other than base 10). Regardless of any kind of usefulness, any non 1-to-1 mappings between abstractions highly interest me.