Re: [TUHS] Encoding an ISA: Random Logic vs. Control Stores

[Jon Steinhart <jon@fourwinds.com>]

Douglas McIlroy writes:
> My take on defining random logic
>
> random logic : hardware :: spaghetti code : software

I hate to take issue with Doug's explanation since he's a lot smarter
than me.

In my opinion, spaghetti code is a choice while random logic is not.

In both cases, I have an underlying assumption that the hardware designer
or coder is implementing someone else's design and doesn't have the
ability to say "I could do a cleaner implementation if we could make a
design change."

While one could almost always do a "regular" implementation instead of a
"random" one in hardware the regular one would likely be more expensive
in terms of resources like speed, space, cost, and power than the random
one.

Of course, that's not always true.  In the blast from the past department,
I had to implement something around 1980 where there was no chance of
meeting the timing requirements using random gates.  At the time, and my
memory is fuzzy here, AMD had a very fast 1Kx8 PROM.  Instead of using
random logic I used a couple of these, and wrote a compiler that converted
logic equations into bit patterns for burning the PROMs.  It was actually
that project that got me back into doing software.  Plus, of course,
the fact that our department finally gave up on DEC operating systems
and starting running UNIX.

Random logic design is way different than it used to be.  Back when I was
in college, we had a Digital Logic Design course that focused on Karnaugh
maps and all that sort of logic minimization stuff.  I made a deal with
my professor.  I'd teach the class instead of taking it and annoying
the crap out of him. In addition to the regular class material, I added
TI's "The TTL Book".  The new idea that I brought to the class was that
gates came in packages, and one had to balance logic minimization with
package minimization.  So for example, if you needed an inverter and
none was available but you had an extra NAND gate in a 7400 you could use
it as an inverter instead of adding another package of which 5/6 of the
gates would be unused.  Today, all of this gets handled by CAD packages.
The only time that one might have to get down into the dirt is in something
like a very tight FPGA design where certain elements are in short supply
and can clever misuse of other elements can get what's needed.

Anyway, for yet another try, random logic is what you get when implementing
an "unclean" specification while minimizing cost and other factors.  Sort
of like implementing a parser for FORTRAN :-)

Speaking of FORTRAN and back to Doug's comment, I'm reminded of yet another
story.  Some decades ago I was the author of the C language binding for
GKS, an absolutely stupid standard graphics package.  The original GKS
only had a FORTRAN binding, and many people on the ANSI committee were
working on bindings for languages that their customers actually wanted.
The FORTRAN binding was pretty much what you'd expect.  When I did the C
binding, among other things I defined a "point" data structure to hold
x,y coordinates.  At one of the meetings my friend Randy from Sandia
complained about it.  When pressed, he said that he had a program that
started by labeling a map, and it was tedious for him to have code like

  p.x = 10;
  p.y = 20;
  gtext(p, "label");

when in FORTRAN he could just do

  gtext(10, 20, "label");

Once I understood his issue, I of course had to say "Well, if I was doing
a map to monitor the nuclear test ban..." (because it was always fun to
have people like him and the NSA person who pretended that we didn't know
what they did), I taught him how to put the coordinates and labels into a
static data structure making the rest a two-line program.  He went back to
Sandia and started teaching his peers how to write C in C instead of doing
FORTRAN in C.

I think that this is somewhat analogous to Doug's comment in that there was
a choice on how to write the code, and Sandia's original choice wasn't very
good.  But, it was a choice, not something required by the specification.
Different than, for example, logic that says that "an interrupt is generated
when this or that or another goes high and this enable bit is high and this
mask bit is low and the global interrupt enable is high."  No sensible way to
implement this except as a random hunk of logic because it's a one-off.
Especially if there are other interrupts such as an NMI that has completely
different rules.

Hope that this all helps.

Jon