A RISC Implementation of a 68000

How difficult is it to turn a archtypical CISC into a RISC?? That's the
question that I'll need to answer soon.. My first attempt at that, the k68,
was a disaster.. However, the k68 was also my first crack at designing a
microprocessor.. Without any prior knowledge of computer architecture, it was
a total disaster..

Now that I'm far wiser (with far more processor design experience under my
belt), I'll hopefully, not create a second disaster.. It has always been
something that I wanted to redo, to get right.. Just to prove to myself that
I can do it.. But I've just not had the motivation to do so.. Until now..

I've recently been approached by a small group, who make interesting hobby
boards based on the 68k.. Since the 68k is a 1970s architecture, parts have
been getting scarcer.. So, the best alternative seems to be to implement a
68k in an FPGA.. This will allow their library of software to be used..

Naturally, they came to me.. So, i've been toying around with the idea of a
new 68k, called "ae68" (the naming convention I've used for the ae18 and
aeMB), that will incorporate the best bits of tech that i've learnt, as well
as implement a few new functions.. Besides being fully pipelined, I will want
to experiment with cache memories as well as branch prediction and exception
handling..

However, trying to squeeze a CISC architecture into a RISC is not as easy as
it looks.. for one, the pipeline would need to be extra-ordinarily long - in
order to handle all the crazy addressing modes and multi-cycle instructions..
another alternative would be to build a RISC back end, and have the decoder
issue microcodes..

That's something that I have never done before.. Design a microcoder..
However, before I decide to do it this way, there are still issues to
consider with regards to performance.. Although I'm sure that a microcoded
RISC would probably perform as well as or better than an original 68k, I'm
not so sure if it'll be an optimal design, as opposed to a monolithic RISC
design..

There is another reason for the microcoder argument.. In a classic RISC, there
is only one data memory access each clock cycle.. either through a LOAD or
STORE.. In the 68k, there are typically at least two memory accesses in an
instruction.. being fully pipelined, they may not be to/from the same
location.. So, most of the instructions will need to stall the pipeline
anyway.. So, breaking the instructions into a few micro-RISC instructions
might be useful..

So, it might be useful to build something akin to the coldfire, and use
microcode to simulate a software macro for certain unimplemented
instructions.. hehe.. quite a concept.. time to take a peek at the coldfire
CPU..

So, I'll need to put some thought into it.. and we'll see how things turn
out..