xx21 series hardware features

[gut@xxxxxxxxxxxxxxxxx (alex lasky)]

part 2 (continued from part 1)

So, should the simplistic video and audio processors be upgraded to
something useful (and making the chip larger, more expensive and power hungry)
or left off entirely, and thus requiring more external circuitry? The latter
approach has problems aside from the added circuit complexity, in that
the 2.5 byte data bus and CPU registers are not really compatible with
readily available support chips or standard integer or floating point formats.
The P32 addresses this issue, but couples a 32 bit bus with "deluxe" serial
comms features, which add to the cost and may not be necessary for users.
Why couldn't the other chips have been 32 bit?

Jeff Fox seemed to say in his presentation that the xx21 series was intended
for parallel processing, and also mentioned that the chips could be coupled
with cheap DSP chips for floating point operations. The compatibility
problems with a 2.5 byte bus have been mentioned above. Furthermore (and
I'm no expert in this area, so correct me if I'm wrong) but isn't highly
parallel processing mainly used in situations involving highly intensive
floating point operations? If so, and parallel processing is seen as a major
use for the xx21 series, this would suggest that an on-chip FPU would be a
decided advantage. Once again, this adds to the expense, power & cost, but
seems necessary to make the chip really effective for this application.

Jeff's web page notes seem unclear on the role of the bus interface
processor. The 3 bus system seems to imply one slow bus for I/O, one DRAM bus
for standard DRAM memory, and one fast bus for a cache. Does the bus processor
peform cache management? If not, are programs supposed to define commonly
used data and code at compile time, and place it in the cache? Also why
is the cache limited to 8Kwords, and the slow bus limited to 8 bits per
word? Isn't the address and data sent over the same pins whatever the bus
being used?

I have not encountered Forth in any detail before reading Jeff's web page
notes, but it seems a right bastard of a language. No type checking,
sloppy, near-indecipherable syntax, three letter effective limit for variable
names, susceptibility to side effects etc. It seems to encourage a profusion
of undocumented functions. Forth code must be a nightmare to maintain.
However it seems quite suitable for MISC, since the stack based architecture
allows an arbitrary number of on-chip registers without any added complexity
to the instruction set. Still, I would hate to use Forth as a high level
language. The promised 3rd party C compiler seems to come and go from the chip
summaries for the F21 on Jeff's homepage; pity, as it would be a great
advantage to getting the chip accepted.

If the has been a little pessimistic and long-winded, sorry but, that's just
the kind of person I am. But it would be a shame if a promising idea was
castrated by too much fence-straddling in the implementation details. I am
reminded of Mark E. Smith singing: "Made from the finest of British intentions/
To the wrong detail/Guaranteed obsolete unit surrounded by hail".



Alex Lasky            * "Clubland & dubland will bop till they drop, then
gut@elec.apana.org.au * discuss postmodernism & the punk ethos over pools of
Sydney, Australia     * 70%-proof vomit on the toilet floor" - Ian Mcdonald