The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Subject: [TUHS] Harvard and Von Neumann Architectures and Unix
Date: Fri, 24 Nov 2017 16:43:42 -0500 (EST)	[thread overview]
Message-ID: <20171124214342.A4A8818C0D0@mercury.lcs.mit.edu> (raw)

    > From: Will Senn <will.senn at gmail.com>

    > I am curious about how the Harvard Architecture relates to Unix,
    > historically. If the Harvard Architecture is predicated on the
    > separation of code from data in order to prevent self-modifying code (my
    > interpretation)

That's not the 'dictionary' definition, which is 'separate paths for
instructions and data'. But let's go with the 'no self-modifying code' one for
the moment.

The thing is that self-modifying code is pretty much an artifact of the dawn
of computers, before the economics of gates moved from that of tubes, to
transistors, and also before people understood how important good support for
subroutines was. (This latter is a reference to how Whirlwind did subroutines,
with self-modifying code.) Once people had index registers, and lots of
registers in general, self-modifying code (except for a few small, special
hacks like bootstraps which had to fit in tiny spaces) became as dead as the
dodo.

It's just a Bad Idea.

    > then it would seem to me to be somewhat at odds with a Unix philosophy
    > of extreme abstraction (code, data, it's all 0's and 1's, after all).

The people who built Unix were fundamentally very practical. Self-modifing
code is not 'practical'. (And note that Unix from V4:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/text.c

onward has support for pure text - for practical reasons).

    > the PDP-11 itself, with the Unibus and apparently agnostic ISA seem to
    > summarily reject the Harvard Architecure...

You could say that of a zillion computers. The only recent computer I can
think of offhand with separate instruction and data paths was the AMD 42K
(nice chip, I used it in a product we built at Proteon). They had separate
ports for instructions and data purely for performance reasons. (Our card had
a pathway which allowed the CPU to write the instruction memory, needed during
booting, obviously; the details as to how we did it escape me now.)


    > From: Jon Steinhart

    > For all intents and purposes instructions were separate from data from
    > the PDP 11/70 on.

s/70/45/.

And the other -11 memory management (as on the /40, /23, etc) does allow for
execute-only 'segments' (they call them 'pages' in the later versions of the
manual, but they're not) - again, separating code from data. Unix used this
for shared pure texts.

And note that those machines with separate I+D space don't meet the dictionary
definition either, because they only have one bus from the CPU to memory,
shared between data and instruction fetches.

       Noel


             reply	other threads:[~2017-11-24 21:43 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-24 21:43 Noel Chiappa [this message]
2017-11-24 21:50 ` Jon Steinhart
2017-11-25 21:55   ` William Cheswick
2017-11-25 23:15     ` Dave Horsfall
2017-11-24 22:20 ` Mike Markowski
2017-11-24 22:31   ` Dave Horsfall
  -- strict thread matches above, loose matches on Subject: below --
2017-11-27 17:11 Noel Chiappa
2017-11-28  0:23 ` Dave Horsfall
2017-11-27 16:11 Noel Chiappa
2017-11-27 16:50 ` Larry McVoy
2017-11-27 17:08   ` Clem Cole
2017-11-27 18:21     ` Lawrence Stewart
2017-11-27 18:30       ` Lars Brinkhoff
2017-11-27 18:14   ` Warner Losh
2017-11-27 18:26     ` Paul Winalski
2017-11-27 17:35 ` Ian Zimmerman
2017-11-28 14:55 ` Tim Bradshaw
2017-11-28 19:45   ` Paul Winalski
2017-11-25 17:34 Doug McIlroy
2017-11-25 14:24 Noel Chiappa
2017-11-25 15:58 ` Lawrence Stewart
2017-11-25 16:10 ` Lars Brinkhoff
2017-11-25 19:59 ` Steve Simon
2017-11-25 21:59 ` Bakul Shah
2017-11-25  3:14 Doug McIlroy
2017-11-25  4:16 ` Jon Steinhart
2017-11-25  5:17   ` ron minnich
2017-11-25 14:23 ` Ralph Corderoy
2017-11-24 19:25 Will Senn
2017-11-24 19:28 ` Jon Steinhart
2017-11-27 14:50 ` Tony Finch

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20171124214342.A4A8818C0D0@mercury.lcs.mit.edu \
    --to=jnc@mercury.lcs.mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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