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.

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)

>Are delay slots unique to mips?

No, several other architectures of that period have delay slots (80s/90s), and modern VLIWs/DSPs still often have them. Sometimes the slots longer than a single instruction.

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     %o0

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/

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'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.

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.

Comparing spoken language with programming is such a terrible comparison to make. The two even at a fundamental level have almost nothing in common. The brain uses completely different parts for programming and human language.

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...

Or something like msp430, doing math on 16bit address space is fun and only 4 hex digits. All the concepts transfer.

Working through the microcorruption.com challenges left me really liking msp430 assembly

It is probably one of the best ways to learn how computers work :)

I learned on the Motorola 68000 series. I can confirm, it is easier to learn on a smaller instruction set for a simpler architecture.

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.

I learned on Z80. It's also relatively simple (and a lot of fun).

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.

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).

Ah, interesting. I think, looking back, that "lea" is usually where I start getting confused!

I apparently also need to internalize harder that I should just ask llms about everything :-)

>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.

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.

MIPS is a load-store architecture and has branch delay slots, both of which make it complicated to learn for beginners. If you want to learn an obsolete ISA with no commercial relevance because it's simpler, I would recommend 68000 or 6502 instead.

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.)

Learning assembly on the 68HC11 was the keystone moment in understanding programming at an intuitive level for me. What I learned applies to this day.

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.