Comment by mamonster 2 days ago
Biased opinion(because this is how I did it in uni): Before looking at modern x86, you should learn 32-bit MIPS.
It's hopelessly outdated as an architecture, but the instruction set is way more suited for teaching (and you should look at the classic procedure from Harris and Harris where they actually design a pipelined MIPS processor component by component to handle the instruction set).
People who say this rarely also recommend learning toki pona or Esperanto before learning a spoken language they have a practical need for. Some do, but few.
In don't think it makes sense to learn a "clean" language first. Always learn a useful language and never learn a language that has no organic utility as step 1 of learning a useful one.
Unless the person taking this advice will program MIPS devices, then go ahead.
This is only true if your goal is only to speak some language rather than be a linguist.
The analogy is a little off because most people do not much need to be linguists.
But programmers almost always benefit from being a linguist that can pick up any language and do some job and then the next job might be any other language.
The abstract language allows you to see the difference between the universal principles and the arbitrary quirks.
You don't think it's worth the abstract stage it to know that? I do.
Even though I'm not primarily a developer. This is just as an ordinary mere user of computers. Just the plain utility of being even basically literate and functional and do a little coding or modifying in any language that the current project happens to use is extremely valuable in whatever I want to do at any given time.
Not to mention the entirely other obvious thing that you almost always learn a simple version of any new thing rather than starting immediately with the most advanced and complex version.
No, this reasoning does not hold up to scrutiny.
Need-based learning is the way to go with this for sure. Z80 assembly (ZX Spectrum) used to be a popular online recommendation, it's probably a good thing it's no longer popular... On the other hand, I think most people who are casually interested in learning a bit more about assembly don't have a need, so aren't going to actually use it or do anything with it. If the need for any particular system just isn't there, just a weak desire to learn a little, learning fundamentals is a decent strategy, and picking a language that helps get to and express those fundamentals will be helpful even if you later on use a different language. What are the relevant fundamentals for assembly? Maybe just a story about how CPUs from the 70s sort of worked is fine. With spoken languages, there's not much difference in "cleaner" things like Esperanto vs. useful things like English in showcasing fundamentals like nouns and verbs. With assembly, x86 is kind of insane, so I think there are bigger differences.
Of course, some people might consider modern hardware advances to be the fundamentals. Like if you aren't learning about simd and so on, taking into account caches and multi-cores, what's even the point, sort of opinions. I can almost get behind that.
My biased opinion though is that if you want to learn beyond a casual level, you should definitely be learning something that is running on actual hardware, not some sort of emulation layer. x86 then comes back into prominence since most PCs are that. However in the context of a captive audience like students in a classroom, the teacher can decide on something less insane, more fun than things like figuring out how to take an -O0 compiled C file and optimize a loop (ignore -O2 will do it better), and more showcasing a "need" because unlike your x86 class assignment, you can't just trivially do it in a higher level language, and you can't just swap in an x86 chip to a PCB. My first introduction to real assembly in college was with a little PIC microcontroller to control a robot car. I knew a bit of x86 by then, just enough to compare, and it was such a breath of fresh air just to use something not x86. It could have been ARM (we later used an ARM chip to program an RTOS and do other embedded systems relevant stuff), or anything really, the important thing is it was real. In the quest for teaching a "simpler assembly" I know some schools have done things I consider absurd like having students learn some other architecture but can only run code in some provided emulator on Windows, not a real chip with real peripherals you need to write code to talk to.
Those are the ones I was fed in the early 00s and I can confirm they work fine for pedagogical purposes. But if it were my choice today, I think I'd go with THUMB on legacy 32-bit ARM chips. (This can even theoretically be used practically today: GBA games can be emulated on 3DS and probably also Switch.)
I suggest starting with 8-bit MCU assembly, like AVR or PIC, or even something like 6502. It's very easy and cheap to get started, anyone with an "arduino" could write assembly for it, and 8-bit assembly is still relevant for very low latency real-time systems, or cheap simple solutions. You can do a lot with 10MIPS 8-bit MCUs that has a bunch of easy I/O peripherals. It's easy and accessible. I think 32-bit assembly is less common because C/C++ is usually the right tool for most of the jobs a 32-bit CPU would be used for.
I think 6502 is a very good and accessible assembly language for beginners, and I've done a decent amount of work around it
I disagree. I did 6502 (and a bit of z80) in high school, those old Turbo-Pascal-embedded-assembly demoscene tutorials in high school and college, learned MIPS in college, learned msp430 (very risc-y) when working through microcorruption.com, wrote a (very simply) Cool-to-MIPS compiler working through the old Coursera compilers course, and wrote a 6502 emulator, AppleII emulator, and 6502 assembler.
I still feel completely intimidated and out of my depth with modern assembly. I have no idea where to start. There are just so many instructions, conventions, registers with strange names and conventions that include each other, etc. Add to that that many of the examples you see are trying to beat the compiler, so doing clever/wide stuff. A comprehensive, modern tutorial that starts simple but goes more or less the whole way would be welcome.
>I still feel completely intimidated and out of my depth with modern assembly. I have no idea where to start.
I'm not surprised. But keep in mind that "create something that works on a modern CPU and beats the compiler's output" is not the only possible goal of learning assembly programming. I would say it's not even the usual goal, and hasn't been for a long time.
It's not that bad if you don't expect too much of yourself. I could patch some software machine code just by drawing on my 6502 teenage experience from more than 20 years ago. x86 or IL ASM doesn't matter all that much. Core concepts are the same. Registers, stack, relative jumps conditioned on the contents of flag register.
One thing that tripped me up a bit is that on x86 standard practice is using "taking address" lea operation combined with weird addressing mode to do simple arithmetics. I had to ask ChatGPT wtf is that.
In the process I learned that 686 assembly is a very different beast and they don't play nicely with each other (or at all).
Even System/370 [0] architecture (mainframe) is a great place to start. There's a one-to-one correspondence between assembler instructions and machine instructions, which makes writing and debugging considerably easier. It's actually an incredibly robust processor architecture that's simple to understand.
[0] IBM System/370 Principles of Operation (the "big yellow book")
http://bitsavers.trailing-edge.com/pdf/ibm/370/princOps/GA22...
I might also suggest ARM. Way back in the day, one of my first-year CS modules included writing a rudimentary MIPS emulator for much the same reasons as above, but I came to that knowing 6502, x86 and ARM2 assembler already, having cut my teeth on Acorn stuff, and at the time I still preferred ARM2 out of all these for clarity. ARM obviously remains relevant today, albeit with many revisions.
I learned 6502 back in the 80's, when it was current. Definitely easier than x86, but I kind of wonder if a modern learner wouldn't constantly be wondering if they were missing something and whether they were actually learning anything on what is now a completely obsolete framework. x86 is more complex, but you can actually see it _do_ something rather than hope that the emulator you're running it on is actually faithful to a real electronic device.
Are delay slots unique to mips? They're a pretty significant aspect (complication) that I don't see anywhere else.
Also, the gp register- don't know of any other arch where you need to set something like that up to access global variables. It's another layer of indirection which makes the assembly code harder to read (especially PIC code that works off of the value of the t9 register)
SPARC has delay slots. Here's some code. The clr %o3 and restore %o0 are in the delay slots.
10082410 9de3bf98 save %sp, 0xffffff98, %sp
10082414 90102001 mov 1, %o0
10082418 92100018 mov %i0, %o1
1008241c 94100019 mov %i1, %o2
10082420 7fffff17 call dirList
10082424 96102000 clr %o3
10082428 81c7e008 ret
1008242c 91e80008 restore %o0I learned on Z80. It's also relatively simple (and a lot of fun).
Emu86/assembler/MIPS/key_words.py: https://github.com/gcallah/Emu86/blob/master/assembler/MIPS/...
Emu86.assembler.virtual_machine > MIPSMachine(VirtualMachine) , RISCVMachine(VirtualMachine) , IntelMachine(VirtualMachine) https://github.com/gcallah/Emu86/blob/b48725898f37dede3ab254...
Learn x in y minutes > "Where X=MIPS Assembly" https://learnxinyminutes.com/docs/mips/
If we are not doing Intel/ARM architectures, a lot can be said for learning PDP11 assembly. Among other things, is maps very cleanly into concepts central to higher level programming languages, like indirection.
I'd suggest RISC-V, not only because it is inevitable and rapidly growing the strongest ecosystem, or because the MIPS ISA is no more (company who owns it switched to RISC-V) but because it is free of microarchitecture spilling into ISA, which MIPS is guilty of.
From a programmer POV, RISC-V is not unlike MIPS, but much easier.
Or something like msp430, doing math on 16bit address space is fun and only 4 hex digits. All the concepts transfer.
I'd recommend RISC-V instead. It is close to MIPS assembly but more consistent without MIPS's quirks.
I believe it has already replaced MIPS for teaching assembly language at many universities. Another one I've seen a lot is the 8-bit MCU Intel 8051.