> 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.
> 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.
Indeed. 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.
Is 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?
>Would Dijsktra, for example have adviced teaching for or against teaching Assembly language?
Dijkstra makes a distinction between Computing Science and Computer Engineering. The former is the Theoretical Science part i.e. Mathematical Logic, Automata, Algorithms, Computability, Complexity etc. The latter is the design of practical machines where we can realize the running of algorithms from the former domain. Dijkstra did both but his interests/focus were more in the former domain.
However, he called the General-purpose Computer "A Radical Novelty" from the pov that it allowed us to do any computation that we can think of (subject to Mathematical limitations/Computability) unlike any other previous man-made inventions. Many of his EWDs talk about this. Given that Assembly language is the native language of a Computer and all Higher-level language abstraction constructs have to map to it there is great value in learning the structure of Assembly language and how to program using it. There is also the beauty of Engineering involved, where layers of abstraction come together in a harmonious manner to give you a Machine with almost limitless capabilities. Also note that Assembly language is the Computer Architecture view for a Programmer while Computer Organization is the engineering implementation of it.
The following two books are highly recommended for further understanding:
1) Code: The Hidden Language of Computer Hardware and Software by Charles Petzold.
2) Structured Computer Organization by Andrew Tanenbaum.
A minor niggle there: machine code is the native language of the computer. Assembly language is a slightly higher-level and slightly less expressive language. Most of the time, they can be seen as equivalent, but as a trivial example, a generation of us had to DB Z80 opcodes when using an 8080 assembler. More practically, things like breakpoints have to be set by writing binary to memory - there is no assembly language involved. At a less practical level, you can have things like self-modifying code, or code where the meaning changes depending on what byte offset you start.
Writing assembly language is a rather specialized skill that few people need to master nowadays.
Being able to read it, on the other hand, I find really useful for debugging. You can follow execution into places where you don't have code at hand, find code that was not translated the way you expected (e.g. due to surprising aggressive optimizations), etc.
> Is learning any sort of Assembly language a good investment of time?
Learning to understand Arm architecture specifically or computer architecture in general can be invaluable. A particular Assembly syntax is just a way of expressing what you want to do.
I would suggest reading a book about computer architecture or taking a course. And if you are like me and are interested in what complicated things hardware does to fulfil the needs of software, you might want to first read a book on operating systems (like OSTEP by Arpaci-Dusseaus, which is marvel of accessibility and challenge for students), because it will make you ask relevant question.
Understanding 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.
Most 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.
>> Are there interesting problems that require knowledgeable of Assembly language to solve?
If you find reverse engineering interesting, at minimum being able to read assembly is a must.
I only learn assembly for fun, e.g writing SNES/Sega/Atari games.
As a mobile application developer, obviously assembly is practically useless for work.
Any 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).
> 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.