The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* Re: [TUHS] Encoding an ISA: Random Logic vs. Control Stores
@ 2021-12-01 14:55 Douglas McIlroy
  2021-12-01 20:27 ` Jon Steinhart
  2021-12-01 21:14 ` Lawrence Stewart
  0 siblings, 2 replies; 17+ messages in thread
From: Douglas McIlroy @ 2021-12-01 14:55 UTC (permalink / raw)
  To: TUHS main list

My take on defining random logic

random logic : hardware :: spaghetti code : software

Doug

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Encoding an ISA: Random Logic vs. Control Stores
  2021-12-01 14:55 [TUHS] Encoding an ISA: Random Logic vs. Control Stores Douglas McIlroy
@ 2021-12-01 20:27 ` Jon Steinhart
  2021-12-01 21:14 ` Lawrence Stewart
  1 sibling, 0 replies; 17+ messages in thread
From: Jon Steinhart @ 2021-12-01 20:27 UTC (permalink / raw)
  To: TUHS main list

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Encoding an ISA: Random Logic vs. Control Stores
  2021-12-01 14:55 [TUHS] Encoding an ISA: Random Logic vs. Control Stores Douglas McIlroy
  2021-12-01 20:27 ` Jon Steinhart
@ 2021-12-01 21:14 ` Lawrence Stewart
  2021-12-01 22:09   ` Jon Steinhart
  1 sibling, 1 reply; 17+ messages in thread
From: Lawrence Stewart @ 2021-12-01 21:14 UTC (permalink / raw)
  To: Douglas McIlroy; +Cc: TUHS main list


> On 2021, Dec 1, at 9:55 AM, Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote:
> 
> My take on defining random logic
> 
> random logic : hardware :: spaghetti code : software
> 
> Doug

I don’t think this is right.  The irregular parts of die photographs didn’t get that way because the hardware engineers were writing bad (spaghetti) code.  They got that way due to several levels of optimizing tools working over quite sensible RTL or System C code or whatever. You might as well ding the output of -O3 for being incomprehensible.

You might get the same logic by writing a clean state machine and letting the tools minimize the control rom into gates (good) or by writing the gates yourself (bad).  You can’t tell without looking at the sources.

Software coding:  You write the conrol flow and the compiler generates the datapath
Hardware coding:  You write the datapath and the compiler does the control logic.


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Encoding an ISA: Random Logic vs. Control Stores
  2021-12-01 21:14 ` Lawrence Stewart
@ 2021-12-01 22:09   ` Jon Steinhart
  0 siblings, 0 replies; 17+ messages in thread
From: Jon Steinhart @ 2021-12-01 22:09 UTC (permalink / raw)
  To: TUHS main list

Lawrence Stewart writes:
> I don’t think this is right.  The irregular parts of die photographs didn’t
> get that way because the hardware engineers were writing bad (spaghetti)
> code.  They got that way due to several levels of optimizing tools working
> over quite sensible RTL or System C code or whatever. You might as well ding
> the output of -O3 for being incomprehensible.

Yes and no.  The irregular parts of die photographs are from the instantiation
of random logic.  The point that I obviously failed to make earlier is that it
looks way different than the instantiation of more regular logic.

But there's also a historical element here and I was living in the past.  Sure,
what you say is true of modern designs which I haven't been involved with; my
current history is limited to FPGA designs.  But, going back a while, look up
Rubylith (no relation to Ruby) which is how ICs were laid out pre-CAD days.
The regular and random parts look remarkably similar to the way that they do
today.  No compilers needed to make things look that way.

Just for some more BTL history, I started doing work on CAD software around
1985.  I'm thinking that it was maybe 1988 or 1989 when a bunch of area 10
folks (Carl, Greg, Hal, ...) left BTL to found what I think was called Silicon
Design Labs which eventually merged with Silicon Compilers (or the other way
around).  I think that they were later bought out by one of the current big
CAD system survivors.

Jon

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Encoding an ISA: Random Logic vs. Control Stores
  2021-12-01 16:42                 ` ron minnich
