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(a)yaccman.com> wrote:

On Tue, Jan 17, 2017 at 11:00 PM Angelo Papenhoff <aap(a)papnet.eu> 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 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" &lt;crossd(a)gmail.com&gt; To:"Steve Johnson" &lt;scj(a)yaccman.com&gt; Cc:"Noel Chiappa" &lt;jnc(a)mercury.lcs.mit.edu&gt;du>, "TUHS main list" &lt;tuhs(a)minnie.tuhs.org&gt; 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" &lt;scj(a)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: &quot;jnc(a)mercury.lcs.mit.edu [2] (Noel" <Chiappa)> To:<tuhs@minnie.tuhs.org [3]> Cc:<jnc@mercury.lcs.mit.edu [4]> Sent:Tue, 17 Jan 2017 21:33:58 -0500 (EST) Subject:Re: [TUHS] [TUHS} PDP-11, Unix, octal? for 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@yaccman.com [2] mailto:jnc@mercury.lcs.mit.edu [3] mailto:tuhs@minnie.tuhs.org [4] mailto:jnc@mercury.lcs.mit.edu

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

On Wed, Jan 18, 2017 at 10:47 AM, Peter Jeremy &lt;peter(a)rulingia.com&gt; wrote: 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