Re: 65020 CPU? Look this...

["Peter de Vroomen" <peterv[at][spamblock]jaytown[dot]com>]

> :     Attempt to extend 32 Bits from an original 6502 CPU.  Please comment
> : what you think this website below.
> :
> : http://www.ucc.asn.au/~john/index.html
>
> Did you miss this part Bryan???
>
> " It also hasn't been implemented (and probably never will be). "

Well, in the light of today's Xilinx FPGA's, somebody could pick it up and
build the processor.

But at first sight, it seems that the design is not too smart. Opcodes are
16 bits, addresses and data is 32 bits. The data buss is 32 bits. This means
that an op-code fetch will fetch 32 bits, of which 16 comprise the op-code
and the other 16 either the first part of data or plain rubbish. If it is
data or an address, there needs to be another fetch for the next 16 bits of
the address of data. But the fetch is again 32 bits, so again you have 16
bits of rubbish.

It would be better if op-codes were 8 bits and addresses were 24 bits. One
32-bit fetch could get either 4 op-codes without data, 2 op-codes with 8 bit
data or 1 op-code with 24 bit data.

Or maybe go the 68000 way, make the processor 16/32 bit, i.e. address is 32
bits, but fetches from memory are in pieces of 16-bits. But then the design
would suffer from the same problem as the 68000. If you work on large chunks
of data and have to reload some pointer with a 32 bit address every so
often, you'll suffer speed because reloading a 32 bit address pointer from
the stack or memory will take 2 cycles each. There are way's around this,
but it means that programming for the processor is not straight-forward
anymore, and you enter the realm of optimizing compilers :).

I still think 8 bit processors have their own right of existence. They are
much easier to program the right way, because their instruction set is
simple and to the point. But somebody should make an 8-bit processor with
the speed of a few Ghz :).

PeterV