@ 2021-12-01 17:08                   ` Ron Natalie
  0 siblings, 0 replies; 17+ messages in thread
From: Ron Natalie @ 2021-12-01 17:08 UTC (permalink / raw)
  To: ron minnich, TUHS main list

There seems to be confusion here about microcoding vs. discrete 
logic/LSI.    All but the initial 11/20 (and its variants) are 
microcoded.   That is there is a programmed sequence of operations in 
the execution of the individual instructions.   The less popular 11/60 
even featrued a writable control store.

All of the early PDP-11s were built out of discrete logic.   Relatively 
simplistic combinations of various logic chips, gates, flip flops, etc.. 
   A lot of these were encapsulated into the DEC "Flip Chips" small 
circuit boards to do common sets of operations.   While this is by 
modern standards, crude, it doesn't preclude microcoding and other 
advanced tasks.    I worked on a supercomputer built that way (Denelcor 
HEP built largely out of Motorola 10800-series ECL chips).

As I previously stated, the 11/44 was the last of the discrete logic 
PDP's in 1979.    The later systems were all large scale integrated 
circuit based.  First starting with the LSI-11/03 on the Q bus, quickly 
followed by the 11/23 and the Unibus 11/24.


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Encoding an ISA: Random Logic vs. Control Stores
  2021-12-01  6:27               ` pbirkel
@ 2021-12-01 16:42                 ` ron minnich
  2021-12-01 17:08                   ` Ron Natalie
  0 siblings, 1 reply; 17+ messages in thread
From: ron minnich @ 2021-12-01 16:42 UTC (permalink / raw)
  To: TUHS main list

I used to design hardware in those days, and had a soldering iron and
a PDP 11/45 board on the same bench, unsuccessfully, so here goes.

It's interesting to consider the PDP-8 and -11, and the progression of
hardware. The -11 was way different than the -8: I still have some -8
boards, on which you can see the transistors and such needed to
implement state and gates. The -11s had TTL. At the time, a package
with four logic elements was a big deal.

so the -8 had "a gate per 2x3 inch card" or so. The -11 had about 8x11
boards with, by my count on the 11/20, around 100+ gates (I've got
some cards still ...). Again, multiple logic elements in a 14-dip were
an amazing step forward.

If you look at those boards, you see lots of 14-DIP with quad NAND,
AND, NOR, 2 flops per package, and that's about it. In this world,
where a gate costs about $1, you think about everything. Look
carefully, and you can see the traces were laid out by hand; some of
us remember the rooms full of light panels and the red tape you used
to lay out the board.

Not that I designed CPUs, but having used this gear, lived in the
culture, I'd argue that bit layouts of instructions did in fact
matter. The TTL MUX parts were yet to appear. The board layout,
package design, cost of a wire, instruction format: all to some extent
intertwined. You could look at the hardware design and draw a
connection right back to instruction coding. It was all of a piece.
The luxury of a ROM or MUX that picked instructions apart for you? Not
at that time.

As for random logic ... the things we did back then. The discipline of
design for test, which we take for granted today as JTAG, was some
time in the future. And some of you no doubt remember the unibus ...
and the practice of "margining the bus." I.e., slow it the hell down
so maybe it would not get data errors. Or maybe, even, "let's put a
cap here to add some delay constant" -- people really did that stuff.
It's amazing anything worked. But when a gate costs a buck, you do
what you do.

On Tue, Nov 30, 2021 at 10:30 PM <pbirkel@gmail.com> wrote:
>
> Said Jon:
>
> " In a microcoded machine, the same hardware is used for every
> microinstruction.  In random logic, custom designed circuitry is used for
> each special case."
>
> Best way to get a handle on the distinction is to read up on the originator
> of the concept, Maurice Wilkes:
>
> https://en.wikipedia.org/wiki/Maurice_Wilkes
> https://amturing.acm.org/info/wilkes_1001395.cfm
>
> The original paper:
>
> http://www.cs.princeton.edu/courses/archive/fall09/cos375/BestWay.pdf
>
> "The Best Way to Design an Automatic Calculating Machine" (1951)
>
> -----
>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [TUHS] Encoding an ISA: Random Logic vs. Control Stores
@ 2021-12-01 13:59 Paul Ruizendaal
  0 siblings, 0 replies; 17+ messages in thread
From: Paul Ruizendaal @ 2021-12-01 13:59 UTC (permalink / raw)
  To: TUHS main list

For DEC memo’s on designing the PDP-11 see bitsavers:

http://www.bitsavers.org/pdf/dec/pdp11/memos/

(thank you Bitsavers! I love that archive)

Ad van de Goor (author of a few of the memo’s) was my MSc thesis professor. I recall him saying in the early 80’s that in his view the PDP-11 should have been an 18-bit machine; he reasoned that even in the late 60’s it was obvious that 16-bits of address space was not enough for the lifespan of the design.

---

