[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