6 ms·

Oh man, 15 registers, each 32 bits wide, with indirect addressing modes... it would have been glorious! No more weird need to cram things into just the right re

Oh man, 15 registers, each 32 bits wide, with indirect addressing modes... it would have been glorious! No more weird need to cram things into just the right registers to do a string operation. Not as nice as a PDP-11 processor, but damned close!

13of40 4y ago
No segment registers, as well. A byte of memory is just where it says it is, and you can access [n] and [n+100000] in one breath.
- tom_ 4y ago
  You can't do [n+100000] - the displacement field for the equivalent addressing mode is 16 bits. I also wouldn't hold my breath while waiting for the 68000 to do anything... all the instructions are enormous, and they take ages to execute.
- NikkiA 4y ago
  Don't try just accessing a byte though, even though there are instructions for it it'll trap. I can't remember if working byte addressing got added in the 68010 or 68020.
  - tom_ 4y ago
    You could definitely access bytes? You couldn't do word or long accesses on odd addresses however. The 68000 doesn't have a pin for bit 0 of the address. (Byte accesses presumably fetch the word of interest and discard the 8 unwanted bits.)
- int_19h 4y ago
  But it also means that all your pointers are now 32-bit wide, no? On a machine where memory is measured in kilobytes, that is an expensive luxury.
pulvinar 4y ago
Well, not as pure as the PDP-11, sure, but it was actually nicer to program and use.
marssaxman 4y ago
It was glorious! It was the most fun I've ever had with assembly language (though the fact that hand-written assembly still mattered back then probably had a lot to do with that, too).
dboreham 4y ago
68k was nicer than a pdp-11 because it had 32-bit addressing. Edit: well, 24-bit physically, but flat linear address space and an instruction set that permitted 32-bit addressing.
- jandrese 4y ago
  Yes, and that "Only 24 bits of the 32 bit word are used" thing came back to bite Apple hard when the "32 bits for real" 68020 came out and the funny tricks they were pulling with the top 8 bits confused the processor.
bewaretheirs 4y ago
The register partitioning (eight "data" registers d0-d7 and eight "address" registers a0-a7, with a7 being the stack pointer) was probably the biggest wart.
- Findecanor 4y ago
  I like to see it the other way around: the partitioning was a smart way of doubling the number of registers that could be expressed in a fixed-length 16-bit instruction word. There are many computational instructions that don't make much sense on addresses, especially if you have rich address modes to begin with. And if you'd need to, there was the "movea" instruction for copying between the register files.