For those who want to experiment with FPGA’s and ancient ISA’s, here is my plain Verilog code for the TI 9995 chip, which has an instruction set that is highly reminiscent of the PDP-11:
https://gitlab.com/pnru/cortex/-/tree/master

The actual CPU code (TMS99095.v) is less than 1000 lines of code.

Paul


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Encoding an ISA: Random Logic vs. Control Stores
  2021-12-01  5:00             ` Jon Steinhart
@ 2021-12-01  6:27               ` pbirkel
  2021-12-01 16:42                 ` ron minnich
  0 siblings, 1 reply; 17+ messages in thread
From: pbirkel @ 2021-12-01  6:27 UTC (permalink / raw)
  To: 'TUHS main list'

Said Jon:

" In a microcoded machine, the same hardware is used for every
microinstruction.  In random logic, custom designed circuitry is used for
each special case."

Best way to get a handle on the distinction is to read up on the originator
of the concept, Maurice Wilkes:

https://en.wikipedia.org/wiki/Maurice_Wilkes
https://amturing.acm.org/info/wilkes_1001395.cfm

The original paper:

http://www.cs.princeton.edu/courses/archive/fall09/cos375/BestWay.pdf

"The Best Way to Design an Automatic Calculating Machine" (1951)

-----


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Encoding an ISA: Random Logic vs. Control Stores
  2021-11-30 23:18           ` Henry Bent
@ 2021-12-01  5:00             ` Jon Steinhart
  2021-12-01  6:27               ` pbirkel
  0 siblings, 1 reply; 17+ messages in thread
From: Jon Steinhart @ 2021-12-01  5:00 UTC (permalink / raw)
  To: TUHS main list

Henry Bent writes:
> On Tue, 30 Nov 2021 at 18:10, Jon Steinhart <jon@fourwinds.com> wrote:
>
> > Humm writes:
> > > Quoth Jon Steinhart:
> > > >arnold@skeeve.com writes:
> > > >> Can someone please explain why it's called "random" logic? Discrete
> > > >> logic I understand (more or less), but I've not heard the term
> > "random"
> > > >> used in this context before now.
> > > >
> > > >Well, as a recovered random logic designer, I think that the name comes
> > > >from there being no particular structure to the logic.  Many parts of
> > > >logic design are very regular, think memory.  But that regularity doesn't
> > > >exist when, for example, decoding irregular instructions.
> > >
> > > Now that's a "random" definition.
> > >
> > > --
> > > Humm
> >
> > OK, I'll try again.  For anybody familiar with Portland, Oregon, it's the
> > difference between driving in Northwest where there's a rectangular grid
> > numbered in one direction and alphabetical in the other, and approaching
> > the Ross Island Bridge from the west side which appears to be designed by
> > someone following a goat while tripping their brains out.  One can address
> > Northwest Portland quite easily unlike getting onto the Ross Island Bridge.
> >
>
> So - and as I say this as someone who has no direct experience with this
> level of logic - everything is directly addressable but the difference is
> in how you get there?

Sorry my analogy didn't work.  Look at a photomicrograph of a chip; at least
to me it's pretty obvious where the random logic is located.

Here's another try.  In a microcoded machine, the same hardware is used for
every microinstruction.  In random logic, custom designed circuitry is used
for each special case.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Encoding an ISA: Random Logic vs. Control Stores
  2021-11-30 23:07         ` Jon Steinhart
@ 2021-11-30 23:18           ` Henry Bent
  2021-12-01  5:00             ` Jon Steinhart
  0 siblings, 1 reply; 17+ messages in thread
From: Henry Bent @ 2021-11-30 23:18 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

On Tue, 30 Nov 2021 at 18:10, Jon Steinhart <jon@fourwinds.com> wrote:

> Humm writes:
> > Quoth Jon Steinhart:
> > >arnold@skeeve.com writes:
> > >> Can someone please explain why it's called "random" logic? Discrete
> > >> logic I understand (more or less), but I've not heard the term
> "random"
> > >> used in this context before now.
> > >
> > >Well, as a recovered random logic designer, I think that the name comes
> > >from there being no particular structure to the logic.  Many parts of
> > >logic design are very regular, think memory.  But that regularity
> doesn't
> > >exist when, for example, decoding irregular instructions.
> >
> > Now that’s a “random” definition.
> >
> > --
> > Humm
>
> OK, I'll try again.  For anybody familiar with Portland, Oregon, it's the
> difference between driving in Northwest where there's a rectangular grid
> numbered in one direction and alphabetical in the other, and approaching
> the Ross Island Bridge from the west side which appears to be designed by
> someone following a goat while tripping their brains out.  One can address
> Northwest Portland quite easily unlike getting onto the Ross Island Bridge.
>

So - and as I say this as someone who has no direct experience with this
level of logic - everything is directly addressable but the difference is
in how you get there?

-Henry

[-- Attachment #2: Type: text/html, Size: 1903 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Encoding an ISA: Random Logic vs. Control Stores
  2021-11-30 21:45       ` Humm
