Okay, I guess I told a little fib. But I’ve got a good reason. I’ve been thinking this over for a while, and I still haven’t come to a decision. I want to do a few posts introducing an assembly language and the “style” of programming it, but I don’t know which assembly language to use. So, in the interest of better informing you (and giving myself an extra week to figure out an answer), I’ve decided to put some of my thought processes into words.
The contenders
I know a handful of assembly variants, and I know of quite a few more, especially if you count different versions of architectures as separate languages. Some of these are more useful for introductory purposes than others, while some are much more useful in actual work. These two subsets, unfortunately, don’t overlap much. But I’ve come up with four finalists for this coveted crown, and here they are, complete with my own justifications.
6502
If you’re older than about 25, then you’ve probably used a 6502-based system before, whether you knew it or not. It was a mainstay for 80s “home computers”, including the Apple II and Commodore 64, and a customized version was used in the NES. It’s still a hobbyist favorite, mostly for nostalgia reasons rather than any technical superiority, and there’s no sign that it will ever become truly extinct. (Bender, after all, has one in his head, which explains a lot.)
Pros:
- 8-bit processors are about as simple as you can get while still being useful.
- There’s a lot of work out there already, in terms of tutorials, programming guides, etc.
- An online assembler exists, which makes things much easier.
- Plenty of emulators are available, although these are usually for specific 6502 computers.
Cons:
- 8-bit can be very limiting, mostly because it is so simple.
- There aren’t many registers, which slows down a lot of work and means a lot of memory trickery.
- Despite what its followers might think, 6502 is pretty much a dead end for development, as it has been for about 20 years.
Early x86
By “early”, I specifically mean the 16-bit x86 processors, the 8086 and 80286. These are the CPUs of the first IBM-compatible personal computers, and the ancestors of the i5 and A10 we use today. You would think that would give it direct relevance, but you’d actually be wrong. Today’s x86 processors, when running in 64-bit mode, actually can’t directly run 16-bit code. But we’d be using an emulator of some sort, anyway, so that’s not a problem that would concern us.
Pros:
- Very familiar and widespread, as (a descendent of) x86 is still used in just about every PC today.
- 16-bit isn’t that much more complicated than 8-bit.
- All those old DOS assembly tutorials are out there, somewhere, and most of them contain useful information.
- Even though current processors can’t execute 16-bit code directly, you can still use one of the dozens of emulators out there, including DOSBox.
Cons:
- The segmented memory architecture is weird and hard to explain.
- It’s easy to fall into the trap of using skills and tricks that were relevant here in more modern applications, where they simply don’t carry over.
- A lot of people just don’t like x86 and think it’s horrible; I don’t understand this, but I respect it.
AVR
Atmel’s AVR line of microcontrollers is pretty popular in the embedded world. One of them powers the Arduino, for example. Thus, there’s actually a built-in market for AVR assembly, although most programmers now use C. Of course, AVR has its own problems, not the least is its odd way of segregating program and data memory.
Pros:
- Very relevant today as an embedded platform.
- A ton of support online, including tutorials, forums, etc.
- The assembly language and architecture, despite a few warts, is actually nice, in my opinion.
- Lots of good tools, including a port of GCC.
Cons:
- Emulator quality is hit or miss. (AVR Studio was okay when I used it 4 years ago, but it’s non-free and Windows only, and the free options are mostly beta quality.)
- The Harvard architecture (totally separate memory spaces for code and data) is used by almost nothing else today, and it’s cumbersome at best.
- AVR is very much a microcontroller platform, not a microprocessor one. It’s intended for use in embedded systems, not PCs.
MIPS
MIPS is a bit of an oddball. Sure, it’s used in a few places out there. There’s a port of Android to it, and MIPS CPUs were used in most of the 90s consoles, like the N64 and PlayStation. There’s not much modern development on it, though, except in the Chinese Loongson, which started out as a knock-off, but then became a true MIPS implementation. But its true value seems to be in its assembly language, which is often recommended as a good way to learn the ropes.
Pros:
- Fairly simple assembly language and a sensible architecture.
- Tools are widespread, including cross-compilers, emulators, and even native versions of Linux.
- RISC, if you like that. After all, “RISC is good”, to quote Hackers.
Cons:
- Not quite as relevant as it once was. (If I had written this 20 years ago, the choice would probably be between this and x86.)
- A bit more complex than the others, which actually removes some of the need for assembly.
- I don’t really know it that well, so I would have to learn it first.
The also-rans
Those aren’t the only assembly language platforms out there. There are quite a few that are popular enough that they could fit here, but I didn’t pick them for whatever reason. Some of them include:
-
PowerPC: Used in Macs from about a decade ago, as well as the consoles of the 2000s (GameCube, Wii, PS3, XBox 360), but I don’t know much about it, and it’s mostly on servers now.
-
68000: The 16-bit CPU from the Sega Genesis and the original Macintosh, later developed into a true 32-bit processor. It has its supporters, and it’s not that bad, but again, I don’t know it like I do the others.
-
Z80: This one was used by a few home computers, like the ZX80, Kaypro, and (my favorite) the TRS-80. It’s a transparent remake of the 8080 (forerunner to the 8086) with just enough detail changed to avoid lawsuits. But I know x86 better.
-
PIC: One of the most popular architectures in the 8-bit embedded world. I’ve read a little bit about it, and I don’t exactly like what I see. Its assembly requires a few contortions that I think distract from the task at hand.
-
ARM: The elephant in the room. Technically, ARM is a whole family of architectures, each slightly different, and that is the main problem. The tools are great, the assembly language isn’t half bad (but increasingly less necessary). It’s just that there’s too much choice.
-
MIX: Donald Knuth invented this fictional assembly language for his series The Art of Computer Programming. Then, after 30 years of work, he scrapped it for the next edition, replacing it with the “modern” MMIX. Neither one of them works here, in my opinion. MMIX has a lack of tool support (since it’s not a “real” machine language) and the best tutorial is Knuth’s book. MIX is even worse, since it’s based on the horrible architectures of the 60s and early 70s.
Better times ahead
Hopefully, I’ll come to a decision soon. Then I can start the hard part: actually making assembly language interesting. Wish me luck.