5 ms·

Am I the only one who feels the "intro to x86" market is oversaturated?

tbirdz 10y ago
Seconding this. Is there even any advanced x86_64 assembly language material out there besides the AMD and Intel reference manuals?
- wmu 10y ago
  Probably no. I think when you reach some level of understanding, you'll use manuals. Then you know what you're looking for. :)
  - acdimalev 10y ago
    And once you start reading the docs on the more efficient but far less consistent 64-bit calling convention, you may find yourself choosing words to describe it other than the "improved" that this author opted for.
    - aktau 10y ago
      I take it you're a fan of the plan9 calling convention (f. ex.: all arguments and return value(s) are on the stack)? Curiously, it doesn't actually appear all that ineffecient. Go uses it AFAIK. I wonder whether anyone has studied it. I also wonder whether gccgo uses that convention or defaults to SysV x64.
      - acdimalev 10y ago
        I didn't know it was a System V thing. Thank you for cluing me in! I don't think of it in terms of like-vs-dislike. My observation is that it's a difficult thing to get right without a compiler, and thus avoided for introductory material. As far as I am aware, storing values in a register requires fewer instructions. However, I have never personally confirmed the performance difference of this calling convention. Handling of all calling conventions is one of the many things that I am personally much happier leaving up to GCC and LLVM in practice.
- plexchat 10y ago
  It's somewhat analogous to how we went from 16 bit registers to 32 bit registers with the extended opcode variants, so if you understand x86, x86_64 isn't really much of a stretch.
  - e12e 10y ago
    I only have a vague understanding of assembly in general, and x86_64 in general - but I thought that with so many more registers, the recommended style of programming can change quite a bit (hence aggressive use of registers for passing arguments to function calls in the x86_64 C ABIs)?
    - dkopi 10y ago
      That's less of an assembly issue and more of a compiler/calling convention issue. Assembly allows you to pass parameters on the stack or in registers. Calling conventions simply define a protocol for doing this consistently.
      - Annatar 10y ago
        Actually Id'd say that it's mostly the crappy processor design issue: for example, UltraSPARC has 32 physical registers in 32-bit mode, and 256 virtual registers (through register windows, specifically designed for compilers). Even Motorola 68000 with eight general purpose address registers and eight general purpose data registers is far more elegant than a 32-bit four register intel CPU. intel CPU is just crap from a design standpoint, and since they had to remain backward compatible, it's gotten a lot faster with lots and lots of tricks, but it still sucks in 32-bit mode. No amount of tricks will change that. It has to be run in 64-bit mode to gain a performance boost and simplify the code, whereas processors with fixed 32-bit instruction encoding run faster in 32-bit mode and code simplicity is a constant.
        vardump 10y ago
        While x86 is arguably pretty ugly, I think you're being unfair. > ... far more elegant than a 32-bit four register intel CPU. I count eight: EAX, EBX, ECX, EDX, ESI, EDI, EBP, ESP. x86 has also advantage of supporting arbitrary immediate values, so you don't need to allocate registers just for constants.

Seconding this. Is there even any advanced x86_64 assembly language material out there besides the AMD and Intel reference manuals?

wmu 10y ago
Probably no. I think when you reach some level of understanding, you'll use manuals. Then you know what you're looking for. :)
- acdimalev 10y ago
  And once you start reading the docs on the more efficient but far less consistent 64-bit calling convention, you may find yourself choosing words to describe it other than the "improved" that this author opted for.
  - aktau 10y ago
    I take it you're a fan of the plan9 calling convention (f. ex.: all arguments and return value(s) are on the stack)? Curiously, it doesn't actually appear all that ineffecient. Go uses it AFAIK. I wonder whether anyone has studied it. I also wonder whether gccgo uses that convention or defaults to SysV x64.
    - acdimalev 10y ago
      I didn't know it was a System V thing. Thank you for cluing me in! I don't think of it in terms of like-vs-dislike. My observation is that it's a difficult thing to get right without a compiler, and thus avoided for introductory material. As far as I am aware, storing values in a register requires fewer instructions. However, I have never personally confirmed the performance difference of this calling convention. Handling of all calling conventions is one of the many things that I am personally much happier leaving up to GCC and LLVM in practice.
plexchat 10y ago
It's somewhat analogous to how we went from 16 bit registers to 32 bit registers with the extended opcode variants, so if you understand x86, x86_64 isn't really much of a stretch.
- e12e 10y ago
  I only have a vague understanding of assembly in general, and x86_64 in general - but I thought that with so many more registers, the recommended style of programming can change quite a bit (hence aggressive use of registers for passing arguments to function calls in the x86_64 C ABIs)?
  - dkopi 10y ago
    That's less of an assembly issue and more of a compiler/calling convention issue. Assembly allows you to pass parameters on the stack or in registers. Calling conventions simply define a protocol for doing this consistently.
    - Annatar 10y ago
      Actually Id'd say that it's mostly the crappy processor design issue: for example, UltraSPARC has 32 physical registers in 32-bit mode, and 256 virtual registers (through register windows, specifically designed for compilers). Even Motorola 68000 with eight general purpose address registers and eight general purpose data registers is far more elegant than a 32-bit four register intel CPU. intel CPU is just crap from a design standpoint, and since they had to remain backward compatible, it's gotten a lot faster with lots and lots of tricks, but it still sucks in 32-bit mode. No amount of tricks will change that. It has to be run in 64-bit mode to gain a performance boost and simplify the code, whereas processors with fixed 32-bit instruction encoding run faster in 32-bit mode and code simplicity is a constant.
      - vardump 10y ago
        While x86 is arguably pretty ugly, I think you're being unfair. > ... far more elegant than a 32-bit four register intel CPU. I count eight: EAX, EBX, ECX, EDX, ESI, EDI, EBP, ESP. x86 has also advantage of supporting arbitrary immediate values, so you don't need to allocate registers just for constants.