The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Jon Steinhart <>
To: TUHS main list <>
Subject: Re: [TUHS] Encoding an ISA: Random Logic vs. Control Stores
Date: Wed, 01 Dec 2021 12:27:51 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

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

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.


  reply	other threads:[~2021-12-01 20:30 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-01 14:55 Douglas McIlroy
2021-12-01 20:27 ` Jon Steinhart [this message]
2021-12-01 21:14 ` Lawrence Stewart
2021-12-01 22:09   ` Jon Steinhart
  -- strict thread matches above, loose matches on Subject: below --
2021-12-01 13:59 Paul Ruizendaal
2021-11-30  8:07 pbirkel
2021-11-30 15:19 ` Ron Natalie
2021-11-30 15:30   ` arnold
2021-11-30 15:39     ` Ralph Corderoy
2021-11-30 18:50     ` Jon Steinhart
2021-11-30 21:45       ` Humm
2021-11-30 23:07         ` Jon Steinhart
2021-11-30 23:18           ` Henry Bent
2021-12-01  5:00             ` Jon Steinhart
2021-12-01  6:27               ` pbirkel
2021-12-01 16:42                 ` ron minnich
2021-12-01 17:08                   ` Ron Natalie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).