[makomk]

It's implemented using a few standard 74xxx TTL logic chips and a 256x16 microcode ROM. It's important not to ignore the microcode ROM because that's where all the smarts that turn it from an ALU unit and a bunch of registers and miscellaneous logic into a CPU that can actually execute instructions. All of the instruction decoding and the sequencing of all the operations that make up a CPU cycle is done directly by the microcode ROM.

[PythonicAlpha]

That is right. That differs of course from early microprocessor designs, but still it is valid, since today's processors also rely heavily on microcode that is simply stored in ROM or similar areas.

I think, you can not give this design a negative, because it is much simpler than early microprocessors.

I forgot about the ROM, and apologize for it.

[creshal]

Two 16 KiB ROMs, actually.

(Meanwhile, current Intel processors have 2 MiB microcode files.)

[k8tte]

to be fair, that's 2 MiB code that is the base of the other os you never heard of, the IME, AMT and their backdoor capabilities [1]

1: https://fsf.org/blogs/community/active-management-technology

[creshal]

No, that's just the CPU µcode. IME/AMT are part of the BIOS/EFI images, which is a whopping 16 MiB for my current motherboard.

[makomk]

The current CPU microcode download appears to be 0.81 MB compressed for every single Intel CPU since the Pentium 4.

[jokr004]

You know, lights out management is a wonderful thing and there's never been any kind of evidence that these features do anything but offer functionality that Intel's customers asked for.

[mnw21cam]

The ROM is basically acting as an FPGA. After all, an FPGA is just a load of units of small ROM areas, with the inputs and outputs linked to each other. If all you need to implement your circuit is a single unit, then a small ROM chip is quite sufficient instead.

[adwn]

> The ROM is basically acting as an FPGA.

No, it doesn't; neither from a practical, nor from a theoretical point of view. Theoretically, ROMs are equivalent to the class of pure, total, mathematical functions (i.e., each input value maps to exactly one output value), while FPGAs are equivalent to the class of deterministic finite automata, because they contain internal state.

> After all, an FPGA is just a load of units of small ROM areas, with the inputs and outputs linked to each other.

You're forgetting the memory elements – they're crucial to the functionality of FPGAs.

[duskwuff]

> You're forgetting the memory elements – they're crucial to the functionality of FPGAs.

I'd argue that an even more critical feature of FPGAs is configurable routing. ROMs don't have that either. :)

[adwn]

True. But then again, that's like arguing over which organ is more important – the heart or the lung – when you can't survive without either of them ;-)

[duskwuff]

You can build memory elements - inefficiently, but it's possible - out of recurrent logic. You can't build routing.

Actually, now I wonder whether it'd be possible to build memory out of ROM by looping outputs back to inputs...

[adwn]

> You can't build routing.

You actually don't need configurable (programmable) routing: We can model every synchronous circuit as a Mealy machine [1], therefore we need two functions and a register. Every function can be constructed from a hierarchy of programmable, fixed-size LUTs which are statically connected (for example, you can build a 5-input LUT from three 4-input LUTs). Now you don't need to build routing, it's implicit in the next-state and output functions.

[1] like this: http://electrosofts.com/verilog/mealy.gif