Re: 65020 CPU? Look this...

["Ranando King" <rk@magictouchcorp.com>]

Why not use the 16/32 method? It's semantically no different than the 8/16
method employed by the 6502 as is. Keep the instructions limited to 8 bit.
Allow 16bit zero-page fetches. Allow 8 bit immediate data. Make the A, X, &
Y registers 16bit with 8bit accessable portions. Include a SWP (byte swap)
instruction. This would keep all things almost as simple as the 6502 already
is. Addresses would still take 2 fetches except in the zero-page case. Use
the unused status bit to force the processor into an 8/16 addressing mode so
it can act like a 6502 with added instructions. Tie that bit to the MMU so
that it shifts data and addresses as appropriate for the processor mode.

Could you imagine something like that at 512Mhz?

R.

"Peter de Vroomen" <peterv[at][spamblock]jaytown[dot]com> wrote in message
news:421ef2ad$0$28977$e4fe514c@news.xs4all.nl...
> > :     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
>
>