klodolph 4y ago
Indirect addressing, including memory indirect addressing, which takes a base address (register), an index (register), a size (immediate), two offsets (immediate), and an address stored in memory somewhere. You could, in one single instruction, struct B { int x, y, z; }; struct A { int a, b, c; struct B *ptr; }; void func(struct A *array, int i) { array[i].ptr->z = 3; } Unless I am remembering how it works incorrectly.
- bewaretheirs 4y ago
  godbolt doesn't seem to think so. This is a little closer: https://godbolt.org/z/5K4MEYe31 https://godbolt.org/z/5K4MEYe31 and IIRC there was also the "LEA" instruction ("Load Effective Address") which stored the computed memory address instead of fetching/storing to that address. And I believe some compilers would (ab)use that to do math as well (though this was complicated by the aX/dX register split)
  - mras0 4y ago
    The addressing modes do exist on 68020+ (https://www.nxp.com/files-static/archives/doc/ref_manual/M68000PRM.pdf https://www.nxp.com/files-static/archives/doc/ref_manual/M68... section 2.2), but I don't think any compiler will generate them (even with -mcpu=68020) as I think they're not actually faster than doing it the normal way (even if that costs a register), maybe slower, but I'd have to check the cycle counts. EDIT: Yeah, so if I'm not misreading MC68020UM the memory indirect mode is slower move.l #3,([6,a0,d0.l*8],4) ; 9 cycles best case vs. move.l 6(a0,d0.l*8),a0 ;4 move.l #3,4(a0) ; 3
- mras0 4y ago
  Only supported on 68020+ though, but yeah think it would be something like move.l #3,([6,a0,d0.l*8],4) (scale only goes up to 8 though)
zackmorris 4y ago
Ya 68k assembly was the simplest assembly language I ever used, far simpler than either x86 or z80. I embedded it in asm {} blocks in C++ back in the Mac LC days for innermost loops, and the great thing was that the compiler would even let you reference variables like "register int x;" declared outside the block, instead of having to keep track of r0-r31 (if I remember correctly). One of the only problems is that it's a very RISC-like instruction set, so is missing much of the high/low byte handling of x86, as well as fancier combined MOV/math/loop instructions with side effects that could be taken advantage of for games. Which in practice meant that the same code ran perhaps 2-4 times slower on Mac than PC. Unfortunately Apple crippled the memory bus on most of its products so as not to compete with its more expensive models like the Mac IIfx. So by the time the 486 DX4 came out, there was simply nothing comparable on the Mac side, and then the Pentium was the final nail in the coffin and Apple had to transition to PowerPC. But modern processors are so microcode-heavy, with advanced pipelining, branch prediction and instruction interleaving, that they can't be programmed by humans anymore, at least not anywhere near the level of optimizing compilers. GPUs also killed the golden age of innermost loop optimization in the late 1990s. If I could have one wish, it would be to revert all processor "progress" since the 68040 or possibly PowerPC 601 around 1995, and make something like RISC-V with under 1 million transistors, little or no cache, and 68k assembly or simpler. Then arrange them on a 2D grid. The 50 billion transistors of an Nvidia RTX 4080 would make for 50,000 cores, and even if we lose 1-2 orders of magnitude for interconnect, that's still 500 cores. I'd put at least a 16 GB memory directly above that, connected by vias, with a content-addressable caching scheme for in-memory processing. A scalable chip like that would give us 3 orders of magnitude more performance than we have today, and pull away at perhaps 100x improvement each decade. Maybe Apple's M1 will eventually do that stuff, but right now it's too mired in domain-specific hardware for video and AI. I view that with the same skepticism as DSLs and mourn the loss of symmetric multiprocessing. But I digress!
- convolvatron 4y ago
  I've worked on .. several? high core count 2d array machines, and they tend not to be to useful for general code because of limited memory bandwidth. some pipelines and embarrassingly parallel things work really well. generally machines with higher dimensional interconnect tend to be more useful I agree we shouldn't have completely abandoned these machines in the 90s. the massive resurgence we see of vector and simd today proves that there was substantial value - and maybe the software story would be a lot better if we hadn't have taken a 20 year piss break.
UncleOxidant 4y ago
I know, right? Just think about what could have been if IBM had selected the 68K. An assembly language that was actually pretty pleasant to program in. Motorola would probably be the Intel of now. Intel would maybe still be making memory (so kind of like Micron and probably similar in size).
- speed_spread 4y ago
  I keep reading here great things about the 68k. What made Motorola diverge from it and invest in a whole new arch (88k) rather than keep pushing the 68k line? Intel succeeded in evolving x86 despite it being an originally subpar design, surely the 68k could have been taken further more easily?
  - ghaff 4y ago
    At some point (maybe the 68040?), the 68K line started to decline in popularity and there was a significant contingent of the industry that was convinced that RISC was the future (not that they were really wrong). The big Unix system companies were mostly doing their own RISC designs and Motorola figured that they had a significant market in the second-tier players like Data General that weren't going to do their own RISC designs. Intel did try to do RISC unsuccessfully with the i860--which also had some sort of VLIW mode, which makes their later Itanium even harder to understand.
  - cmrdporcupine 4y ago
    Lower sales. Bad management. And there was a consensus at that point that CISC was a dead-end and RISC was the future. Also, they did in fact take the 68k further (ColdFire) but too late, long after they had pushed their serious customers to PowerPC. Intel was making enough coin from x86 that they were reluctant to EOL it in favour of something RISC. Not that they didn't try. Multiple times (Itanium being the worst, though much later). But each time their replacement failed to ignite, and Intel pulled back from the brink and they pushed something that was a noticeable incremental improvement while keeping backward compatibility. And with the Pentium & the ISAs that followed they just seemed to pull a rabbit from a hat. They made the x86 CISC architecture scale in a way that pundits at least? didn't seem to think was possible. Motorola didn't invest in time in doing for 68k what Intel did for x86 with the Pentium. And they screwed over their customers as a result. They basically told everyone (Apple, NeXT, various workstation makers, etc.) to go to 88k. 88k was an architectural failure. So then they did PowerPC along with IBM and others. And people who used 68k previously either went PowerPC (Apple) or rolled their own RISC (Sun with SPARC, HP with PA-RISC, etc.) or just left the market entirely (Apple, Commodore). ColdFire is roughly to the 68k what Pentium II or so was to the x86 line. It's actually quite nice. They dropped a couple things from 68k but it's about 90% compatible, and can do a very effective software emulation to make itself 100%. But it got pushed basically only as a microcontroller or specialist (routers, ethernet switches, etc.) architecture. You can still buy them from NXP I believe. These days I don't like big-endian. And the separate address vs data registers seems weird now. But the 68k instruction set was overally very nice. I do imagine sometimes an alternate timeline where Motorola had rolled ColdFire out sooner as an MPU line for consumer stuff and Apple, etc. had used that instead of going PowerPC. I wonder what a 64-bit 68k would have looked like. IMHO Apple wasted a whole pile of engineering years getting MacOS classic to port over natively to PowerPC. It was extremely unstable and large parts were emulated 68k code for years. It might have saved them some unprofitable years, who knows? They seem to have finally learned the lesson and they own their own CPU now.

13of40 4y ago

No segment registers, as well. A byte of memory is just where it says it is, and you can access [n] and [n+100000] in one breath.

tom_ 4y ago
You can't do [n+100000] - the displacement field for the equivalent addressing mode is 16 bits. I also wouldn't hold my breath while waiting for the 68000 to do anything... all the instructions are enormous, and they take ages to execute.
NikkiA 4y ago
Don't try just accessing a byte though, even though there are instructions for it it'll trap. I can't remember if working byte addressing got added in the 68010 or 68020.
- tom_ 4y ago
  You could definitely access bytes? You couldn't do word or long accesses on odd addresses however. The 68000 doesn't have a pin for bit 0 of the address. (Byte accesses presumably fetch the word of interest and discard the 8 unwanted bits.)
int_19h 4y ago
But it also means that all your pointers are now 32-bit wide, no? On a machine where memory is measured in kilobytes, that is an expensive luxury.

pulvinar 4y ago

Well, not as pure as the PDP-11, sure, but it was actually nicer to program and use.

marssaxman 4y ago

It was glorious! It was the most fun I've ever had with assembly language (though the fact that hand-written assembly still mattered back then probably had a lot to do with that, too).

dboreham 4y ago

68k was nicer than a pdp-11 because it had 32-bit addressing. Edit: well, 24-bit physically, but flat linear address space and an instruction set that permitted 32-bit addressing.

jandrese 4y ago
Yes, and that "Only 24 bits of the 32 bit word are used" thing came back to bite Apple hard when the "32 bits for real" 68020 came out and the funny tricks they were pulling with the top 8 bits confused the processor.

bewaretheirs 4y ago

The register partitioning (eight "data" registers d0-d7 and eight "address" registers a0-a7, with a7 being the stack pointer) was probably the biggest wart.

Findecanor 4y ago
I like to see it the other way around: the partitioning was a smart way of doubling the number of registers that could be expressed in a fixed-length 16-bit instruction word. There are many computational instructions that don't make much sense on addresses, especially if you have rich address modes to begin with. And if you'd need to, there was the "movea" instruction for copying between the register files.

klodolph 4y ago

Indirect addressing, including memory indirect addressing, which takes a base address (register), an index (register), a size (immediate), two offsets (immediate), and an address stored in memory somewhere. You could, in one single instruction, struct B { int x, y, z; }; struct A { int a, b, c; struct B *ptr; }; void func(struct A *array, int i) { array[i].ptr->z = 3; } Unless I am remembering how it works incorrectly.

bewaretheirs 4y ago
godbolt doesn't seem to think so. This is a little closer: https://godbolt.org/z/5K4MEYe31 https://godbolt.org/z/5K4MEYe31 and IIRC there was also the "LEA" instruction ("Load Effective Address") which stored the computed memory address instead of fetching/storing to that address. And I believe some compilers would (ab)use that to do math as well (though this was complicated by the aX/dX register split)
- mras0 4y ago
  The addressing modes do exist on 68020+ (https://www.nxp.com/files-static/archives/doc/ref_manual/M68000PRM.pdf https://www.nxp.com/files-static/archives/doc/ref_manual/M68... section 2.2), but I don't think any compiler will generate them (even with -mcpu=68020) as I think they're not actually faster than doing it the normal way (even if that costs a register), maybe slower, but I'd have to check the cycle counts. EDIT: Yeah, so if I'm not misreading MC68020UM the memory indirect mode is slower move.l #3,([6,a0,d0.l*8],4) ; 9 cycles best case vs. move.l 6(a0,d0.l*8),a0 ;4 move.l #3,4(a0) ; 3
mras0 4y ago
Only supported on 68020+ though, but yeah think it would be something like move.l #3,([6,a0,d0.l*8],4) (scale only goes up to 8 though)

zackmorris 4y ago

Ya 68k assembly was the simplest assembly language I ever used, far simpler than either x86 or z80. I embedded it in asm {} blocks in C++ back in the Mac LC days for innermost loops, and the great thing was that the compiler would even let you reference variables like "register int x;" declared outside the block, instead of having to keep track of r0-r31 (if I remember correctly). One of the only problems is that it's a very RISC-like instruction set, so is missing much of the high/low byte handling of x86, as well as fancier combined MOV/math/loop instructions with side effects that could be taken advantage of for games. Which in practice meant that the same code ran perhaps 2-4 times slower on Mac than PC. Unfortunately Apple crippled the memory bus on most of its products so as not to compete with its more expensive models like the Mac IIfx. So by the time the 486 DX4 came out, there was simply nothing comparable on the Mac side, and then the Pentium was the final nail in the coffin and Apple had to transition to PowerPC. But modern processors are so microcode-heavy, with advanced pipelining, branch prediction and instruction interleaving, that they can't be programmed by humans anymore, at least not anywhere near the level of optimizing compilers. GPUs also killed the golden age of innermost loop optimization in the late 1990s. If I could have one wish, it would be to revert all processor "progress" since the 68040 or possibly PowerPC 601 around 1995, and make something like RISC-V with under 1 million transistors, little or no cache, and 68k assembly or simpler. Then arrange them on a 2D grid. The 50 billion transistors of an Nvidia RTX 4080 would make for 50,000 cores, and even if we lose 1-2 orders of magnitude for interconnect, that's still 500 cores. I'd put at least a 16 GB memory directly above that, connected by vias, with a content-addressable caching scheme for in-memory processing. A scalable chip like that would give us 3 orders of magnitude more performance than we have today, and pull away at perhaps 100x improvement each decade. Maybe Apple's M1 will eventually do that stuff, but right now it's too mired in domain-specific hardware for video and AI. I view that with the same skepticism as DSLs and mourn the loss of symmetric multiprocessing. But I digress!

convolvatron 4y ago
I've worked on .. several? high core count 2d array machines, and they tend not to be to useful for general code because of limited memory bandwidth. some pipelines and embarrassingly parallel things work really well. generally machines with higher dimensional interconnect tend to be more useful I agree we shouldn't have completely abandoned these machines in the 90s. the massive resurgence we see of vector and simd today proves that there was substantial value - and maybe the software story would be a lot better if we hadn't have taken a 20 year piss break.

UncleOxidant 4y ago

I know, right? Just think about what could have been if IBM had selected the 68K. An assembly language that was actually pretty pleasant to program in. Motorola would probably be the Intel of now. Intel would maybe still be making memory (so kind of like Micron and probably similar in size).

speed_spread 4y ago
I keep reading here great things about the 68k. What made Motorola diverge from it and invest in a whole new arch (88k) rather than keep pushing the 68k line? Intel succeeded in evolving x86 despite it being an originally subpar design, surely the 68k could have been taken further more easily?
- ghaff 4y ago
  At some point (maybe the 68040?), the 68K line started to decline in popularity and there was a significant contingent of the industry that was convinced that RISC was the future (not that they were really wrong). The big Unix system companies were mostly doing their own RISC designs and Motorola figured that they had a significant market in the second-tier players like Data General that weren't going to do their own RISC designs. Intel did try to do RISC unsuccessfully with the i860--which also had some sort of VLIW mode, which makes their later Itanium even harder to understand.
- cmrdporcupine 4y ago
  Lower sales. Bad management. And there was a consensus at that point that CISC was a dead-end and RISC was the future. Also, they did in fact take the 68k further (ColdFire) but too late, long after they had pushed their serious customers to PowerPC. Intel was making enough coin from x86 that they were reluctant to EOL it in favour of something RISC. Not that they didn't try. Multiple times (Itanium being the worst, though much later). But each time their replacement failed to ignite, and Intel pulled back from the brink and they pushed something that was a noticeable incremental improvement while keeping backward compatibility. And with the Pentium & the ISAs that followed they just seemed to pull a rabbit from a hat. They made the x86 CISC architecture scale in a way that pundits at least? didn't seem to think was possible. Motorola didn't invest in time in doing for 68k what Intel did for x86 with the Pentium. And they screwed over their customers as a result. They basically told everyone (Apple, NeXT, various workstation makers, etc.) to go to 88k. 88k was an architectural failure. So then they did PowerPC along with IBM and others. And people who used 68k previously either went PowerPC (Apple) or rolled their own RISC (Sun with SPARC, HP with PA-RISC, etc.) or just left the market entirely (Apple, Commodore). ColdFire is roughly to the 68k what Pentium II or so was to the x86 line. It's actually quite nice. They dropped a couple things from 68k but it's about 90% compatible, and can do a very effective software emulation to make itself 100%. But it got pushed basically only as a microcontroller or specialist (routers, ethernet switches, etc.) architecture. You can still buy them from NXP I believe. These days I don't like big-endian. And the separate address vs data registers seems weird now. But the 68k instruction set was overally very nice. I do imagine sometimes an alternate timeline where Motorola had rolled ColdFire out sooner as an MPU line for consumer stuff and Apple, etc. had used that instead of going PowerPC. I wonder what a 64-bit 68k would have looked like. IMHO Apple wasted a whole pile of engineering years getting MacOS classic to port over natively to PowerPC. It was extremely unstable and large parts were emulated 68k code for years. It might have saved them some unprofitable years, who knows? They seem to have finally learned the lesson and they own their own CPU now.