Most instructions of 8008 are still implemented by the latest Intel-AMD CPUs, even if for most of them there is normally no reason to use them, especially in a 64-bit program, where operations with 8-bit registers should be avoided.

Just because they can execute similar instructions it doesnt mean they are the ssame. 8008 came from a common-bus design with an accumulator-centric ISA, which is miles aways from today's x64 architecture.

Besides, ISA is just the CPU frontend and does not reflect the uarch. You can probably make a Ryzen execute ARM or MIPS code by changing a few frontend opcode / fw tables.

Insufficient support for operations with 8-bit registers is a bottleneck even in 64-bit CPUs.

For example, let's suppose that you have a for loop. You could update 8 uint8 values simultaneously by packing them into a uint64 and adding a constant. But when you need to unpack those 8 bytes to actually use them as indexes, the unpacking costs a lot of CPU cycles, so you lose the advantage you gained by avoiding 8 separate additions.

All you can do is access AH and AL (or `SIL`, `DIL`, `BPL`, `SPL`, etc.), but this does not take just 1 CPU cycle. It takes many cycles, and only the lowest bytes can be accessed. There is a lot of performance left on the table because of insufficient support for small registers inside larger registers.

Lacking modularity of the ISA, I can understand why many of those instructions were carried forward.

But all the legacy operating modes too? A modern x86 cpu should only have 2:

# Full-on 64 bit, legacy cruft cleared out as much as possible

# A compatibility mode to run application code written for 32-bit protected mode OSes like Win2k/XP etc

And even that last mode could be optional. Any other legacy support is just waste of transistors imho (however 'few').

Intel made a move in that direction years ago. Sadly that went nowhere.