@ 2021-11-30 23:07         ` Jon Steinhart
  2021-11-30 23:18           ` Henry Bent
  0 siblings, 1 reply; 17+ messages in thread
From: Jon Steinhart @ 2021-11-30 23:07 UTC (permalink / raw)
  To: tuhs

Humm writes:
> Quoth Jon Steinhart:
> >arnold@skeeve.com writes:
> >> Can someone please explain why it's called "random" logic? Discrete
> >> logic I understand (more or less), but I've not heard the term "random"
> >> used in this context before now.
> >
> >Well, as a recovered random logic designer, I think that the name comes
> >from there being no particular structure to the logic.  Many parts of
> >logic design are very regular, think memory.  But that regularity doesn't
> >exist when, for example, decoding irregular instructions.
>
> Now that’s a “random” definition.
>
> -- 
> Humm

OK, I'll try again.  For anybody familiar with Portland, Oregon, it's the
difference between driving in Northwest where there's a rectangular grid
numbered in one direction and alphabetical in the other, and approaching
the Ross Island Bridge from the west side which appears to be designed by
someone following a goat while tripping their brains out.  One can address
Northwest Portland quite easily unlike getting onto the Ross Island Bridge.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Encoding an ISA: Random Logic vs. Control Stores
  2021-11-30 18:50     ` Jon Steinhart
@ 2021-11-30 21:45       ` Humm
  2021-11-30 23:07         ` Jon Steinhart
  0 siblings, 1 reply; 17+ messages in thread
From: Humm @ 2021-11-30 21:45 UTC (permalink / raw)
  To: tuhs

Quoth Jon Steinhart:
>arnold@skeeve.com writes:
>> Can someone please explain why it's called "random" logic? Discrete
>> logic I understand (more or less), but I've not heard the term "random"
>> used in this context before now.
>
>Well, as a recovered random logic designer, I think that the name comes
>from there being no particular structure to the logic.  Many parts of
>logic design are very regular, think memory.  But that regularity doesn't
>exist when, for example, decoding irregular instructions.

Now that’s a “random” definition.

-- 
Humm

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Encoding an ISA: Random Logic vs. Control Stores
  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
  1 sibling, 1 reply; 17+ messages in thread
From: Jon Steinhart @ 2021-11-30 18:50 UTC (permalink / raw)
  To: tuhs

arnold@skeeve.com writes:
> Can someone please explain why it's called "random" logic? Discrete
> logic I understand (more or less), but I've not heard the term "random"
> used in this context before now.

Well, as a recovered random logic designer, I think that the name comes
from there being no particular structure to the logic.  Many parts of
logic design are very regular, think memory.  But that regularity doesn't
exist when, for example, decoding irregular instructions.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Encoding an ISA: Random Logic vs. Control Stores
  2021-11-30 15:30   ` arnold
@ 2021-11-30 15:39     ` Ralph Corderoy
  2021-11-30 18:50     ` Jon Steinhart
  1 sibling, 0 replies; 17+ messages in thread
From: Ralph Corderoy @ 2021-11-30 15:39 UTC (permalink / raw)
  To: tuhs

Hi Arnold,

> Can someone please explain why it's called "random" logic? Discrete
> logic I understand (more or less), but I've not heard the term
> "random" used in this context before now.

I'm more used to ‘hard-wired’ logic versus ‘micro-programmed’ for
microcode but random logic in a known term in this context:

    https://en.wikipedia.org/wiki/Random_logic

    Random logic is a semiconductor circuit design technique that
    translates high-level logic descriptions directly into hardware
    features such as AND and OR gates.  The name derives from the fact
    that few easily discernible patterns are evident in the arrangement
    of features on the chip and in the interconnects between them.

-- 
Cheers, Ralph.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Encoding an ISA: Random Logic vs. Control Stores
  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
  0 siblings, 2 replies; 17+ messages in thread
