That was my first thought when seeing what these opcodes do. Just a result of a random mix of various parts of cpu in action. Thanks for confirming it!

This is also, what this article is actually about. It's just from a more "hermeneutic" perspective, rather than a bottom-up approach based on an analysis of the hardware.

It was my understanding that this sort of combinatorial logic is used by every CPU's control unit - is this outdated? What do modern chips use now?

I'm not a semiconductor engineer, but it is my understanding that most CPUs today either use a PROM, which is programmed at the factory the correct version/variant for that part, or (a sometimes compacted?) variant of mask ROM which is produced automatically by some EDA tool(s) from the final production version of the ROM.

Mask ROM usually is just used as a big lookup table which replaces the combinatorial logic by just explicitly matching each input bitstring to the correct bitstring to control the ALU, etc. (along with some sort of state-machine for VLIW ISAs).

Moving to a ROM-style architecture makes development a little more straightforward because modifying instruction decoder only requires burning a different bitstring into a PROM rather than redesigning a combinatorial logic circuit and then manufacturing an entirely new chip.

A ROM-based architecture probably makes microcode updates easier to design into a CPU as well, because you can basically just overlay the microcode over the existing ROM and patch, at runtime, essentially any part of the instruction decode (or whatever else you've designed in the ROM) on an unmodified production IC.

I imagine that the combinatorial logic approach isn't really used anywhere today (for new designs) because of how "cheap" gates are considered to be in a digital IC design, but I could be entirely wrong about this (I'm not in the industry).

I think you're confusing instruction ROMs and instruction decode/sequencing ROMs.

What's being discussed is at the same level as microcode, whereas most of the distinctions you're making apply to the normal code storage ROMs. For instance modern microcode is nearly never a PROM.

Additionally combinatorial logic is generally made out of cheap gates, the two concepts aren't in conflict, but instead orthogonal.

I was specifically referring to the process of instruction decode, but I may be using the incorrect terminology.

My understanding (as explained to me by someone who did work on some CPU-like ASICs) was that they were able to produce the early versions of ICs with some form of "PROM" (possibly not the correct term) which could then be one-time programmed so that they didn't have to pay for a new set of masks if they wanted to change any of their instruction decode (or whatever they had wired into the "PROM") logic.

All they had to do was burn a new version into a blank chip and test/use it from there.

The company in question was producing low-volume, high cost products for a narrow niche and so I don't know if they had to throw away some die space to have this "PROM-like" feature and if that is still how things are done today.

It's not just die space, but much slower timing that's the main problem in most cases. At that point it's a lot better to iterate via hardware emulation.

Oh right. I didn't think about the extra time that signal propagation through a big ugly ROM would take.

I my comment earlier about EDA tools being able to "simplify" the ROM into the die was probably a paraphrasing of what I was told about a tool. The tool (or workflow) allowed a designer to go from a working prototype microcode ROM to a hardcoded gate circuit (presumably by the same sort of process that one can go through to simplify a logic statement that is in disjunctive-normal form).

This was information passed on to me second hand from quite a few years back now so I probably should've tried to look up some primary sources before writing my comment! Oh well.

I don't know :) But for instance on the Z80, even though there's a clear opcode bit pattern (see http://www.z80.info/decoding.htm), any holes in the instruction set that make no sense have been "plugged" with official special-case instructions.

For instance the opcode 0x76 should be "LD (HL),(HL)", but instead this opcode has been reused for the HALT instruction.

The Z80 has undocumented instructions too (for instance in the prefix-ranges for the IX and IY indexed instructions), but those behave the same as documented instructions, except that they cost more cycles. This seems to indicate that the instruction decoding on the Z80 works quite a bit different than on the 6502.

Normally you want to reserve the "unused" opcodes in order to assign them new semantics (new instructions) later in an updated CPU model. To discourage programs from using those yet unassigned opcodes, CPUs usually trap if they encounter them (i.e. raise an "illegal instruction" interrupt).

The 6502 approach of just executing some random (but deterministic) logic leads to a situation where the "illegal" opcodes cannot be expected to be unused (programs actually use them), and where assigning them new semantics effectively breaks compatibility with existing programs. That’s why CPUs usually invest in the extra logic necessary to give those opcodes undesirable behavior (i.e. traps).

> compared to more complex and more expensive CPUs like the Z80

It preceded the Z80 by a year or two.

Yes, but that wasn't really the point. The 65xx series was a result of Chuck Peddle initially proposing a drastically cost-cut design similar to the 68xx series from Motorola. When Motorola didn't want to do it, Peddle and other Motorola staff left for MOS Technologies to realise the design. So the simplicity of the 65xx had less to do with when it was released than with an explicit design goal to be extremely simple and cheap.

Is there more on this proposal (e.g., a preserved document)?

Something I found especially interesting is the decision to not implement "STX abs,Y" and "STY abs,X", while the decoding matrix would have easily provided for this. Was this to keep the instruction set arbitrarily simple (as in explicitly not orthogonal)? Or was there a more serious architectural conflict? Or was this just a legacy from the 6800, which had just a single index register, thus lacking a similar option?

(I added a note on this to the article.)

Most of what I know about that comes from Brian Bagnall's books (e.g. Commodore: A company on the edge). It's covered in the first chapter. I don't know of any preserved documents - if they exist they'd belong to Motorola, and I'd expect the leavers would have preferred to ditch any such documents (though part of the reason for the settlement with Motorola was that one of the engineers stupidly taking 6800 documentation with him).

This [1] summarizes it. Here [2] is an interview by Computer History Museum of Chuck Peddle. It matches up with the first chapters in Bagnalls book very closely. From about 50 minutes in he talks about his meetings w/Motorola customers that told him the 6800 was too expensive. From about 58m in they talk about basically setting a size metric for the chip to meet a low enough price point. So the starting point was what they could fit in small enough space.

You might also like the Computer History Museum interview w/Bill Mensch [3]

[1] http://www.cpushack.com/2013/08/03/mos-technology-mcs6501-pr...

[2] https://www.youtube.com/watch?v=enHF9lMseP8

[3] https://www.youtube.com/watch?v=Ne1ApyqSvm0

Thanks! I'll have a closer look at these. – Admittedly, I haven't looked deep into Chuck Peddle's history (besides anything related to the PET), yet.