Back when architectures were designed for human assembly programmers and not just as compiler targets. Having a simple and elegant instruction set was considered a selling point.
If you’re interested in learning an assembly language, you’d be hard-pressed to find a better one than m68k.
Back when architectures were designed for human assembly programmers and not just as compiler targets. Having a simple and elegant instruction set was considered a selling point
Turns out it also makes it hard to make a fast processor. Mashey believed it wasn’t the number of instructions, but the ergonomic and symmetrical forms that lead to things like memory-to-memory instructions, which makes it harder to optimize. (Memory decode, dependencies, etc. when it gets broken down into µops…)
Ironically, the ugly duckling of CISC, x86, is ugly in ways that mostly don’t matter for performance. IBM System/3x0 is actually pretty clean, and arguably on the borderline of RISC with clean mostly fixed instruction forms and mostly schewing memory to memory instructions. (Arguably, the Model 44 comes pretty close to RISC!) I don’t think it’s a coincidence that x86 and z are around today while the more aggressively assembly-friendly architectures like VAX and 68k died.
It isn’t at all a coincidence; x86 and the Z series are much easier to implement than the 68k or the VAX.
John Mashey discusses the difficulties with implementing a high-speed VAX here.
I think that refers to parsing by a machine, and indeed MIPS was designed to be very easy to parse (as were other RISC ISAs), but not to ease of writing the instructions by a human.
I’ve found MIPS to be somewhat obnoxious to write, but I realize my experiences refer to privileged code intended to work on multiple machines, so aren’t the typical MIPS experience.
Having worked on a MIPS implementation and the LLVM MIPS back end, I’d agree that MIPS is clean from the perspective of writing an assembler or instruction decoder, as long as we’re talking about MIPS IV and not the newer MIPS32 and MIPS64. That is; however, the only positive thing that I could think of to say about the ISA.
If you want to get an understanding of a simple close-to-the-metal environment, RISC-V is fine. If you want to write assembly code, it’s painful. The lack of complex addressing modes means that you end up burning registers and doing arithmetic for simple tasks. If you want to do complex things like bitfield manipulation, you either need to write a lot of logic with shifts and masks or you need to use an extension (I think the bitmanip extension is standardised now, but the cores from ETH have their own variants). There are lots of clunky things in RISC-V.
ARM (AArch32 or AArch64) is much nicer to use as an assembly programmer. Both are big instruction sets, but the addressing modes on ARM are really nice to work with (it’s almost as if they, unlike the RISC-V project, followed the RISC I methodology of examining the output from compilers and working out what the common sequences of operations were, before designing an instruction set).
Note that ARM doesn’t call itself a RISC ISA anymore, it calls itself a load-store architecture. This is one of the key points of RISC (memory-register and memory-memory instructions make out-of-order execution difficult), but they’re definitely not a small ISA. They do have a much more efficient encoding than RISC-V (which, in a massive case of premature optimisation, optimised the ISA to be simple to decode in an in-order pipeline).
Really Old-School Company’s Rosco-m68k is a 68010 SBC kit for $124 all-in (except shipping). I’m dreaming about getting one of those after I finish my Z180 CP/M kit. I grew up on 68k Macs, and have a warm place in my heart for the whole System 7 Mac era.
Edit: looks like there are now a backplane with expansion boards for the Rosco including video and RAM expansion. Gonna be a very expensive but fun 1983-fantasy computer if you build everything!
The last ones I was aware of were the Dragonball MCUs from Motorola / Freescale, which were m68k with no MMU. The later Dragonball MCUs were ARM based and I don’t think Freescale sells the m68k versions anymore. They can’t run NetBSD due to the lack of MMU.
Back when architectures were designed for human assembly programmers and not just as compiler targets. Having a simple and elegant instruction set was considered a selling point.
If you’re interested in learning an assembly language, you’d be hard-pressed to find a better one than m68k.
Turns out it also makes it hard to make a fast processor. Mashey believed it wasn’t the number of instructions, but the ergonomic and symmetrical forms that lead to things like memory-to-memory instructions, which makes it harder to optimize. (Memory decode, dependencies, etc. when it gets broken down into µops…)
Ironically, the ugly duckling of CISC, x86, is ugly in ways that mostly don’t matter for performance. IBM System/3x0 is actually pretty clean, and arguably on the borderline of RISC with clean mostly fixed instruction forms and mostly schewing memory to memory instructions. (Arguably, the Model 44 comes pretty close to RISC!) I don’t think it’s a coincidence that x86 and z are around today while the more aggressively assembly-friendly architectures like VAX and 68k died.
It isn’t at all a coincidence; x86 and the Z series are much easier to implement than the 68k or the VAX.
John Mashey discusses the difficulties with implementing a high-speed VAX here.
Someone who wrote several assemblers thinks MSP430, MIPS, and AVR8 are the cleanest architectures:
https://github.com/mikeakohn/naken_asm/issues/60#issuecomment-471514168
While I still love the m68k, See MIPS Run is the best processor architecture book I’ve ever read…
I think that refers to parsing by a machine, and indeed MIPS was designed to be very easy to parse (as were other RISC ISAs), but not to ease of writing the instructions by a human.
I’ve found MIPS to be somewhat obnoxious to write, but I realize my experiences refer to privileged code intended to work on multiple machines, so aren’t the typical MIPS experience.
Having worked on a MIPS implementation and the LLVM MIPS back end, I’d agree that MIPS is clean from the perspective of writing an assembler or instruction decoder, as long as we’re talking about MIPS IV and not the newer MIPS32 and MIPS64. That is; however, the only positive thing that I could think of to say about the ISA.
I think AVR is a good, modern-day contender that I would recommend to anyone looking to get started with Assembly.
risc-v?
If you want to get an understanding of a simple close-to-the-metal environment, RISC-V is fine. If you want to write assembly code, it’s painful. The lack of complex addressing modes means that you end up burning registers and doing arithmetic for simple tasks. If you want to do complex things like bitfield manipulation, you either need to write a lot of logic with shifts and masks or you need to use an extension (I think the bitmanip extension is standardised now, but the cores from ETH have their own variants). There are lots of clunky things in RISC-V.
ARM (AArch32 or AArch64) is much nicer to use as an assembly programmer. Both are big instruction sets, but the addressing modes on ARM are really nice to work with (it’s almost as if they, unlike the RISC-V project, followed the RISC I methodology of examining the output from compilers and working out what the common sequences of operations were, before designing an instruction set).
Note that ARM doesn’t call itself a RISC ISA anymore, it calls itself a load-store architecture. This is one of the key points of RISC (memory-register and memory-memory instructions make out-of-order execution difficult), but they’re definitely not a small ISA. They do have a much more efficient encoding than RISC-V (which, in a massive case of premature optimisation, optimised the ISA to be simple to decode in an in-order pipeline).
ah, I made the mistake of assuming that the smaller instruction set of the risc-v meant that it was easier to work with.
Warms the cockles of my heart to see 68K still getting love :)
Wonderful news! I know there have been earlier attempts to bring Clang to 68k, how far off is this from bringing up Clang as well?
Are there any m68k systems still in production?
An m68k SBC could be a lot of fun, especially if it were Classic Mac OS or Amiga compatible.
Retrobrew has a few 68k-based designs, both SBCs and as processor boards.
Cheers, what a great site! It’s like osdev.org, but a level or two further down the stack. I’ll be sure to check them out.
Really Old-School Company’s Rosco-m68k is a 68010 SBC kit for $124 all-in (except shipping). I’m dreaming about getting one of those after I finish my Z180 CP/M kit. I grew up on 68k Macs, and have a warm place in my heart for the whole System 7 Mac era.
Edit: looks like there are now a backplane with expansion boards for the Rosco including video and RAM expansion. Gonna be a very expensive but fun 1983-fantasy computer if you build everything!
The last ones I was aware of were the Dragonball MCUs from Motorola / Freescale, which were m68k with no MMU. The later Dragonball MCUs were ARM based and I don’t think Freescale sells the m68k versions anymore. They can’t run NetBSD due to the lack of MMU.
I see availability for the 030 in e.g. digikey. Apparently they are still being made.
These have MMU.