see below, plz.
Dick
----- Original Message -----
From: "Tony Duell" <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Friday, April 12, 2002 12:43 PM
Subject: Re: TTL computing
> > > Of course I do. It's just a somewhat larger ROM. You do realise that
> > > _any_ combinatorial logic circuit can be implemented using a
sufficiently
> > > large ROM, right. So all I need to do is pick a large enough ROM to
> > > contain the original microcode + the logic for the counter, etc. That's
> > > now all in one ROM. I connect it to the state latch. It's now a state
> > > machine. It's also, IMHO, the same microcoded system as the original
design.
> > >
> > You're starting to mix questions of logic with questions of
implementation. A
>
> True, in one sense.
>
> The point is, I am claiming (and still claim) that the system of 'control
> store + microcode latch + mux + counter' can be considered to be just
> another state machine, and I provided a way to turning it into the
> classic implementation of a state machine.
>
> Agreed it doenn't really matter how it's implemented...
>
> > The term "microcoded" in the context in which I've seen it used for the
past
> > three decades has always meant that there's a small primitive computer
running
> > a small primitive instruction set, and it's used to implement, physically,
the
> > more complex structures of a larger system with a larger, more complex,
> > instruction set and resources. This was a distinction between "microcode"
and
>
> But it's possible to consider the inputs to a state machine as being the
> 'instruction set' of that state machine (in fact, in Computer Theory,
> that's _exactly_ how it's normally considered I believe).
>
> I think what I've been trying to say for the last <n> messages is that
> microcoded systems are necessarily finite state machines (by any
> reasonable definition) and that also the boundary between 'microcoded
> machines' and 'any old finite state machine' is not that clear.
>
At the risk of repeating myself, I'll say, again, it's a semantic quagmire ...
It's true that they are, in a sense state machines, though I'd guess that
they're actually a combination of several or even many state machines.
You've not only mixed issues of logic with issues of implementation but also
mixed what "could" be with what is or has been. While there's a lot of
discussion possible, as you've shown, regarding the definition of "microcode"
it's only fair to warn you that what you've pointed out could be, is in the
subjunctive, and that the definition that has, in fact, been adopted by
convention differs form what could have been. As I said in a previous post,
nomenclature has been driven largely by design practice rather than by theory,
and that folks, therefore, refer to state machines as little thingies that
live in a PAL or consist of a PROM, registers, and some combo logic. We talk
about Moore machines and Mealy machines, and think in terms of 24-pin PALs,
not in terms of 12"x15" boards, as one might envision when discussing a
microcoded CPU.
>
> > > Well, I thought the combinatorial part of the state machine was also
> > > implemented using a ROM. It's certainly possible to do this (and at one
> > > time it was very common).
> > >
> > Using a PROM to implement a combinatorial path has always been the most
costly
> > way to do it. I don't think it was as common as you suggest. Such an
>
> It probably depends on the time period and the manufacturer. Certainly
> I've worked on devices containing state machines built in that way. Or
> perhaps you don't want to call them state machines ;-)
>
> > application is likely to lead to very sparse ROM utilization. The ROM has
a
> > fixed Or and fixed AND array, hence has to have many more registers in it
than
>
> One conculsion you can draw from this is that there are therefore
> combinatorial functions you can implement in the PROM that you can't
> implement in the PAL. One trivial example : It's not hard to program a
> 4*4 (giving 8 bit product) multiplication table into a 256 byte PROM. It
> is (I believe) impossible to do the same using a 10L8 PAL.
>
That's a lookup table, however, and not a multiplier, and terribly
inefficient. By way of contrast, it is straightforward enough to build a
32x32 multiplier into a sincle CPLD/FPGA of reasonable proportions. I doubt
that it's easy to build a ROM lookup table capable of accomplishing the same
thing into a ROM. As for the small multiplier, I think the TTL part that does
that is a 74S274 or thereabouts. It's a wallace tree multiplier, and the
basic unit was, I think, 4x4. There's also a '284 and '285. None of these
are as small as the 256x8 PROM, but they're expandable, which the PROM is not.
I say the PROM is inefficient, since it contains two representations of each
product, since the multiplier and multiplicand are interchangeable to produce
the same result.
Received on Fri Apr 12 2002 - 19:24:04 BST