[Coco] What would a CoCo successor have to have as a minimum?

John Kent jekent at optusnet.com.au
Sun Nov 21 00:19:08 EST 2010



On 21/11/2010 3:27 PM, Mark McDougall wrote:
> On 21/11/2010 2:49 PM, John Kent wrote:
>
>> I might also add that the software emulator has to perform memory 
>> decoding,
>> bounds checking and memory mapping all sequentially. It also has to 
>> emulate
>> the hardware, which is presumably on an an I/O space access, but may 
>> also be
>> concurrent with the CPU execution. The FPGA does this all in 
>> parallel. So
>> even if there are say 100 CPU cycles to one FPGA clock cycle there is 
>> a lot
>> the CPU has to do in those 100 cycles.
>
> You're right of course John, but you also have to take into 
> consideration the efficiency of modern CPU design, with pipelining, 
> hyper-threading etc. Most of the effort emulating a Coco is churning 
> the CPU emulation. Unlike a real Coco - or even FPGA - half the 
> emulated memory is probably cached in the processor too.
>
> Regards,
>
Hi Mark,

Yes, I'm assuming the PC CPU is running at 2.5GHZ and the FPGA 25 MHz 
which gives a 100 fold increase in clock speed. However, the PC CPU has 
to run entirely out of cache to get the full 2.5GHz operation. If it has 
to fetch the program or data from external memory, then this speed is 
reduced. It also assumes branch predictions are 100% accurate and that 
there are no stalls in the pipeline. Emulation requires 8 bit accesses 
which are probably just as expensive as 32 bit accesses. I would imagine 
the compiler or computer is not smart enough to fetch multiple emulation 
bytes in it's registers and use them later.  I'm not really up with 
hyper-threading. I would have thought multicore CPUs can only do multi 
threading if the compilers is smart enough to support that. Multi core 
CPUs provide only course grain parallelism where as FPGAs provide fine 
grain parallelism. This means that multi-core CPUs are most efficient 
running separate tasks. The overheads of processor intercommunication, 
make fine grain parallelism inefficient. Hyperthreading though is 
different to multithreading though isn't it ?  The PC CPU is no doubt 
super-scaler so should be able to execute some instructions concurrently 
which will speed things up. I've a bit to learn.

John K.

-- 
http://www.johnkent.com.au
http://members.optusnet.com.au/jekent




More information about the Coco mailing list