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).