5 ms·

One of the main reasons for learning assembly today is to do reverse engineering, for which the plumbing is just as important as the concepts.

by roel_v 6y ago

simias 6y ago
I mainly use assembly for optimization myself, in general to double-check that the compiler did what I expected it to do. I also sometimes use it when I do bare-metal programming or other very low level code, but that's pretty niche these days. But even more generally I think you won't have any trouble picking up x86 idiosyncrasies if you've familiarized yourself with ARM/MIPS/Z80 assembly. Although maybe MIPS would be a bad choice because it doesn't use flags which are an important concept for many assembly languages. IMO the key concepts for an assembler tutorial would be, out of the top of my head: - The stack, - banking registers, the frame pointer, - The various types of jumps/calls/branches and their differences, - Conditionals, - Calling conventions, - Banking/context switching/IRQs (at least for low level programming, not so important if you're only dealing with userland I suppose), That stuff exists on basically any architecture. Then you have things like immediate encoding and addressing modes which are also very important and architecture-specific. I suppose SIMD could be interesting as well, but these days it seems to be mostly done with intrinsics instead of raw assembly, at least in my experience.
- roel_v 6y ago
  Yes, when you study assembly as a general programming language, the same way you learn another language. But again, for people who are interested in reverse engineering, the focus is different, and you'll find that if you start looking for assembly tutorials online (and also the books on modern assembly, e.g. I have "Modern x64 assembly language programming" and "Windows 64 bit assembly language programming quick start" here next to me and those fit that description), a lot of those are for aspiring reverse engineers. The (numerical) optimization angle is a lot harder to find, agner.org probably being the exception. E.g., knowing what _main is and how to call an OS primitive is a lot more important when reverse engineering than knowing about context switching and simd. I was just trying to say, that's where the focus on a specific OS comes from, and a focus on things that people who do manual numerical optimization would consider irrelevant or at best tangential to what they consider 'important' in assembly.
derefr 6y ago
There's no reason that somebody's first exposure to bare-metal programming should be with the ISA they actually want to understand in practice, though. Although no obvious example is springing to mind (any help?), I'm pretty sure there are cases where it's faster to teach someone—even an adult!—a https://en.wikipedia.org/wiki/Lie-to-children https://en.wikipedia.org/wiki/Lie-to-children model of a system, and then teach them the actual system, than it is to teach them the actual system from the start. I believe that, for the same reason I believe that people get better at the reflex skills of a video game if early parts of the game hold back some of the game's mechanics, focusing on only a core subset. You're allowed to develop just those sub-skills in isolation, and get good at them, so that they can become subconscious-enough that you won't be distracted thinking about them any more by the time the new sub-skills are introduced. Honestly, I think a great way to learn bare-metal programming would be to not work with bare-metal at all, but rather to work with a virtual machine for a custom ISA, where that supported ISA has 100 different sub-variants (ranging from very simplified to very "realistic") and the VM supports all of them. You'd learn to work with the simplest ISA (e.g. target a compiler backend to it), then learn the next-simplest (and tweak your compiler to also emit the new instructions introduced), etc. Evolve from RISC to CISC, from stack-based to register-based, from SISD to SIMD, gradually add vector instructions, etc. By the end of a process like that, you'd understand a (fake) ISA nearly as complex as x86-64; but more importantly, you'd understand the why of it, not just the what. You'd understand the history behind each instruction, and why it has the options/limits it does. At that point, learning x86-64, or AArch64, or whatever else, would just be "learning the vocabulary", with no new skills per se.

One of the main reasons for learning assembly today is to do reverse engineering, for which the plumbing is just as important as the concepts.

by roel_v 6y ago

One of the main reasons for learning assembly today is to do reverse engineering, for which the plumbing is just as important as the concepts.

simias 6y ago

I mainly use assembly for optimization myself, in general to double-check that the compiler did what I expected it to do. I also sometimes use it when I do bare-metal programming or other very low level code, but that's pretty niche these days. But even more generally I think you won't have any trouble picking up x86 idiosyncrasies if you've familiarized yourself with ARM/MIPS/Z80 assembly. Although maybe MIPS would be a bad choice because it doesn't use flags which are an important concept for many assembly languages. IMO the key concepts for an assembler tutorial would be, out of the top of my head: - The stack, - banking registers, the frame pointer, - The various types of jumps/calls/branches and their differences, - Conditionals, - Calling conventions, - Banking/context switching/IRQs (at least for low level programming, not so important if you're only dealing with userland I suppose), That stuff exists on basically any architecture. Then you have things like immediate encoding and addressing modes which are also very important and architecture-specific. I suppose SIMD could be interesting as well, but these days it seems to be mostly done with intrinsics instead of raw assembly, at least in my experience.

roel_v 6y ago
Yes, when you study assembly as a general programming language, the same way you learn another language. But again, for people who are interested in reverse engineering, the focus is different, and you'll find that if you start looking for assembly tutorials online (and also the books on modern assembly, e.g. I have "Modern x64 assembly language programming" and "Windows 64 bit assembly language programming quick start" here next to me and those fit that description), a lot of those are for aspiring reverse engineers. The (numerical) optimization angle is a lot harder to find, agner.org probably being the exception. E.g., knowing what _main is and how to call an OS primitive is a lot more important when reverse engineering than knowing about context switching and simd. I was just trying to say, that's where the focus on a specific OS comes from, and a focus on things that people who do manual numerical optimization would consider irrelevant or at best tangential to what they consider 'important' in assembly.

derefr 6y ago

There's no reason that somebody's first exposure to bare-metal programming should be with the ISA they actually want to understand in practice, though. Although no obvious example is springing to mind (any help?), I'm pretty sure there are cases where it's faster to teach someone—even an adult!—a https://en.wikipedia.org/wiki/Lie-to-children https://en.wikipedia.org/wiki/Lie-to-children model of a system, and then teach them the actual system, than it is to teach them the actual system from the start. I believe that, for the same reason I believe that people get better at the reflex skills of a video game if early parts of the game hold back some of the game's mechanics, focusing on only a core subset. You're allowed to develop just those sub-skills in isolation, and get good at them, so that they can become subconscious-enough that you won't be distracted thinking about them any more by the time the new sub-skills are introduced. Honestly, I think a great way to learn bare-metal programming would be to not work with bare-metal at all, but rather to work with a virtual machine for a custom ISA, where that supported ISA has 100 different sub-variants (ranging from very simplified to very "realistic") and the VM supports all of them. You'd learn to work with the simplest ISA (e.g. target a compiler backend to it), then learn the next-simplest (and tweak your compiler to also emit the new instructions introduced), etc. Evolve from RISC to CISC, from stack-based to register-based, from SISD to SIMD, gradually add vector instructions, etc. By the end of a process like that, you'd understand a (fake) ISA nearly as complex as x86-64; but more importantly, you'd understand the why of it, not just the what. You'd understand the history behind each instruction, and why it has the options/limits it does. At that point, learning x86-64, or AArch64, or whatever else, would just be "learning the vocabulary", with no new skills per se.