3 ms·
That article is from 2007, so I don't think we're going to get that promised update any time soon. I really wish they would have gotten around to it, because to
by ksaj 6y ago
That article is from 2007, so I don't think we're going to get that promised update any time soon. I really wish they would have gotten around to it, because toward the end they say:
"Another GAS's problem is that it still keeps very old standards, not all of which are the best choice."
I'd love to see some examples of those poor choice standards compared in similar fashion as the article's earlier examples. That would be pretty interesting. They might also be updated since then. Can't know without examples.
Their argument about jumps was a little bit brilliant. If your syntax (like AT&T's "gas") is:
operation [source],[destination]
then your jumps should have something before an included comma, to put the destination in the right field:
jmp $,destination ; $ alone in assembler means "here"
That would be crazy of course, since the source is implicit, and it would suggest you can somehow jump from other places. But not doing it makes the language inconsistent. Intel's destination-first syntax gets around that by lopping off the end instead of something from the middle. This is the same for other opcodes like INC and DEC (increment and decrement) where the source is implied by the destination where the answer is stored. Somehow that never occurred to me, and now I can't not notice it.
PUSH and POP kinda mess this up for either format though, since PUSH points to a source, and POP points to a destination. So for consistency, one of them is always backward. It's still less typing.
Also I'd (lightly) rebut the claim that Intel's assembler needs 2 steps to make a binary, and MASM doesn't. The Microsoft DOS compilers have a command line switch to invoke the linker for you. Intel's assembler doesn't, like the article says, but if you compile with the make command instead, you accomplish the same thing.
Also, Intel's compiler is actually 'as' and not 'gas.' GNU utils used to name it gas, but I only ever see it referred to as the original 'as' these days, and even then, it's linked (the file system type of link... now it's getting confusing!) to a binary with the target architecture in the name. But no 'gas'. This might have happened after the article was written, though.
- souprock 6y agoFor the jmp instruction, both source and destination are the rip register. That other thing is an immediate value. Really jmp is just mov or add, with the rip register. Like so: movq somelabel, %rip addq somelabel-%rip, %rip mov rip, _somelabel add rip, _somelabel-rip
- ksaj 6y agoIt was never legal to jump that way, though. And it wouldn't make sense if it was allowed by the cpu for your jump source to be somewhere you haven't been yet. So the $ "here" makes more sense, at least to me. Literally "from here, to there" versus "from there, to there." Here's a similar "illegal" re-envisioning of a call: push rip mov rip, _interrupt ; a weird illegal jump ... _interrupt: ... pop rip ; similarly illegal way to RET The workings are the same, but the cpu won't let you write it that way of course. The source and destination are still clear and intact because you start by pushing the source onto the stack before giving the destination, so it's at least good for demonstrating that bit of near-consistency in the Intel syntax. Part of the reason these rip shenanigans aren't allowed is because you'd have a hell of a time jumping or calling to a different SEG (segment), as INT always does, and the jumps can do if you need them to, because you'd have to push change the index pointer and the segment at the same time somehow. So you'd be limited to .COM (single segment memory images) file format with no interrupts if that's how you wanted to go about doing them. Simply "editing" rip, if you could, would stick you to a single memory segment.