The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: scj@yaccman.com (Steve Johnson)
Subject: [TUHS] [TUHS} PDP-11, Unix, octal?
Date: Wed, 18 Jan 2017 13:04:20 -0800	[thread overview]
Message-ID: <510395f632697f73c8a4d90e562790dfa8c082d5@webmail.yaccman.com> (raw)
In-Reply-To: <CAEoi9W6A9ttt-LAhKAGFeGf5UaVhiqoVfaNmJ3dooB2obPqNkg@mail.gmail.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4535 bytes --]

The PDP-10 and the GE/Honeywell were the two machines I recall that
elicited Dennis' comment about 10-track tape drives.  When I ported C
to the Honeywell machine at the Murray Hill comp center, I used 9-bit
bytes as the default, and added a syntax `abcd` to create a constant
in the 6-bit character set.  Most of the OS calls used 6-bit
characters, although the time-sharing system was moving to 9-bits. 
And most of the use of C on the Honeywell was in the time-sharing
system.

Quite a few years later, I discovered accidentally that the syntax
`abcd` was still accepted on the Sun compiler, that had been based on
PCC.  It drew some kind of error message like "GCOS characters not
supported", presumably because some switch was turned off in the
machine-dependent files...

Steve

----- Original Message -----
From: "Dan Cross" <crossd@gmail.com>
To:"Steve Johnson" <scj at yaccman.com>
Cc:"Noel Chiappa" <jnc at mercury.lcs.mit.edu>, "TUHS main list"
<tuhs at minnie.tuhs.org>
Sent:Tue, 17 Jan 2017 22:36:12 -0500
Subject:Re: [TUHS] [TUHS} PDP-11, Unix, octal?

A question about 36 bit machines....

In some of the historical accounts I've read, it seems that before the
PDP-11 a pitch was made for a PDP-10 to support the then-nascent Unix
efforts. This was shot down by labs management and sometime later the
PDP-11 arrived and within a decade or so the question of byte width
was the creatively settled for general purpose machines.

The question then is twofold: why a PDP-10 in the early 70s (instead
of, say, a 360 or something) and why later the aversion to
word-oriented machines? The PDP-7 was of course word oriented.

I imagine answers have to do with cost/performance for the former and
with regard to the latter, a) the question was largely settled by the
middle of the decade, and b) by then Unix had evolved so that a port
was considered rather different than a rewrite.  But I'd love to hear
from some of the players involved.

        - Dan C.

On Jan 18, 2017 10:06 AM, "Steve Johnson" <scj at yaccman.com [1]> wrote:
When we were considering what machine to port PDP-11 Unix to, there
were several 36-bit machines around and some folks were lobbying for
them.   Dennis' comment was quite characteristically succinct: "I'll
consider it if they throw in a 10-track tape drive...".    Just
thinking about Unix (and C!) on a machine where the byte size does not
evenly divide the word size is pretty painful...

(Historical note: before networking, magnetic tapes were essential for
backups and moving large quantities of data.  Data was stored in
magnetic dots running across the tape, and typically held a character
plus a parity bit.  Thus, there were 7-track drives for 6-bit
machines, and 9-track drives for 8-bit machines.  But nothing for
9-bit machines...)

----- Original Message -----
From: "jnc@mercury.lcs.mit.edu [2] (Noel" <Chiappa)>
To:<tuhs at minnie.tuhs.org [3]>
Cc:<jnc at mercury.lcs.mit.edu [4]>
Sent:Tue, 17 Jan 2017 21:33:58 -0500 (EST)
Subject:Re: [TUHS] [TUHS} PDP-11, Unix, octal?

 > From: Doug McIlroy

 > Perhaps the real question is why did IBM break so completely to hex
for
 > the 360?

 Probably because the 360 had 8-bit bytes?

 Unless there's something like the PDP-11 instruction format which
makes octal
 optimal, octal is a pain working with 8-bit bytes; anytime you're
looking at
 the higher bytes in a word, unless you are working through software
which
 will 'interpret' the bytes for you, it's a PITA.

 The 360 instruction coding doesn't really benefit from octal (well,
 instructions are in 4 classes, based on the high two bits of the
first byte,
 but past that, hex works better); opcodes are 8 or 16 bits, and
register
 numbers are 4 bits.

 As to why the 360 had 8-bit bytes, according to "IBM's 360 and Early
370
 Systems" (Pugh, Johnson, and Palmer, pp. 148-149), there was a big
fight over
 whether to use 6 or 8, and they finally went with 8 because i)
statistics
 showed that more customer data was numbers, rather than text, and
storing
 decimal numbers in 6-bit bytes was inefficient (BCD does two digits
per 8-bit
 byte), and ii) they were looking forward to handling text with upper-
and
 lower-case.

 Noel
  

Links:
------
[1] mailto:scj at yaccman.com
[2] mailto:jnc at mercury.lcs.mit.edu
[3] mailto:tuhs at minnie.tuhs.org
[4] mailto:jnc at mercury.lcs.mit.edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170118/9d2bf2be/attachment-0001.html>


  parent reply	other threads:[~2017-01-18 21:04 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-18  2:33 Noel Chiappa
2017-01-18  3:06 ` Steve Johnson
2017-01-18  3:36   ` Dan Cross
2017-01-18  6:53     ` Angelo Papenhoff
2017-01-18  7:31       ` ron minnich
2017-01-18  8:09         ` Angelo Papenhoff
2017-01-18 21:04     ` Steve Johnson [this message]
2017-01-18 21:42       ` Charles Anthony
2017-01-18  6:04   ` Lars Brinkhoff
2017-01-18 18:47     ` Peter Jeremy
2017-01-18 18:58       ` Charles Anthony
  -- strict thread matches above, loose matches on Subject: below --
2017-01-18 14:28 Nelson H. F. Beebe
2017-01-17  2:23 Doug McIlroy
2017-01-18 16:47 ` Clem Cole

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=510395f632697f73c8a4d90e562790dfa8c082d5@webmail.yaccman.com \
    --to=scj@yaccman.com \
    /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).