[TUHS] [TUHS} PDP-11, Unix, octal?

[TUHS] [TUHS} PDP-11, Unix, octal?

[Noel Chiappa]

    > 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

[TUHS] [TUHS} PDP-11, Unix, octal?

[Steve Johnson]

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

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 (Noel" <Chiappa)>
To:<tuhs at minnie.tuhs.org>
Cc:<jnc at mercury.lcs.mit.edu>
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170117/8df0b66f/attachment.html>

[TUHS] [TUHS} PDP-11, Unix, octal?

[Dan Cross]

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> 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 at mercury.lcs.mit.edu (Noel" <Chiappa)>
>
> To:
> <tuhs at minnie.tuhs.org>
> Cc:
> <jnc at mercury.lcs.mit.edu>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170117/ae827068/attachment.html>

[TUHS] [TUHS} PDP-11, Unix, octal?

[Angelo Papenhoff]

On 17/01/17, Dan Cross wrote:
> 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.

Doesn't exactly answer your question, but from the "Oral History of Ken
Thompson":

Q: As I recall this - once upon a time weren't you trying to get a
PDP-10 or something like that for the lab?

Ken Thompson: Yes, we were arguing that the Multi[cs] machine should be
replaced with a PDP-10. And there was such a huge backlash from
Multi[cs] that it was pretty soundly turned down. It was probably a good
idea, the -10 is a kind of trashy machine with 36 bits - the future just
left it behind.


"the -10 is a kind of trashy machine with 36 bit"
I'm not sure whether I can still like UNIX now :( I hope this is the bad
(?) experience with Multics on the GE-645 speaking.

"the future just left it behind"
More like DEC didn't want internal competition with the VAX.

aap

[TUHS] [TUHS} PDP-11, Unix, octal?

[ron minnich]

On Tue, Jan 17, 2017 at 11:00 PM Angelo Papenhoff <aap at papnet.eu> wrote:

>
> "the future just left it behind"
> More like DEC didn't want internal competition with the VAX.
>
>

The 10 was introduced in 1968, the vax in 1977. They were not even close to
being contemporaries. I don't think your argument is correct.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170118/6be24288/attachment-0001.html>

[TUHS] [TUHS} PDP-11, Unix, octal?

[Angelo Papenhoff]

On 18/01/17, ron minnich wrote:
> The 10 was introduced in 1968, the vax in 1977. They were not even close to
> being contemporaries. I don't think your argument is correct.

The 10 was discontinued in 1983 because the VAX was more important
to DEC, not because the 10 was getting old.

aap

[TUHS] [TUHS} PDP-11, Unix, octal?

[Steve Johnson]

[-- 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>

[TUHS] [TUHS} PDP-11, Unix, octal?

[Charles Anthony]

On Wed, Jan 18, 2017 at 1:04 PM, Steve Johnson <scj at yaccman.com> wrote:

> 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
>
> r 13:40 0.072 1

qedx
i
main () {
  int i;
  i = `abcd`;
}
\f
w foo.c
q
r 13:41 0.169 3

>sl3p>cc>x>cc foo
linkage_editor: Entry not found. foo
r 13:41 0.276 50

>sl3p>cc>x>cc foo.c
"", line 3: gcos BCD constant illegal
cc: An error has occurred while Compiling foo.c.
r 13:41 3.575 211


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

[TUHS] [TUHS} PDP-11, Unix, octal?

[Lars Brinkhoff]

Steve Johnson wrote:
> 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...

The 36-bit PDP-10 initially used 7-track drives, with six frames to a
word.  During its lifetime sunset, 7-track drives were no longer made,
so 9-track drives were used instead.  The most common encoding was to
store a word in five 8-bit frames, with four bits unused.

The PDP-10 did not have a fixed byte size.  Were there any 9-bit
machines?

[TUHS] [TUHS} PDP-11, Unix, octal?

[Peter Jeremy]

On 2017-Jan-18 07:04:31 +0100, Lars Brinkhoff <lars at nocrew.org> wrote:
>The PDP-10 did not have a fixed byte size.  Were there any 9-bit
>machines?

The Honeywell 6000 series (aka 66/DPS, a rebadged GE 6xx series) was
36-bit and supported either 6-bit or 9-bit characters.  I don't recall
how you selected which you were using but I recall both Pascal and APL
used the 9-bit byte.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170119/01344743/attachment.sig>

[TUHS] [TUHS} PDP-11, Unix, octal?

[Charles Anthony]

On Wed, Jan 18, 2017 at 10:47 AM, Peter Jeremy <peter at rulingia.com> wrote:

> On 2017-Jan-18 07:04:31 +0100, Lars Brinkhoff <lars at nocrew.org> wrote:
> >The PDP-10 did not have a fixed byte size.  Were there any 9-bit
> >machines?
>
> The Honeywell 6000 series (aka 66/DPS, a rebadged GE 6xx series) was
> 36-bit and supported either 6-bit or 9-bit characters.  I don't recall
> how you selected which you were using but I recall both Pascal and APL
> used the 9-bit byte.
>
>
The [EIS] instruction set supported 4, 6 and 9 bit operands; it was a
matter of which instructions you used.

For pl1, the instructions generated were driven by the DCLs; for Pascal and
APL, [I would guess] that the compiler/interpreter writers defined
character size to be 9 bits and generated the 9 bit variants of the
instructions.

Move 9 6-bit bytes starting at the 3rd byte in the word, convert to 4 bit
bytes in some signed manner, and store as 10 4-bit bytes starting at offset
6.


MLR ,,400        move with sign captured
ADSC6 FLD1,3,9   sending descriptor
ADSC4 FLD2,6,10  receiving descriptor


-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170118/4b116f73/attachment.html>

[TUHS] [TUHS} PDP-11, Unix, octal?

[Nelson H. F. Beebe]

On the subject of the PDP-10, I recall seeing people at a DECUS
meeting in the early 1980s wearing T-shirts that proclaimed

	I don't care what they say, 36 bits are here to say!

I also recall a funny advertizing video spoof at that meeting that
ended with the line

	At DIGITAL, we're building yesterday's tomorrow, today.

That meeting was about the time of the cancellation of the Jupiter
project at DEC that was planned to produce a substantially more
powerful follow-on to the KL-10 processor model of the PDP-10 (we had
two such at the UofUtah), disappointing most of its PDP-10 customers.

Some of the Jupiter technology was transferred to later VAX models,
but DEC never produced anything faster than the KL-10 in the 36-bit
line.  However, with microcomputers entering the market, and early
workstations from Apollo, LMI, Sun, and others, the economics of
computing changed dramatically, and departmental mainframes ceased to
be cost effective.

Besides our mainframe DEC-20/60 TOPS-20 system in the College of
Science, we also ran Wollongong BSD Unix on a VAX 750, and DEC VMS on
VAX 780 and 8600 models.  In 1987, we bought our first dozen Sun
workstations (and for far less than the cost of a DEC-20/60).

After 12 good years of service (and a forklift upgrade from a 20/40 to
a 20/60), our KL-10 was retired on 31-Oct-1990, and the VAX 8600 in
July 1991.  Our productivity increased significantly in the Unix
world.

I wrote about memories and history and impact of the PDP-10 in two
keynote addresses at TUG meetings in articles and slides available at

	http://www.math.utah.edu/~beebe/talks/2003/tug2003/
	http://www.math.utah.edu/~beebe/talks/2005/pt2005/

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

[TUHS] [TUHS} PDP-11, Unix, octal?

[Doug McIlroy]

> I understand why other DEC architectures (e.g. PDP-7) were octal: 18b is
a multiple of 3. But PDP-11 is 16b, multiple of 4.

Octal predates the 6-bit byte. Dumps on Whirwind II, a 16-bit machine,
were issued in octal. And to help with arithmetic, the computer lab
had an octal Friden (IIRC) desk calculator. One important feature of
octal is you don't have to learn new numerals and their addition
and multiplication tables, 2.5x the size of decimal tables.

Established early, octal was reinforced by a decade of 6-bit bytes.
Perhaps the real question is why did IBM break so completely to hex
for the 360? (Absent actual knowledge, I'd hazard a guess that it
was eased in on the 7030.)

Doug> I understand why other DEC architectures (e.g. PDP-7) were octal: 18b is
a multiple of 3. But PDP-11 is 16b, multiple of 4.

Octal predates the 6-bit byte. Dumps on Whirwind II, a 16-bit machine,
were issued in octal. And to help with arithmetic, the computer lab
had an octal Friden (IIRC) desk calculator. One important feature of
octal is you don't have to learn new numerals and their addition
and multiplication tables, 2.5x the size of decimal tables.

Established early, octal was reinforced by a decade of 6-bit bytes.
Perhaps the real question is why did IBM break so completely to hex
for the 360? (Absent actual knowledge, I'd hazard a guess that it
was eased in on the 7030.)

Doug
=

[TUHS] [TUHS} PDP-11, Unix, octal?

[Clem Cole]

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

On Mon, Jan 16, 2017 at 9:23 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> ctal was reinforced by a decade of 6-bit bytes.
> Perhaps the real question is why did IBM break so completely to hex
> for the 360?
>
​I may be able to help a little here.  A few years ago I used work with
Russ Robelen who was the Chief Designer of the 360/50​.   Russ regaled us
with a number of the stories from those times and having met a few of the
personalities involved in them I tend to believe Russ's stories as I have
heard other of similar color.

The first important thing about the 360 was it was supposed to be an the
first ASCII machine from IBM.   It's funny how history would use prove it
otherwise, but IBM had invested heavily and originally planned on going
ASCII.   And the key is that ASCII was originally a 7-bit character set,
being able to store a 7 bit character was an important design idea for the
architecture.

According to Russ, Amdahl came up with some [IMO hokey] schemes (similar to
what CDC would do) that mapped into 6 bits.  I understand that he even
proposed a 7-bit byte.   He felt that 8 bits was wasteful of the hardware.
Russ says that, Brooks would toss him out of his office and said something
on the order don't come back until you have a power of 2 - that he (Brooks)
did not know how to program things in multiples of 3 and things made of 7s
were ever worse.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170118/288fcf7c/attachment.html>