I agree that indexing looks way better in Intel ("[ebx+3]") than in AT&T syntax ("2(%ebx)").
However, for me, AT&T's "mov X Y" for "move X to Y" feels better for me than Intel's "mov Y X" for "move Y from X" (who says that?). If they wanted to things in reverse, they should have named the instruction differently, for example as "load Y X" for "load Y from X" (as in "LDA #0xFF" from the 6502)
As for movl instead of mov, I like the 68K version (MOVE.L) better.
with coma being a synonym for equals, like mov x = y, hence it feels more natural to me.
But the biggest issues are address modes, specially the more complex ones and the macros seem very light weight in features when compared to the Intel world.
I love this comment. It shows how powerful the right metaphor can be in understanding something, which is something we obsess over at Dev Bootcamp when teaching students. It also shows how tiny affordances (http://en.wikipedia.org/wiki/Affordance) make us "think" specific thoughts. I mean, it's called "mov" so something must be moving, which means there must be a subject, object, and possibly an indirect object, right?
I see this more as a) an example of how well humans can learn to ignore misdirection (the word 'move' hints at src, dest arguments) and b) the first small step towards C:
- read "mov X,Y" as "X = Y"
- adjust syntax so that it allows "X = Y" (what you see is what you think)
- similarly, replace obscure syntax for indexed memory acces by such things as "X = Y[3]"
- getting annoyed with the seemingly random limitations of the language, add an expression parser that translates "X = 2 * Y + 3" into "X = 2 * Y" and "X = X + 3", each of which gets assembled into one instruction. For now, only allow expressions that get away with only using the result register for temporaries.
- use existing macro capabilities to build a library of control flow statements such as IF and WHILE.
- introduce standard way to call subroutines.
- introduce shorthand method for doing such calls: one for the call site that takes a couple of expressions as argument, and one for function entry that uses macros such as 'int' and 'char' to pop arguments from the call stack.
I wrote my first compiler in M68000 assembler in a similar fashion to your steps. I started by allowing it to recognize M68000 assembler opcodes, and when found it'd just copy the line to output, otherwise it'd parse and compile the line. You could use register names and sizes directly in the statements.
So e.g.
D0.W = 5
Would translate into:
MOVE.W #5, D0
I didn't use macros though - handling basic argument passing is simple enough.
As soon as I had the basics of procedures/functions, simple expressions and argument passing in place I started rewriting the compiler using it.
"It shows how powerful the right metaphor can be in understanding something"
Just like how I was taught the difference between "<" and ">". Our teacher drew the rest of Pac-Man around the "<" or ">" so that we'd think of "<" or ">" like the mouth of Pac-Man. It wants to eat the larger number. But that was back around 1983 when Pac-Man was all the rage (when I was drawing Pac-Man eating ghosts on my folders).
My elementary school teachers used a similar metaphor with alligators. But I never could remember which number it was that got eaten, so I just figured the bigger side was for the bigger number. Since an equal sign doesn’t have a “bigger side”, it would imply that both sides are the same. Then I wondered why they didn’t just teach that. Then I liked school even less.
(Oddly enough, my childhood intuition about equals signs isn’t historically accurate—the equality is actually supposed to be represented by the equal length of the two strokes.)
The greedy alligator always wants the bigger prey.
It took me a long time to differentiate the symbols because, before using the alligator metaphor, my teacher tried this one: cross a line that goes perperdicular to the bottom part of the symbol. If it turns into a 4 it's smaller than; otherwise, if it turns into a 7, then it's bigger than.
I remember seeing a "5 < 8" and thinking "ok, I know which number is smaller and which one is bigger, and I know how which symbol is named, but which one should I use?" For some reason it wasn't obvious to me that I should read the assertion from left to right. I just saw two numbers and I didn't know if I should indicate that one of them was bigger or that another was smaller—both assertions were true. I remember having a list of exercises to do as homework and just circling the bigger numbers in frustration.
When I hearded the alligator metaphor, however, I got it instantly.
wow. what? what's all this stuff about alligators and pac-men? Isn't the side with two lines just bigger than the pointy side? how do these new entities help? I'm really confused by the small side being the alligator that wants to eat the big side (or did i get that wrong?), let alone the stuff about 4s and 7s!
"Move" is called "load" on other architectures; indeed, the corresponding 8080 instruction is LD.
If x86 used LD instead of MOV, it would make more sense. LD AX,4 would be read as "load register AX with the value 4"; LD AX,BX would be "load AX with what's in BX"; LD AX,[SI] would be "load AX with what's in the memory location pointed to by SI" and so forth.
I agree that it does seem backwards initially to have OP DEST, SRC, but it does match the other ISAs that are still being used these days like ARM or PowerPC. I have found it really hard to go from working one day in PowerPC assembly to the next working in AT&T-format x86 because of the operand ordering. Plus all the other bits and pieces that make AT&T a pain, like the required sigils, LEA format, use of immediates with MOV, instruction size suffixes, etc.
However, for me, AT&T's "mov X Y" for "move X to Y" feels better for me than Intel's "mov Y X" for "move Y from X" (who says that?). If they wanted to things in reverse, they should have named the instruction differently, for example as "load Y X" for "load Y from X" (as in "LDA #0xFF" from the 6502)
As for movl instead of mov, I like the 68K version (MOVE.L) better.