4 ms·

Computer science curriculums vary wildly. And just because you were taught assembly and how a cpu works, doesn't mean you learned how to do it on unix or even x

Computer science curriculums vary wildly. And just because you were taught assembly and how a cpu works, doesn't mean you learned how to do it on unix or even x86. (My college taught with the spim mips emulator. I also taught myself dos assembly when I was younger, but this is the first time I've seen unix assembly.)

Locke1689 16y ago
Nah, what you're seeing here is relatively poor, old, IA32, AT&T-style (which means GCC targeted), Linux-targeted assembly code. This is not the article I would use to learn about Linux, operating systems, or assembly (although it's more accurate to say you learn "an ISA" instead of "assembly").
- recoil 16y ago
  The article uses Nasm not GCC (or rather, not Gas - though Gas supports Intel syntax too now, afaik), and is definitely using Intel syntax. Note for instance the unintuitive order of source and destination in the MOV calls and the lack of delimiters on the operands, amongst other things. [edit: clarification]
  - barrkel 16y ago
    I strongly object to your characterization; it's highly dependent on what you're familiar with. MOV calls map intuitively to assignment, and with assignment, the LHS is the destination and the RHS is the value. And Intel syntax uses type inference to deduce the width of operands, and only requires DWORD PTR / WORD PTR / BYTE PTR etc. to disambiguate when it's necessary. (I have a very strong personal preference for the Intel syntax.)
    - recoil 16y ago
      I prefer Intel syntax too, in every other respect other than order of operands. That's really just because it differs from the only other assembly language I've ever used (68k). I still think it's unintuitive, but it's no worse than, say, the order of arguments to the Unix 'ln' command. You get used to it. The comment about the lack of delimiters was not a value judgement; I was just pointing out one of the obvious signs that the article wasn't using AT&T syntax. I think that having to stick $ on immediate operands is particularly annoying, for instance.
      - mgedmin 16y ago
        And the trick to getting used to things is finding the right mnemonic. I used to get tripped up by 'ln -s' all the time, until I realized that if I thought about 'cp src dst' but with 'cp' replaced 'cp' with 'ln -s' it suddenly made sense. Likewise Intel assembly's mov statement and its similarity with assignment statements that barrkel mentioned. Whether something seems intuitive or not depends on the analogy you prefer, or even your choice of words. E.g. look at 2D coordinates for a terminal character cell: if you think of them in terms of (x, y), you will find that order intuitive, but if you think (row, col), you'll find the opposite order intuitive.
deleted 16y ago
[deleted]

Locke1689 16y ago

Nah, what you're seeing here is relatively poor, old, IA32, AT&T-style (which means GCC targeted), Linux-targeted assembly code. This is not the article I would use to learn about Linux, operating systems, or assembly (although it's more accurate to say you learn "an ISA" instead of "assembly").

recoil 16y ago
The article uses Nasm not GCC (or rather, not Gas - though Gas supports Intel syntax too now, afaik), and is definitely using Intel syntax. Note for instance the unintuitive order of source and destination in the MOV calls and the lack of delimiters on the operands, amongst other things. [edit: clarification]
- barrkel 16y ago
  I strongly object to your characterization; it's highly dependent on what you're familiar with. MOV calls map intuitively to assignment, and with assignment, the LHS is the destination and the RHS is the value. And Intel syntax uses type inference to deduce the width of operands, and only requires DWORD PTR / WORD PTR / BYTE PTR etc. to disambiguate when it's necessary. (I have a very strong personal preference for the Intel syntax.)
  - recoil 16y ago
    I prefer Intel syntax too, in every other respect other than order of operands. That's really just because it differs from the only other assembly language I've ever used (68k). I still think it's unintuitive, but it's no worse than, say, the order of arguments to the Unix 'ln' command. You get used to it. The comment about the lack of delimiters was not a value judgement; I was just pointing out one of the obvious signs that the article wasn't using AT&T syntax. I think that having to stick $ on immediate operands is particularly annoying, for instance.
    - mgedmin 16y ago
      And the trick to getting used to things is finding the right mnemonic. I used to get tripped up by 'ln -s' all the time, until I realized that if I thought about 'cp src dst' but with 'cp' replaced 'cp' with 'ln -s' it suddenly made sense. Likewise Intel assembly's mov statement and its similarity with assignment statements that barrkel mentioned. Whether something seems intuitive or not depends on the analogy you prefer, or even your choice of words. E.g. look at 2D coordinates for a terminal character cell: if you think of them in terms of (x, y), you will find that order intuitive, but if you think (row, col), you'll find the opposite order intuitive.

deleted 16y ago

[deleted]