RE: F21 docs

[Jeff Fox <Jfox@xxxxxxxxx>]

Dear MISC readers:

Mike wrote:
>I have noted some complaints in this list about the F21 docs.
>
>I think the criticism is unjustified. Let me tell you why:
>
>F21 is a very simple but hard to understand processor.
>
>The most complicating factor is the address incrementer.
>
>Here is what I think happened. Chuck found that the simplest
>fastest incrementer included an inversion with each pass. This makes the
>addressing scheme hard to follow.

I agree with Mike but I think it goes well beyond this.  And one of
the biggest problem was that for a year or two Chuck only talked
about the chip from the point of view of a hardware designer.  

He admits that he would jump in one paragraph from a description of
the chip from inside to a description of the chip from outside to a
description of the chip from a programmer's point of view.  I 
understood everything he was saying but it would make my head
spin and confuse me.  He admits that he thought it was interesting
but that it was very unproductive to introduce the chip from a
hardware point of view.  Many people who didn't work mostly with
hardware dismissed the chips many years ago as not comprehensible.

The problem is that no chip is comprehensible when presented from
that kind of point of view.  With coaxing and with his own eventual
realization that this was confusing a lot of people Chuck tried to
focus his presentations either on hardware design problems or on
software and not jump in and out constantly as he does in his work

The complementary bus scheme that Chuck used in hardware and his
explanation to people about patterns and numbers really confused
a lot of people.  He never mentions it any more because it is so
insignifigant.  The bottom line is that it only effects you in
two places and most people don't deal with those things.

It only effects a line or two in any cross compiler tools that
run on an enviroment with a differnt bus. This is also true for
tools that go between Intel and Motoral processors or others.
It also requires that the driver for the I/O port xor with AAAAA
to convert from a physical pattern to a logical representation.

There is no univeral hardware standard that a logical zero
should be zero volts and a logical one should be five volts as
hardware people know.  Computers generally fall into positive
or negative logic on the bus.  Chuck introduced the bus with
half the bits positive and half the bits negative.  

This sort of thing is what was dealing with as a chip designer and
discussing it along with discussing programming gave people it was
some sort of devilish complexity.  It is if you cross the boundry
from inside to outside or from programmer to chip designer too many
times while working on the code.  Since it really doesn't effect
anyone except chip designers (like Mike) we don't even talk about
it anymore except to document it as one of the things cross-compiler
writers must deal with.  We don't need to confuse most people with it.

1 + 1  is still 2 logically.  If you plug in a bus analyzer to a MISC
chip that was not designed to show that logical representation on a bus
where even and odd bits have oposite polarity you have to make a conversion
or program a macro to do it.  But again I try not to confuse people who
only want to understand the chip from a programmer's point of view by
trying to get them to understand chip design.

There is documentation on chip design for those who are interested.  It
does complement the programming stuff but it is not important that anyone
understand that level of the internals of the chip for normal programming
of the chips.

>The instruction decoder is a little unusual but not terribly so.
>
>Nowadays these hardware simplifications are easily dealt with in the
compiler.
>
>None the less it requires considerable thinking to 'get' it.
>
>I have found the doc adequate to design this chip on a board including 
>software.

It is a bit mind numbing to deal with the issue of logical representation
and hardware represent being different on two systems and doing cross 
development.  It is as simple as one view or the other, but it also means
that if you did an even number of transitions instead of odd, or whatever,
you have the wrong perspective. 

In the long run as Mike says it just amounts to a couple lines of code
being in the right place then you can more or less forget about this issue.

>================================
>
>What might make doing a chip on FPGA useful is having separate memory
managers
>for processor, video, audio, and serial comms.  Pins are cheaper on FPGAs.

Not to mention the very fast turn around time for getting hardware
programmed
to your design.  Fast and cheap development, not like custom VLSI.  The FPGA
choices are getting better.  They are bigger and faster and there is more
variety to choose from too.

Jeff Fox