From: arnold @ 2021-11-30 15:30 UTC (permalink / raw)
  To: tuhs, ron, pbirkel; +Cc: eugene

Can someone please explain why it's called "random" logic? Discrete
logic I understand (more or less), but I've not heard the term "random"
used in this context before now.

Thanks,

Arnold

"Ron Natalie" <ron@ronnatalie.com> wrote:

> Indeed, the early PDPs (10/15/20) had no microprogramming at all.   Even 
> the early microprogrammed ones used "random logic" to implement that.    
> It would take ten years before large scale integration took over.    The 
> PDP-11/44 in 1979 was the last of the discrete logic CPUs.
>
>
> ------ Original Message ------
> From: pbirkel@gmail.com
> To: "'TUHS main list'" <tuhs@minnie.tuhs.org>
> Cc: "'Eugene Miya'" <eugene@soe.ucsc.edu>
> Sent: 11/30/2021 3:07:15 AM
> Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores
>
> >I believe that the PDP-11 ISA was defined at a time when DEC was still using
> >random logic rather than a control stor
>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Encoding an ISA: Random Logic vs. Control Stores
  2021-11-30  8:07 pbirkel
@ 2021-11-30 15:19 ` Ron Natalie
  2021-11-30 15:30   ` arnold
  0 siblings, 1 reply; 17+ messages in thread
From: Ron Natalie @ 2021-11-30 15:19 UTC (permalink / raw)
  To: pbirkel, 'TUHS main list'; +Cc: 'Eugene Miya'

Indeed, the early PDPs (10/15/20) had no microprogramming at all.   Even 
the early microprogrammed ones used "random logic" to implement that.    
It would take ten years before large scale integration took over.    The 
PDP-11/44 in 1979 was the last of the discrete logic CPUs.


------ Original Message ------
From: pbirkel@gmail.com
To: "'TUHS main list'" <tuhs@minnie.tuhs.org>
Cc: "'Eugene Miya'" <eugene@soe.ucsc.edu>
Sent: 11/30/2021 3:07:15 AM
Subject: [TUHS] Encoding an ISA: Random Logic vs. Control Stores

>I believe that the PDP-11 ISA was defined at a time when DEC was still using
>random logic rather than a control stor


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [TUHS] Encoding an ISA: Random Logic vs. Control Stores
@ 2021-11-30  8:07 pbirkel
  2021-11-30 15:19 ` Ron Natalie
  0 siblings, 1 reply; 17+ messages in thread
From: pbirkel @ 2021-11-30  8:07 UTC (permalink / raw)
  To: 'TUHS main list'; +Cc: 'Eugene Miya'

I believe that the PDP-11 ISA was defined at a time when DEC was still using
random logic rather than a control store (which came pretty soon
thereafter).  Given a random logic design it's efficient to organize the ISA
encoding to maximize its regularity.  Probably also of some benefit to
compilers in a memory-constrained environment?

I'm not sure at what point in time we can say "lots of processors" had moved
to a control store based implementation.  Certainly the IBM System/360 was
there in the mid-60's.  HP was there by the late 60's.

-----Original Message-----
From: TUHS <tuhs-bounces@minnie.tuhs.org> On Behalf Of Larry McVoy
Sent: Monday, November 29, 2021 10:18 PM
To: Clem Cole <clemc@ccc.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>; Eugene Miya <eugene@soe.ucsc.edu>
Subject: Re: [TUHS] A New History of Modern Computing - my thoughts

On Sun, Nov 28, 2021 at 05:12:44PM -0800, Larry McVoy wrote:
> I remember Ken Witte (my TA for the PDP-11 class) trying to get me to 
> see how easy it was to read the octal.  If I remember correctly (and I 
> probably don't, this was ~40 years ago), the instructions were divided 
> into fields, so instruction, operand, operand and it was all regular, 
> so you could see that this was some form of an add or whatever, it got 
> the values from these registers and put it in that register.

I've looked it up and it is pretty much as Ken described.  The weird thing
is that there is no need to do it like the PDP-11 did it, you could use
random numbers for each instruction and lots of processors did pretty much
that.  The PDP-11 didn't, it was very uniform to the point that Ken's
ability to read octal made perfect sense.  I was never that good but a
little google and reading and I can see how he got there.

...

--lm


^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2021-12-01 22:11 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-01 14:55 [TUHS] Encoding an ISA: Random Logic vs. Control Stores Douglas McIlroy
2021-12-01 20:27 ` Jon Steinhart
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

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).