4 ms·
> In fact, we would argue that the study of assembly language is extremely important to the building of competent software engineers. Further, we would argue th
by ryao 4y ago
> In fact, we would argue that the study of assembly language is extremely important to the building of competent software engineers. Further, we would argue that teaching the x86 instruction set is cruel as that ISA was born in the 1970s and has simply gotten more muddled with age.
> The MIPS instruction set is another ISA that is often covered in College level courses. While kinder and gentler than the x86 ISA, the MIPS processor isn't nearly as relevant as the ARM family.
I disagree. My university taught me MIPS assembly and its only utility has been in enabling me to understand x86_64 assembly poorly. When I look at the disassembly of my code, it is in x86_64 assembly, yet I realized yesterday that I have no clue what the difference is between signed and unsigned subtraction on x86_64. Had that been covered in my university class, I would not be in a position where I need to reverse engineer how that works by working out the math based on the very succinct documentation.
I only recently dabbled with aarch64 and POWER9 because I felt inspired to try to make ZFS' fletcher4 checksum algorithm run faster on various architectures. I had no success on POWER9 due to the Talos II workstation being severely memory bandwidth limited, but had fairly good success on x86_64 and aarch64, although the PRs with that code are still works in progress.
A guide for NEON and SVE would be great, since that is the only aspect of the aarch64 assembly that I did not understand well enough to muddle through it in my recent fletcher4 adventures, but that does not appear to be here. Thankfully, Clang did an awesome job compiling GNU C dialect vector extensions into efficient, easy to understand NEON assembly (even if I had no clue about the notation used for registers), so I did not need to learn the syntax.
For students, I would suggest learning x86_64, since that is what they are going to be using and if they can learn that, they can learn just about any assembly language (although the RISC-V Vector Extension might pose some trouble). The broader industry shift from x86_64 to aarch64 is still years away and ARM seems determined to kill it before it is here by suing Qualcomm for wanting to build ARM processors under the license they already paid ARM to give them. ARM can say whatever they want in court, but at the end of the day, ARM IP now looks toxic. I hope RISC-V can take the baton from aarch64. It could very well be our only hope for a x86_64-free future given ARM's major strategic mistake.
- masklinn 4y ago> ARM seems determined to kill it before it is here by suing Qualcomm for wanting to build ARM processors under the license they already paid ARM to give them That is not what they are doing at all and it’s very dishonest of you to pretend it is.
- klelatti 4y agoIndeed. I'm really surprised that some seem to be saying that Arm trying to enforce the terms of contracts freely entered into by two of its customers is a bad thing for the wider ecosystem.
- billfruit 4y agoIs learning any sort of Assembly language a good investment of time? Is that time better spent more usefully studying other topics that help solve interesting problems? Are there interesting problems that require knowledgeable of Assembly language to solve? Would Dijsktra, for example have adviced teaching for or against teaching Assembly language?
- sandruso 4y agoUnderstanding lower levels can be satisfying for certain type of people. I find it very useful when you can reason about stuff that is mostly invisible to other people. But if you are building web apps then this stuff is 95% useless as you can’t leverage the knowledge because web apps are much higher level. If you are curious about this stuff definitely look into it. It may be worth to you.
- billfruit 4y agoNot just web apps, isn't most of assembly language just incidental details? Is it fundamental knowledge? I doubt.
- nottorp 4y agoMost is details you don't need. However knowing how a function call works, what kind of branching is available and how to do basic operations with collections (arrays or more) at the assembly level will allow you to write more efficient code in higher level languages.
- sandruso 4y agoIt is fundamental knowledge, but you can skip it thanks to higher levels of abstraction. In the end everything is just bunch of ones and zeroes and clever hardware architectures. Nand2tetris is great source for figuring out whether this is something you want to get in to.
- flohofwoe 4y agoAny sort of serious optimization work may require mulling over disassembly listings of compiler output (at least after you've exhausted the 'simple' high level optimization options).
- celrod 4y ago> yet I realized yesterday that I have no clue what the difference is between signed and unsigned subtraction on x86_64 It's two's complement. There is no difference between signed and unsigned for addition, subtraction, or multiplication. https://en.m.wikipedia.org/wiki/Two%27s_complement https://en.m.wikipedia.org/wiki/Two%27s_complement
- renox 4y agoIn the value no, in the condition code registers status, there may be differences.