3 ms·

I feel like X64 doesn't get enough love these days. I think new tutorials should be X64 first and then after you get a hang of it talk about X32. It's harder th

by _8j50 5y ago

I feel like X64 doesn't get enough love these days. I think new tutorials should be X64 first and then after you get a hang of it talk about X32. It's harder the other way around, especially when it comes to calling conventions.

Ygg2 5y ago
Umm, did anyone read the reference manual for x86_64? Intel's big enough to kill a goat (~2000). Add AMD on that and you can kill a small tribe of goats.
- sabas123 5y ago
  Depending on what you're after there is a lot more than 2000 pages of documentation :) That said, the C standard is also an impenetrable mess, yet people can start using it without resorting to it.
  - Ygg2 5y ago
    If you are reaching for assembly, usually that means digging into some optimizations. Those are highly obscure.
- _8j50 5y ago
  There are not that many compiler generated instructions both for X32 or X64 if you look at it by percentage of code. You have to look up the manual for rare instructions no matter what, you hardly need to read maybe a dozen pages to know enough to understand the common operations and control flow. My argument if you start with the current arch, that will be your frame of reference instead of X32 (why not X16 if earlier is better?)
mike256 5y ago
I think it's much easier to begin with x86. Especially when the assembled code is being run the way it is on this website. x64 is a little harder because just the switch to x64 mode alone almost fills the boot sector.
- Joker_vD 5y ago
  And then you lose the ability to temporarily switch to the real mode to call BIOS functions so you better load the rest of your program before switching to x64.
coopierez 5y ago
On the contrary, I felt that understanding where x86 had come from helped me understand the reason why the registers were named what they were, why some instructions are longer than others, etc. It's confusing as a beginner to encounter the "di" and "dx" registers, and to understand why the 8-bit version of "r13" is "r13b" but the 8-bit version of "rdx" is either "dh" or "dl".
- sabas123 5y ago
  I think if you start from a point where you need to know all the registers beforehand you already lost. I like x64 a lot more because IMO it allows you a few important memory related ones in x86 making life a lot simpler.
- _8j50 5y ago
  Wouldn't it be better if you knew about all the current registers first then learn about older types? I learned like most people X32 first and I feel like I still read X64 relative to X32.
  - coopierez 5y ago
    I suppose it depends how you learn! For some it is likely better to do what you suggested and start with what's current and then work backwards - but for me I needed to know why certain limitations were in place, and that required me to start at the beginning and work forwards. As a newer developer this is a problem I've had with computing in general - a lot of newer languages, web frameworks, etc. are solving problems that I only understand through seeing what came before me. For example - why should I care about memory ownership if I've never tried to write a large-scale C program?
mettamage 5y ago
I started with x86, after that x64 felt simply like a different flavor. There was more Googling to do, but I did that a ton already for x86, so I was used to the type of game I was playing.
HelloNurse 5y ago
New tutorials? Don't they all date from when 32 bit registers were new, 16 bit registers mainstream, and MMX and x87 the new complicated instruction set additions? It would be certainly a smaller tutorial, but historical perspective might be valuable for understanding cruft layers of design decisions that made sense decades ago and addressed problems that have ceased to exist.
raxxorrax 5y ago
You also need to define the system when talking about assembly, I think this is more relevant than the difference between architecture variants. I would recommend Linux because available documentation. Without doing any system specific syscalls and learning about calling conventions you won't get very far. https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_64.tbl https://github.com/torvalds/linux/blob/master/arch/x86/entry... (subject to change, see your specific kernel source) I think more fun is doing assembly on a µC without OS with some interesting peripherals and many MCUs have an instruction set inspired by x86.
- _8j50 5y ago
  I think it depends on your goals. I am with you for writing assembly. For reading compiler generated coder however, I think windows is ideal as a starting point because you don't often get spoiled by the availability if source code and debugging symbols.
pengaru 5y ago
x86's purely stack-oriented C ABI calling convention makes things far less tedious. In x86_64 sure it executes faster with the register passing, but what a miserable thing to read/write as a human. Maybe this is just a case of having learned and written 32-bit x86 assembler for years in my youth, but I strongly prefer it to x86_64.
- _8j50 5y ago
  But would you still prefer X32 if you started with X64? My argument is that some would not find it tediuous if that was the first thing they learned. Similar to how a python programmer would share your sentiment about C because he learned python first. I learned C first so while I accept that it is more verbose and more work in general, I enjoy writing C more.
  - pengaru 5y ago
    I think so. It's nice to have more registers and all, but the consistency of an entirely stack-oriented calling convention is simply more elegant and ergonomic IMHO. The register passing overflowing into stack-oriented at some arbitrary limit is just hideously warty, and obnoxious if you're actually writing assembly with C ABI function calling. Changing the signature of functions requires rearranging which registers are being populated, and if there's enough parameters some go in the stack, and if you've rearranged the order, now you're moving some from stack back to registers and visa versa. At least when everything was always going through the stack, you just rearranged their position in the stack. x86_64 will always be more annoying in this regard, it's not an ABI decision made with humans in mind at all. The assumption is (rightfully) that compilers are doing this work, and the perf win is significant.
    - _8j50 5y ago
      Fair enough, you have a good point there
