TTL computing

From: Richard Erlacher <edick_at_idcomm.com>
Date: Fri Apr 12 00:46:42 2002

see below, plz.

Dick

----- Original Message -----
From: "Tony Duell" <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Thursday, April 11, 2002 6:43 PM
Subject: Re: TTL computing


> > 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.
>
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.
>
> [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
is
> > 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?
>
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.
>
> > 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.
Received on Fri Apr 12 2002 - 00:46:42 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:34:30 BST