Foreword

For a homebuilt CPU hobby project, defining the instruction set
is one of the toughest tasks.

Well, not actually defining it, but knowing that you
will have to live with the consequences of your decisions for
the next several years.

A lot can happen within a few years.
You could have missed a point, and then be forced to add some
things not covered by your design...
a nice example is the evolution of the 80386 family into the
world of 64 Bit CPUs.

You could try to stay compatible with the instruction set
of a CPU which already exists, but as a hobbyist you might find
that plain boring...
The question "is it possible finding an approach of solving the
problem like no one considered doing it before" troubles you.

If you really want to invent your own instruction set,
the question is, if you will have the time, energy and patience
to write your own set of tools, your own operating system, and so on.

The effort for this always seems to be underestimated, and there
is a chance that your hardware might turn into just another strange
trophy in your cupboard, doing nothing but to filter the dust from
out of the air several months after the test runs were completed.

So when starting such a project, try to get in contact with a
'software guru' first, at least for getting some hints on what your
CPU should look like for being able to run 'serious' software
(whatever that means...).

If you ask three people what the best instruction set may look
like, maybe you're getting five different answers.

Assembly programmers
might prefer different architectures, just remember the "8085/Z80 versus
6502" holy wars in the past... besides that, the answer also depends on
what the CPU will be used for:
8031 might be nice for building a small PLC, but not for other applications.
6502 is nice and efficient for small assembler projects, but when your
projects grow bigger, you might feel a few limitations...
68k is quite the thing for big projects, like writing your own operating
systems, but you can't memorize every machine code there is,
what could make debbuging the code without approbiate tools difficult.

"mere" C programmers
don't exactly know, what a CPU is. The don't want/need to know.
But sometimes they are happy if the available CPU memory isn't melting away
too fast when compiling C code into machine code...
well, at least in the "embedded" sector sometimes.

Compiler gurus
might prefer writing compilers and software tools for a rather simple,
orthogonal instruction set, maybe with register windows like in the
AM29k or SPARC architecture.

CPU hardware designers
might want to keep the concept of the CPU as simple as possible, just for
reducing the trouble to come when implementing the design.
And the simplest concepts for building a CPU can be found in the Forth
environment.

You see the problem: the hardware guy would enjoy to "nail together"
a very simple instruction set, based on the hardware/technology available.
The result might fry the brains of the software guys.

If the assembly programmer insists in having a 68k instruction set,
the hardware guy probably would have to retire into a cave (like a Zen monk),
spending many months with scribbling specifications on piles of papers
before being able of starting to actually design something.

If the mere C programmer eventually is happy with the efficiency of the CPU,
maybe the assembly language programmers will refuse debbuging machine
code on this architecture for some reasons.

And the problem is:
As a hobbyist building a CPU, there is a chance that you will have to play
in all the fields mentioned above, but maybe you're not aware of this
when starting your project...

Back in 2006, I had a a nice and long discussion with
a software guru about all the points mentioned above.

This article explains what grew out of it.

[HOME] [UP]/ [BACK] [1] [2] [3] [4] [5] [6] [7] [8] [NEXT]