- inkyoto 5y ago
  C stack-oriented ABI calling conventions also started with PDP-11, for which the first portable C compiler was written, and the convention then tagged along to nearly every other architecture as the pcc was progressively ported to other platforms. If a function return value could fit into %r0 on the PDP-11 (%ax/%eax/%rax on x86), it would be returned in there. %r1-%r4 would be used to pass function parameters in, if they could fit, and/or spill over into the stack. Heck, even UNIX system call conventions on x86 can be traced back to PDP-11, i.e. the syscall number is passed in %r0 (%eax) followed by a TRAP (INT on x86) instruction (can't remember which TRAP number, though).

by _8j50 5y ago

Ygg2 5y ago

Umm, did anyone read the reference manual for x86_64? Intel's big enough to kill a goat (~2000). Add AMD on that and you can kill a small tribe of goats.

sabas123 5y ago
Depending on what you're after there is a lot more than 2000 pages of documentation :) That said, the C standard is also an impenetrable mess, yet people can start using it without resorting to it.
- Ygg2 5y ago
  If you are reaching for assembly, usually that means digging into some optimizations. Those are highly obscure.
_8j50 5y ago
There are not that many compiler generated instructions both for X32 or X64 if you look at it by percentage of code. You have to look up the manual for rare instructions no matter what, you hardly need to read maybe a dozen pages to know enough to understand the common operations and control flow. My argument if you start with the current arch, that will be your frame of reference instead of X32 (why not X16 if earlier is better?)

mike256 5y ago

I think it's much easier to begin with x86. Especially when the assembled code is being run the way it is on this website. x64 is a little harder because just the switch to x64 mode alone almost fills the boot sector.

Joker_vD 5y ago
And then you lose the ability to temporarily switch to the real mode to call BIOS functions so you better load the rest of your program before switching to x64.

coopierez 5y ago

On the contrary, I felt that understanding where x86 had come from helped me understand the reason why the registers were named what they were, why some instructions are longer than others, etc. It's confusing as a beginner to encounter the "di" and "dx" registers, and to understand why the 8-bit version of "r13" is "r13b" but the 8-bit version of "rdx" is either "dh" or "dl".

sabas123 5y ago
I think if you start from a point where you need to know all the registers beforehand you already lost. I like x64 a lot more because IMO it allows you a few important memory related ones in x86 making life a lot simpler.
_8j50 5y ago
Wouldn't it be better if you knew about all the current registers first then learn about older types? I learned like most people X32 first and I feel like I still read X64 relative to X32.
- coopierez 5y ago
  I suppose it depends how you learn! For some it is likely better to do what you suggested and start with what's current and then work backwards - but for me I needed to know why certain limitations were in place, and that required me to start at the beginning and work forwards. As a newer developer this is a problem I've had with computing in general - a lot of newer languages, web frameworks, etc. are solving problems that I only understand through seeing what came before me. For example - why should I care about memory ownership if I've never tried to write a large-scale C program?

mettamage 5y ago

I started with x86, after that x64 felt simply like a different flavor. There was more Googling to do, but I did that a ton already for x86, so I was used to the type of game I was playing.

HelloNurse 5y ago

New tutorials? Don't they all date from when 32 bit registers were new, 16 bit registers mainstream, and MMX and x87 the new complicated instruction set additions? It would be certainly a smaller tutorial, but historical perspective might be valuable for understanding cruft layers of design decisions that made sense decades ago and addressed problems that have ceased to exist.

raxxorrax 5y ago

You also need to define the system when talking about assembly, I think this is more relevant than the difference between architecture variants. I would recommend Linux because available documentation. Without doing any system specific syscalls and learning about calling conventions you won't get very far. https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_64.tbl https://github.com/torvalds/linux/blob/master/arch/x86/entry... (subject to change, see your specific kernel source) I think more fun is doing assembly on a µC without OS with some interesting peripherals and many MCUs have an instruction set inspired by x86.

_8j50 5y ago
I think it depends on your goals. I am with you for writing assembly. For reading compiler generated coder however, I think windows is ideal as a starting point because you don't often get spoiled by the availability if source code and debugging symbols.

pengaru 5y ago

x86's purely stack-oriented C ABI calling convention makes things far less tedious. In x86_64 sure it executes faster with the register passing, but what a miserable thing to read/write as a human. Maybe this is just a case of having learned and written 32-bit x86 assembler for years in my youth, but I strongly prefer it to x86_64.

_8j50 5y ago
But would you still prefer X32 if you started with X64? My argument is that some would not find it tediuous if that was the first thing they learned. Similar to how a python programmer would share your sentiment about C because he learned python first. I learned C first so while I accept that it is more verbose and more work in general, I enjoy writing C more.
- pengaru 5y ago
  I think so. It's nice to have more registers and all, but the consistency of an entirely stack-oriented calling convention is simply more elegant and ergonomic IMHO. The register passing overflowing into stack-oriented at some arbitrary limit is just hideously warty, and obnoxious if you're actually writing assembly with C ABI function calling. Changing the signature of functions requires rearranging which registers are being populated, and if there's enough parameters some go in the stack, and if you've rearranged the order, now you're moving some from stack back to registers and visa versa. At least when everything was always going through the stack, you just rearranged their position in the stack. x86_64 will always be more annoying in this regard, it's not an ABI decision made with humans in mind at all. The assumption is (rightfully) that compilers are doing this work, and the perf win is significant.
  - _8j50 5y ago
    Fair enough, you have a good point there
inkyoto 5y ago
C stack-oriented ABI calling conventions also started with PDP-11, for which the first portable C compiler was written, and the convention then tagged along to nearly every other architecture as the pcc was progressively ported to other platforms. If a function return value could fit into %r0 on the PDP-11 (%ax/%eax/%rax on x86), it would be returned in there. %r1-%r4 would be used to pass function parameters in, if they could fit, and/or spill over into the stack. Heck, even UNIX system call conventions on x86 can be traced back to PDP-11, i.e. the syscall number is passed in %r0 (%eax) followed by a TRAP (INT on x86) instruction (can't remember which TRAP number, though).