12 Apr
2002
12 Apr
'02
12:46 a.m.
see below, plz.
Dick
----- Original Message -----
From: "Tony Duell" <ard(a)p850ug1.demon.co.uk>
To: <classiccmp(a)classiccmp.org>
Sent: Thursday, April 11, 2002 6:43 PM
Subject: Re: TTL computing
I've argued that in the context of exhaustive system testing. Any computer,
and, in fact, the worldwide computer resources, viewed as a system is still
bounded, though very large, and could, in theory, be viewed as a finite state
machine. I challenge you, however, to come up with a way to validate such a
system, whatever the size, using a computer, such that every possible
combination of bits in mass storage, in semiconductor memory, and in inputs
and outputs, is exercised and the system behavior rigorously characterized.
is
In the context of "microcoded" system it is a small fast computer used
to
implement, physically, the behavior and resources of a larger more complex,
and somewhat slower, system.
> A computer is likely to have several state
machines. Defining the
computer as
being a state
machine is like saying a '747 is a light bulb.
But a state machine takes in external inputs, combines them with it's
internal 'state', and produces outputs. So does a computer....
I think that _any_ computer with finite memory (and that's all real
computers) cna be shown to be equivalent to a state machine. Things like
turing machines and PDAs [1] are only more powerful than state machines
becuase they have infinite memory.
[1] Push-Down Automata. A state machine with an infinite stack linked up
to it. Not any other expansion of that acronym.
How do you create an infinite stack? I'd submit that if it has an infinite
anything, it isn't a Finite State Machine.
> > > Here we have a fine example of what happens when computer-science
meets
> > > electro-engineering...
> > > Mathematically there is no difference between a state-machine and
> > > microcode. Both are just different methods to describe a finite state
> machine.
> >
> > And electronically there's little, if any, difference.
> >
> Actually, there's a mathematical difference between them, since the
microcode
> is just to ROM or fuse array content, while the
state machine is the
> combination of that with the combo-logic and registers that comprise the
state
machine.
OK, the term 'microcode' was incorrect here. Let's rephrase it as
'microcoded system'. There is little, if any, electronic difference
between a state machine and a microcoded control system.
> If it's microcoded, there's a complete execution unit the purpose of which
to execute
content of the microcode ROMs. If it's a hand-wired set of
I don't know what you're getting at here? What's an 'execution
unit',
other than some kind of microcode address sequencer and something to
decode the microcode words. How does it differ from the state latch and
state decoding logic of a state machine?
> transitors and diodes, or whatever, functioning as a state machine, it's
not
> microcoded, since there's no distinct
microcode. Now if you want to
redefine
So by this definition if I take a microcoded processor and store the
microcode in a mask programmed ROM, then it ceases to be microcoded? The
68000 is not microcoded because the ROM contents can't be changed?
Alternatively, say I take a classic microcoded processor (say the
11/45). The microcode is stored in fusible link PROMs in the original. I
now put all the processor logic _including the microcode_ into a very
large FPGA, and I let the FPGA tools reduce and optimise the logic
(letting said tools loose on a complex circuit is a very silly idea,
but...). Are you going to tell me the result, which is electronically
equivalent to the original, is no longer microcoded?
The applications I've seen use a multi-component chipset that allows
considerable flexibility in configuration of the "target" hardware/software
system and executes primitive microinstructions to implement the target
instruction set and implement the target resources. It's essentially a
simulator, consisting of both hardware and firmware, that functions as a
computer that, in effect doesn't really exist. That's what makes 'em so
flexible. That's also why they're ultimately implemented in hardware with
considerable reduction in cost and increase in performance.