3 ms·
Author here. Yeah, I have a tendency to go into pretty big deep dives when I find stuff like this. It's so rewarding at the end, even if it does take a lot of t
by dougg3 2y ago
Author here. Yeah, I have a tendency to go into pretty big deep dives when I find stuff like this. It's so rewarding at the end, even if it does take a lot of time!
- mrandish 2y agoFinding a previously unknown undocumented instruction at this late date in a line of processors as prevalent and historically significant as the 68k is surprising. Congrats on your achievement! If someone does dive into fully characterizing the undocumented instruction so it can be properly supported in emulators (as you suggested), please post about it on HN. I suspect, like many undocumented CPU instructions, it was probably to help the original designers test or verify something during development but it would be interesting to know. While obviously a subjective judgement, a lot of people who hand coded assembler on 68k processors regard the ISA as especially elegant, powerful and fun to develop for. In many ways I think of it as peak CISC, thanks to its orthogonal instruction set and wildly flexible addressing modes. And of course the platforms which used it are legendary, from consumer (Mac/Lisa, Amiga, Atari ST, Sinclair QL) to workstations (SUN, Apollo, Quantel) to gaming (Sega Genesis, Neo Geo, Capcom, Atari, Namco, Sega, Taito, Konami) to embedded (automation, print/network controllers, synthesizers, appliances). I'm certainly biased but to this day the 68k (and its 8-bit little brother the 6809) are the only CPUs I still enjoy writing assembler on.
- dougg3 2y agoThank you! Yes, I will definitely make another post if and when someone figures out what the instruction does.
- userbinator 2y agoI suspect, like many undocumented CPU instructions, it was probably to help the original designers test or verify something during development but it would be interesting to know. Or simply be an emergent but unintended behaviour of the implementation, as is the case for most of the undocumented 6502, Z80, and x86 instructions I know of.
- bell-cot 2y ago> a lot of people who hand coded assembler on 68k processors regard the ISA as especially elegant, powerful and fun to develop for. In many ways I think of it as peak CISC, thanks to its orthogonal instruction set and wildly flexible addressing modes. I definitely agree...but I'd say Motorola really got carried away with those wildly flexible addressing modes. Which lead them into implementation, power draw, and gate-delay hells by the late 1980's and the 68040. The future was ever-rising transistor counts and clock speeds - and their 68k architecture just couldn't go there.
- mrandish 2y ago> I'd say Motorola really got carried away with those wildly flexible addressing modes. Yeah, while they could certainly be extremely powerful, I'll admit the edges of my 68000 programmer's reference card quickly got dog-eared from how often I'd need to remind myself exactly how some program-counter relative indexed redirection+offset instruction worked. Almost made me miss the days of simple 8-bit loads, stores, compares and branches being all we had. > The future was ever-rising transistor counts and clock speeds - and their 68k architecture just couldn't go there I've always wanted to understand more about why Motorola abandoned the 68k architecture. I understand the broad factors cited in the Wikipedia article and on RetroStackExchange but I don't recall anyone citing supporting the addressing modes specifically (though it makes sense). I never programmed x86 assembler but my sense was that ISA also had its own oddball complexities. I never understood if there was some fundamental conceptual difference between the 68k and x86 ISAs that prevented one from being able to scale into the future while the other could. Would love any more info or links if you have them handy.
- bell-cot 2y agoNot seriously detailed, but try this: https://userpages.umbc.edu/~vijay/mashey.on.risc.html https://userpages.umbc.edu/~vijay/mashey.on.risc.html Another way to view it: Motorola did not have a senior 68k implementation engineer, who could look down the road and push back against cool- or easy-sounding ideas for making 68k programmers happy. (I once heard that, with virtual memory, a single 68040 instruction could generate 16 page faults. No, that'll never happen in the real world - but once the spec' is final, the CPU implementation team has to lay out a chip that can handle every situation correctly. And if you're pipelining a sequence of "tough" instructions against corner-case data - yeah, that can be factorial hell.)