Nexxen wrote on 2021-11-23, 10:51:
I was thinking, isn't the increase in mhz going to yield a linear increase in performance?
Not quite. On old systems like 086/088, 186, 286, 386, (and 486 before clock multipliers), the bus clock speed and CPU speed are the same. So, for them increasing the CPU speed does yield a pretty much linear increase in performance, as long as you ignore any performance limited by ISA, which can only really clock up to 8-10MHz safely unless you're picking your ISA cards carefully. In simpler systems (some 8088, some 8086, some 286) where the CPU, Bus, and ISA are all run at the same frequency, a frequency increase is a completely linear performance improvement since it increases the frequency of everything in the system.
You won't reliably be able to exceed whatever Bus speed your board has for its maximum setting. So, after a certain point, you want to increase CPU performance without increasing bus speed.
One way to do this is to make your instructions take fewer cycles to complete. This technique is referred to as "Increasing IPC", increasing Instructions Per Cycle. Many x86 instructions take several clock-cycles to complete. In real CPUs, this was done with the NEC V20/V30, and is why those are known to be faster than their 8088/8086 counterparts at the same clock speed. IPC is improved with pretty much every new CPU generation (except the Pentium 4), and is why a 8MHz 286 system can outperform a 10MHz 8086 system.
Another option is to introduce/increase cache, and reduce dependence on the slow main memory. Even when the Bus and CPU ran at the same speed, DRAM is slow, so going out to memory to fetch a value is going to slow execution down. If you have a cache onboard or on-chip (and the value you want is inside the cache) you can read from the much faster SRAM cache memory and not have the CPU waiting for your slow main memory to respond.
Another option is to increase CPU clock speed without increasing the Bus speed. In real CPUs this happened in the 486 era when Intel started clock-doubling. This especially works well if you have a cache on-chip which can run at your doubled/tripled/etc clock speed, and prevent slow accesses to your now half/one-third/etc-speed Bus. Full-speed on-chip cache in combination with clock-multiplication is what makes the 65F02 fast. It has enough RAM inside it to almost never have to touch main memory, and all the ram inside it runs at 100MHz, vs the previously incredibly slow 1MHz system ram.
Nexxen wrote on 2021-11-23, 10:51:
186,286,386? Some FPGA could come with L1 + L2 cache, are the new performance results predictable?
The new results could be simulated and compared to a simulated version of the old results, but I'm not remotely smart enough to be able to do that. A cycle-accurate emulator would need to be implemented to be able to check, which is pretty much the same amount of work as implementing the device on an FPGA to begin with.
Nexxen wrote on 2021-11-23, 10:51:
Isn't a BIOS necessary for these new cpus? I can't get around the idea of some support updates.
Or being internally clocked x2/3/4... doesn't need?
Probably wouldn't need a BIOS update as long as it behaves mostly like the original chip. NEC V20/V30 don't need BIOS updates. 486DX2 in a system with a bios that only knows about 486DX doesn't need a bios update to clock-double.