Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS?

[Acceptable Name]

Ritchie, Dennis M. (1977). The Unix Time-sharing System: A retrospective. Tenth Hawaii International Conference on the System Sciences. "...a good case can be made that UNIX is in essence a modern implementation of MIT’s CTSS system."
https://www.bell-labs.com/usr/dmr/www/retro.pdf

There's the citation. Why did he write that?

[John Levine]

Post by Acceptable Name
Ritchie, Dennis M. (1977). The Unix Time-sharing System: A retrospective. Tenth Hawaii International Conference on the System Sciences. "...a good case
can be made that UNIX is in essence a modern implementation of MIT’s CTSS system."
https://www.bell-labs.com/usr/dmr/www/retro.pdf
There's the citation. Why did he write that?

He was probably comparing it to the much more complex Multics.

CTSS and Unix both had a simple file system, typically one process connected
to each user console, and (at that time) no paging or other stuff that unified
memory and disk.

In the ensuing 45 years since he wrote that paper, Unix has gotten more
Multics-ish with paging and dynamic linking.

[Acceptable Name]

Post by John Levine

Post by Acceptable Name
Ritchie, Dennis M. (1977). The Unix Time-sharing System: A retrospective. Tenth Hawaii International Conference on the System Sciences. "...a good case
can be made that UNIX is in essence a modern implementation of MIT’s CTSS system."
https://www.bell-labs.com/usr/dmr/www/retro.pdf
There's the citation. Why did he write that?

He was probably comparing it to the much more complex Multics.
CTSS and Unix both had a simple file system, typically one process connected
to each user console, and (at that time) no paging or other stuff that unified
memory and disk.

That's along the lines of what I was thinking. The example of the file system is probably not a good one to include in the comparison as Ken Thompson clearly stated that he was inspired to only adopt two things from Multics, the file system and the shell.^1

1. Seibel, Peter (2009). Coders at work: reflections on the craft of programming. New York: Apress. p. 463. ISBN 9781430219491. "The things that I [Ken Thompson] liked [about Multics] enough to actually take were the hierarchical file system and the shell."

I do have list of other design and terminology elements that CTSS and UNIX have in common:

UNIX block devices have a strategy. CTSS disk, drum and tape drivers have strategy modules.

UNIX and CTSS both have PANIC. The CTSS PANIC was manually-invoked by toggling console switch positions.

UNIX and CTSS both have core dump spelled "CORDMP" in six letters on CTSS. The CTSS CORDMP was invoked under software control as in a subroutine (function) call.

CTSS has UNLINK TSSDC. which is linked to DELETE (but UNLINK might only erase links, not other types of files?). UNIX has unlink, a system call which is used by rm to remove files.

Programs on CTSS could be sent "quit" and "interrupt" signals generated by pressing keys on the terminal. CTSS documentation uses the term "signals" in this context.

The term "canonical" as in canonical terminal input mode (process erase and kill characters typed on a terminal) is used by both CTSS and UNIX. Unix/Linux still have an ICANON mode bit.

Erasing (killing) a line of input typed into a terminal on both CTSS and (vintage) UNIX (by default) is accomplished by typing the @ character. Likewise # erases a single character on both.

UNIX and CTSS both have swapping of process memory to disk.

This list is a work-in-progress; I've added items to it and removed some from it as I learn more about CTSS.

In addition to the technology, Robert Fano repeatedly discusses and writes about the social aspects of CTSS which is echoed in DMR's paper cited above. Fano also spoke of the importance of designing an OS around a file system which is what Ken Thomson did with UNIX.

Post by John Levine
In the ensuing 45 years since he wrote that paper, Unix has gotten more
Multics-ish with paging and dynamic linking.
--
Regards,
Please consider the environment before reading this e-mail. https://jl.ly

[Peter Flass]

Post by John Levine

Post by Acceptable Name
Ritchie, Dennis M. (1977). The Unix Time-sharing System: A
retrospective. Tenth Hawaii International Conference on the System
Sciences. "...a good case
can be made that UNIX is in essence a modern implementation of MIT’s CTSS system."
https://www.bell-labs.com/usr/dmr/www/retro.pdf
There's the citation. Why did he write that?

He was probably comparing it to the much more complex Multics.
CTSS and Unix both had a simple file system, typically one process connected
to each user console, and (at that time) no paging or other stuff that unified
memory and disk.
In the ensuing 45 years since he wrote that paper, Unix has gotten more
Multics-ish with paging and dynamic linking.

It’s been a pattern. At the time PL/I was considered bloated, but since
then other languages have added, or been designed with, most of the more
complex features of PL/I. C started life as a nice simple language, and has
since gotten more and bloated, to say nothing of languages like C++.

[Acceptable Name]

Post by Peter Flass

Post by John Levine

Post by Acceptable Name
Ritchie, Dennis M. (1977). The Unix Time-sharing System: A
retrospective. Tenth Hawaii International Conference on the System
Sciences. "...a good case
can be made that UNIX is in essence a modern implementation of MIT’s CTSS system."
https://www.bell-labs.com/usr/dmr/www/retro.pdf
There's the citation. Why did he write that?

He was probably comparing it to the much more complex Multics.
CTSS and Unix both had a simple file system, typically one process connected
to each user console, and (at that time) no paging or other stuff that unified
memory and disk.
In the ensuing 45 years since he wrote that paper, Unix has gotten more
Multics-ish with paging and dynamic linking.

It’s been a pattern. At the time PL/I was considered bloated, but since
then other languages have added, or been designed with, most of the more
complex features of PL/I. C started life as a nice simple language, and has
since gotten more and bloated, to say nothing of languages like C++.
--
Pete

CTSS was created by taking IBM FORTRAN Monitor System (FMS) with FORTRAN Assembly Program (FAP) and modifying it. FMS and FAP were already debugged. On Multics they started with the design specifications for PL/1 and no code. They had to write the code for PL/1 to have the first working version of the language. MIT people tried to outsource that and the contractors failed to deliver PL/1. UNIX was more like CTSS as it started on an assembler that was already debugged; C came later.

CTSS was created on the IBM 709 which was debugged hardware. It was "ported" to the 7090 and later 7094 which were the same. The GE 645 was created for Multics, first generation, full of hardware bugs that they mostly had to write Multics code with work-arounds and GE was not used to making large systems so only some hardware issues were addressed. UNIX was more like CTSS because it was on a PDP-7 which was not full of hardware bugs like the GE 645.

CTSS had very primitive memory management, two core (RAM) boxes called A core and B core. Programs in the A core were privileged as in able to use all of the CPU instructions while programs in the B core could not use certain ones. Programs on CTSS in the B core did not have issues with other programs as there was only one program in the B core at a time. Multics had much more complex memory protection rings of protection, etc. UNIX on the PDP-7 had no memory management, it was common to call out Dangerous program! when you ran something that could mess up all the other program's memory.

Robert Fano, seeing people cooperating on CTSS wrote about the social aspects of time-sharing. Dennis Richie the the paper I cited writes about cooperation on UNIX the same way.

Because it took so long to have an operational Multics, Project MAC was forced to use CTSS for years. Bell Labs was part of project MAC and therefor Ken Thomson of Bell Labs used CTSS extensively for years. For example he wrote that he developed "regular expressions" on an IBM 7094 which only could be running CTSS based on the Project MAC context (see footnote 1).

Ken Thompson's CTSS experience leads to many of the UNIX features having similar terminology and design; none of the CTSS code was directly portable to UNIX but I am able to come up with a list (a work-in-progress) of the technological similarities:

UNIX block devices have a strategy. CTSS disk, drum and tape drivers have strategy modules. At the very least the terminology, strategy, matches.

UNIX and CTSS both have PANIC. The CTSS PANIC was manually-invoked by toggling console switch positions. Again another terminology match, a design match too as both systems bring down the systems on a panic.

UNIX and CTSS terminal drivers have multiple similarities. Both share the same word for processing erase and kill (erase a line), canonical. Both used the same erase character, #, and the same kill character, @. Both CTSS and UNIX could be sent quit and interrupt signals (and the CTSS Programmer's Guide does use the word signal for this) generated by pressing keys on the terminal to processes.

UNIX and CTSS had swapping of programs from core (RAM) to disk (in the case of CTSS it was drum not disk).

-----
1. Regular Expression Search Algorithm, Ken Thompson, 1968, Bell Telephone Laboratories, Inc., Murray Hill, New Jersey

[Lars Brinkhoff]

Post by Acceptable Name
Ken Thompson's CTSS experience leads to many of the UNIX features having similar terminology and design

Don't forget Thompson also had experience with the Berkeley timesharing system. Maybe the term "fork" got to Unix from there?

[Acceptable Name]

Post by Acceptable Name
Ken Thompson's CTSS experience leads to many of the UNIX features having similar terminology and design

Don't forget Thompson also had experience with the Berkeley timesharing system. Maybe the term "fork" got to Unix from there?

Yes, he borrowed from Project Genie.

The point I'm trying to make is that it is very common to think of UNIX as a mini Multics not a maxxed-out CTSS.

Ken Thompson said that he only borrowed two concepts from Multics, the shell as a user program not part of any kernel or supervisor and the idea of a hierarchical file system. See Seibel, Peter (2009). Coders at work: reflections on the craft of programming. New York: Apress. p. 463. ISBN 9781430219491. "The things that I [Ken Thompson] liked [about Multics] enough to actually take were the hierarchical file system and the shell".

[Lars Brinkhoff]

Post by Acceptable Name
Yes, he borrowed from Project Genie.
The point I'm trying to make is that it is very common to think of UNIX as a mini Multics not a maxxed-out CTSS.

I agree it's an interesting angle to explore.

This seems apropos:
https://www.princeton.edu/~hos/mike/transcripts/thompson.htm

"That's were most of the ideas came from was the combination of those three systems. The 940 system... what became the 940 system, CTSS and Multics"

[Acceptable Name]

Post by Lars Brinkhoff

Post by Acceptable Name
Yes, he borrowed from Project Genie.
The point I'm trying to make is that it is very common to think of UNIX as a mini Multics not a maxxed-out CTSS.

I agree it's an interesting angle to explore.
https://www.princeton.edu/~hos/mike/transcripts/thompson.htm
"That's were most of the ideas came from was the combination of those three systems. The 940 system... what became the 940 system, CTSS and Multics"

One of the things about Multics is that I shoulder surfed Eagle Scouts (only once) in the Honeywell building while they ran Multics. I didn't get it, I was very youngnic. I also used AI.AI.MIT.EDU for a short while as a TURIST by accessing it over a TCP-to-Chaosnet bridge that allowed access from Unix to ITS after the IMP was removed. Both times I really didn't get it. All I saw in ITS was some system where you could issue commands to without logging in. I rapidly lost interest and went back to examining very early Gnu software being developed. Those were the days, just dial into GSFC to a LAT and telnet to MIT or SRINIC to pick up the latest hosts file.

[Acceptable Name]

Post by Lars Brinkhoff

Post by Acceptable Name
Yes, he borrowed from Project Genie.
The point I'm trying to make is that it is very common to think of UNIX as a mini Multics not a maxxed-out CTSS.

I agree it's an interesting angle to explore.
https://www.princeton.edu/~hos/mike/transcripts/thompson.htm
"That's were most of the ideas came from was the combination of those three systems. The 940 system... what became the 940 system, CTSS and Multics"

One of the things about Multics is that I shoulder surfed Eagle Scouts (only once) in the Honeywell building while they ran Multics. I didn't get it, I was very youngnic. I also used AI.AI.MIT.EDU for a short while as a TURIST by accessing it over a TCP-to-Chaosnet bridge that allowed access from Unix to ITS after the IMP was removed. Both times I really didn't get it. All I saw in ITS was some system where you could issue commands to without logging in. I rapidly lost interest and went back to examining very early Gnu software being developed. Those were the days, just dial into GSFC to a LAT and telnet to MIT or SRINIC to pick up the latest hosts file.

One more thing, I did get ITS experience on emulators and I remember corresponding via email with someone who told me that before creating a U.F.D. by using print, you had to deposit a byte somewhere to do it. Is it true?

[Lars Brinkhoff]

Post by Acceptable Name
One more thing, I did get ITS experience on emulators and I remember corresponding via email with someone who told me that before creating a U.F.D. by using print, you had to deposit a byte somewhere to do it. Is it true?

The semi secret way to create a new directory on recent versions of ITS, is to print a file name called ..NEW. (UDIR). You don't have to make any preparations for this to work. It's clearly documented in the .CALLS file, but in DDT ORDER so accidental gefingerpoking by lusers was discouraged.

In earlier versions you had to run-time patch the live system core image using DDT to create a new directory. Maybe it's this deposit you heard about. Or it could be that you have to deposit into a special DDT location in order to run-time patch the system.

[Adam Sampson]

Post by Acceptable Name
(and the CTSS Programmer's Guide does use the word signal for this)

The CTSS Programmer's Guide itself might be another example of Unix
following CTSS practice -- in the 1969 version, the overall structure
and the individual descriptions are much like the Unix manual sections
and pages.

http://bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide_Dec69.pdf

(The Multics manuals and info segments don't seem quite so similar to
me...)

[Acceptable Name]

Post by Adam Sampson

Post by Acceptable Name
(and the CTSS Programmer's Guide does use the word signal for this)

The CTSS Programmer's Guide itself might be another example of Unix
following CTSS practice -- in the 1969 version, the overall structure
and the individual descriptions are much like the Unix manual sections
and pages.
http://bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide_Dec69.pdf
(The Multics manuals and info segments don't seem quite so similar to
me...)
--

Thanks. I noticed yet another one:

IBM FORTRAN II Assembly Program (FAP) is basically the CTSS native language. IBM FAP has a pseudo operation instruction (pseudo op), BCI, (binary coded information) which is used for generating (inserting) BCD data words (strings). CTSS has certain extensions to FAP which include modifications to the BCI FAP pseudo operation instruction. One of those extensions is that the string can be enclosed in delimiters which in the documentation (always) and the code (mostly always) the slash character, /. UNIX uses slashes around strings in documentation and code, for example the ed, and sed are usually invoked with slashes while grep is documented as g/re/p,

[Peter Flass]

Post by Acceptable Name

Post by Adam Sampson

Post by Acceptable Name
(and the CTSS Programmer's Guide does use the word signal for this)

The CTSS Programmer's Guide itself might be another example of Unix
following CTSS practice -- in the 1969 version, the overall structure
and the individual descriptions are much like the Unix manual sections
and pages.
http://bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide_Dec69.pdf
(The Multics manuals and info segments don't seem quite so similar to
me...)
--

IBM FORTRAN II Assembly Program (FAP) is basically the CTSS native
language. IBM FAP has a pseudo operation instruction (pseudo op), BCI,
(binary coded information) which is used for generating (inserting) BCD
data words (strings). CTSS has certain extensions to FAP which include
modifications to the BCI FAP pseudo operation instruction. One of those
extensions is that the string can be enclosed in delimiters which in the
documentation (always) and the code (mostly always) the slash character,
/. UNIX uses slashes around strings in documentation and code, for
example the ed, and sed are usually invoked with slashes while grep is
documented as g/re/p,

There are only so many characters that can be used fir delimiters, or for
line editing.

[Acceptable Name]

Post by Peter Flass

Post by Acceptable Name

Post by Adam Sampson

Post by Acceptable Name
(and the CTSS Programmer's Guide does use the word signal for this)

The CTSS Programmer's Guide itself might be another example of Unix
following CTSS practice -- in the 1969 version, the overall structure
and the individual descriptions are much like the Unix manual sections
and pages.
http://bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide_Dec69.pdf
(The Multics manuals and info segments don't seem quite so similar to
me...)
--

IBM FORTRAN II Assembly Program (FAP) is basically the CTSS native
language. IBM FAP has a pseudo operation instruction (pseudo op), BCI,
(binary coded information) which is used for generating (inserting) BCD
data words (strings). CTSS has certain extensions to FAP which include
modifications to the BCI FAP pseudo operation instruction. One of those
extensions is that the string can be enclosed in delimiters which in the
documentation (always) and the code (mostly always) the slash character,
/. UNIX uses slashes around strings in documentation and code, for
example the ed, and sed are usually invoked with slashes while grep is
documented as g/re/p,

There are only so many characters that can be used fir delimiters, or for
line editing.
--
Pete

Right. I added another sentence:

Delimited (quoted) strings on both CTSS and UNIX could use more than just slash, they could use any character other than blank (space) that is not in the string being quoted by the delimiter, i. e. use /foo/ or "foo" etc.

[Bob Eager]

Post by Adam Sampson

Post by Acceptable Name
(and the CTSS Programmer's Guide does use the word signal for this)

The CTSS Programmer's Guide itself might be another example of Unix
following CTSS practice -- in the 1969 version, the overall structure
and the individual descriptions are much like the Unix manual sections
and pages.
http://bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide_Dec69.pdf
(The Multics manuals and info segments don't seem quite so similar to
me...)

Interesting!

And ... Hi, Adam!

[Anne & Lynn Wheeler]

Post by Acceptable Name
UNIX and CTSS terminal drivers have multiple similarities. Both share
the same word for processing erase and kill (erase a line),
canonical. Both used the same erase character, #, and the same kill
signals (and the CTSS Programmer's Guide does use the word signal for
this) generated by pressing keys on the terminal to processes.

other CTSS, MULTICS, CP67 drift, all used 1052 and then 2741 keyboard
(1965) ... "@" was lower-case next to letter "P" and "cent-sign" was
upper case, "#" was lower case below the @/cent-sign ... and double
quotes was uppercase. CP67 used (lower-case) "@" for character-delete
and (on same key, upper-case) "cent-sign" for line-delete.

pg19/figure 9
http://bitsavers.org/pdf/ibm/2741/A24-3415-2_2741_Communication_Terminal.pdf

when I added ASCII/TTY support to CP67m I had choose something else at
least for cent-sign ... but also tried to use keys that were
approx. same position on keyboard (character/line kill)... so played
with useing left&right brackets (in place of "@" and cent-sign).

CTSS & 1050 terminals
https://multicians.org/terminals.html
referenced in above
https://history.computer.org/pioneers/bemer.html

Bemer also at IBM ... ibm 360 was originally suppose to be ASCII machine
(instead of EBCDIC) ... web pages gone 404 but lives on at wayback
machine (biggest computer goof ever)
https://web.archive.org/web/20180513184025/http://www.bobbemer.com/P-BIT.HTM
https://web.archive.org/web/20180402200104/http://www.bobbemer.com/ASCII.HTM
https://web.archive.org/web/20180402194530/http://www.bobbemer.com/FATHEROF.HTM
https://web.archive.org/web/20180402200149/http://www.bobbemer.com/HISTORY.HTM

[Acceptable Name]

Post by Anne & Lynn Wheeler

Post by Acceptable Name
UNIX and CTSS terminal drivers have multiple similarities. Both share
the same word for processing erase and kill (erase a line),
canonical. Both used the same erase character, #, and the same kill
signals (and the CTSS Programmer's Guide does use the word signal for
this) generated by pressing keys on the terminal to processes.

other CTSS, MULTICS, CP67 drift, all used 1052 and then 2741 keyboard
and (on same key, upper-case) "cent-sign" for line-delete.
pg19/figure 9
http://bitsavers.org/pdf/ibm/2741/A24-3415-2_2741_Communication_Terminal.pdf
when I added ASCII/TTY support to CP67m I had choose something else at
least for cent-sign ... but also tried to use keys that were
approx. same position on keyboard (character/line kill)... so played
CTSS & 1050 terminals
https://multicians.org/terminals.html
referenced in above
https://history.computer.org/pioneers/bemer.html
Bemer also at IBM ... ibm 360 was originally suppose to be ASCII machine
(instead of EBCDIC) ... web pages gone 404 but lives on at wayback
machine (biggest computer goof ever)
https://web.archive.org/web/20180513184025/http://www.bobbemer.com/P-BIT.HTM
https://web.archive.org/web/20180402200104/http://www.bobbemer.com/ASCII.HTM
https://web.archive.org/web/20180402194530/http://www.bobbemer.com/FATHEROF.HTM
https://web.archive.org/web/20180402200149/http://www.bobbemer.com/HISTORY.HTM
--
virtualization experience starting Jan1968, online at home since Mar1970

Thanks again. I think in this context it's most important to know what Ken Thompson used prior to creating UNIX.

IBM's biggest mistake ever might have been trying to lock in their customers who had started with IBM by always being different so the non-IBM world would be weirder and harder to adapt to for those customers.

One of the things in the videos I watched was a statement that IBM representative was confronted with MIT promoting time-sharing as more efficient because programmer's didn't have to wait for their jobs to come back hours to days later. The IBM rep purportedly said to the idea of programmer efficiency "you know we're in the business of selling computer time" (implying we want programmers to re-submit batch jobs to use even more time).

This is a good spot in the discussion panel video, how IBM was spending a lot of money on modifying an S360/40 into a time-sharing system and the people going to the 5th floor.

[Charlie Gibbs]

Post by Acceptable Name
IBM's biggest mistake ever might have been trying to lock in their
customers who had started with IBM by always being different so
the non-IBM world would be weirder and harder to adapt to for those
customers.

Oh, I don't know. They seem to have done a pretty good job of
playing the incompatibility game. And then Microsoft came along
and are still pushing it to ever-greater heights.

Post by Acceptable Name
One of the things in the videos I watched was a statement that IBM
representative was confronted with MIT promoting time-sharing as more
efficient because programmer's didn't have to wait for their jobs to
come back hours to days later. The IBM rep purportedly said to the
idea of programmer efficiency "you know we're in the business of
selling computer time" (implying we want programmers to re-submit
batch jobs to use even more time).

And now we live in the era of Software as a Service (SaaS),
with ever-increasing numbers of mouse clicks required to
accomplish the same simple tasks...

[Peter Flass]

Post by Charlie Gibbs

Post by Acceptable Name
IBM's biggest mistake ever might have been trying to lock in their
customers who had started with IBM by always being different so
the non-IBM world would be weirder and harder to adapt to for those
customers.

Oh, I don't know. They seem to have done a pretty good job of
playing the incompatibility game. And then Microsoft came along
and are still pushing it to ever-greater heights.

IBM started first. System/360 was the first of it’s kind, after everybody’s
36-bit or decimal machines. They started from scratch with both the
hardware architecture and the software. Many companies copied the
architecture, to one extent or another, but almost no one wanted to copy
OS/360( (justifiably), so it’s unfair to blame them for being different.
Once they started down that road trying to switch to something else would
have caused more problems than it solved.

Post by Charlie Gibbs

Post by Acceptable Name
One of the things in the videos I watched was a statement that IBM
representative was confronted with MIT promoting time-sharing as more
efficient because programmer's didn't have to wait for their jobs to
come back hours to days later. The IBM rep purportedly said to the
idea of programmer efficiency "you know we're in the business of
selling computer time" (implying we want programmers to re-submit
batch jobs to use even more time).

And now we live in the era of Software as a Service (SaaS),
with ever-increasing numbers of mouse clicks required to
accomplish the same simple tasks...

[John Levine]

IBM started first. System/360 was the first of it’s kind, after everybody’s
36-bit or decimal machines. They started from scratch with both the
hardware architecture and the software. Many companies copied the
architecture, to one extent or another, but almost no one wanted to copy
OS/360( (justifiably), so it’s unfair to blame them for being different.
Once they started down that road trying to switch to something else would
have caused more problems than it solved.

The 360 was the first 8-bit byte addressed machine. We take that for
granted now but at the time it was quite a change from what had gone
before. It also killed off decimal addressing and ones complement
arithmetic.

I can blame them for building EBCDIC and mutant ASCII into the
architecture rather than real ASCII, but at the time I don't think it
was clear that ASCII was going to take over. They also botched the
floating point, but IEEE FP eventually fixed that.

I have never been able to figure out why DEC made the PDP-11
little-endian, when all previous byte addressed machines were big-endian.
If you have a reference about why they did that, I would love to see
it because I have looked and found nothing. If you want to guess about
why, please don't, we've been through that a dozen times already.

[Acceptable Name]

Post by John Levine

Post by Peter Flass
IBM started first. System/360 was the first of it’s kind, after everybody’s
36-bit or decimal machines. They started from scratch with both the
hardware architecture and the software. Many companies copied the
architecture, to one extent or another, but almost no one wanted to copy
OS/360( (justifiably), so it’s unfair to blame them for being different.
Once they started down that road trying to switch to something else would
have caused more problems than it solved.

The 360 was the first 8-bit byte addressed machine. We take that for
granted now but at the time it was quite a change from what had gone
before. It also killed off decimal addressing and ones complement
arithmetic.
I can blame them for building EBCDIC and mutant ASCII into the
architecture rather than real ASCII, but at the time I don't think it
was clear that ASCII was going to take over. They also botched the
floating point, but IEEE FP eventually fixed that.
I have never been able to figure out why DEC made the PDP-11
little-endian, when all previous byte addressed machines were big-endian.
If you have a reference about why they did that, I would love to see
it because I have looked and found nothing. If you want to guess about
why, please don't, we've been through that a dozen times already.
--
Regards,
Please consider the environment before reading this e-mail. https://jl.ly

I read somewhere that RISC-V is little endian because that was good for performance.

Re: IBM being different, in the 1990s I learn Logical Volume Manager (LVM). It was created during the time when OSF/1 was being written by three-headed monster, IBM, HP and DEC. HP and IBM had essentially the same commands with different names. IBM used varyonvg for what HP called vgchange, etc.

[John Levine]

Post by Acceptable Name

Post by John Levine
I have never been able to figure out why DEC made the PDP-11
little-endian, when all previous byte addressed machines were big-endian.

I read somewhere that RISC-V is little endian because that was good for performance.

The PDP-11 was in 1969, RISC-V was four decades later in 2010 by which
time the endian wars had largely burned out.

Data accesses in RISC-V are either endian set by a mode bit, code is
always little-endian. The manual claims that little-endiian makes it
easier to look at instruction bits and see how long the instruction is
which I find unpersuasive. The 360 did that with big-endian
instructions in the 1960s when logic was a lot more expensive.

[Scott Lurndal]

Post by John Levine

Post by Acceptable Name

Post by John Levine
I have never been able to figure out why DEC made the PDP-11
little-endian, when all previous byte addressed machines were big-endian.

I read somewhere that RISC-V is little endian because that was good for performance.

The PDP-11 was in 1969, RISC-V was four decades later in 2010 by which
time the endian wars had largely burned out.

I might argue that - big-endian processors are still available and
widely used in packet processing hardware such as DPUs. It's true that
most processors default to little-endian, but that's more because of the
ubiquity of x86 than anything else.

Post by John Levine
Data accesses in RISC-V are either endian set by a mode bit, code is
always little-endian. The manual claims that little-endian makes it
easier to look at instruction bits and see how long the instruction is
which I find unpersuasive.

They'd have to byte-swap the 32-bit instruction before decoding if they
accepted big-endian instructions or add a bunch of gates with
a dependency on the endianness bit in a control register. That
dependency would add complexity for OoO implementations.

Same for ARMv8 where the 32-bit instructions are always little-endian.

Makes sense, since the main
use for big-endian nowadays is to handle IP packets without byteswapping
and for processing data (e.g. interoperability). Doesn't
really make sense for the instruction stream to be big-endian.

[John Levine]

Post by Scott Lurndal

Post by John Levine
The PDP-11 was in 1969, RISC-V was four decades later in 2010 by which
time the endian wars had largely burned out.

I might argue that - big-endian processors are still available and
widely used in packet processing hardware such as DPUs. It's true that
most processors default to little-endian, but that's more because of the
ubiquity of x86 than anything else.

By burned out I meant that we don't hear arguments about which is
better. The differences are minor, so the most compelling argument is
to match the other stuff you're already using. Outside of IBM, that's
all little-endian these days.

Post by Scott Lurndal

Post by John Levine
Data accesses in RISC-V are either endian set by a mode bit, code is
always little-endian. The manual claims that little-endian makes it
easier to look at instruction bits and see how long the instruction is
which I find unpersuasive.

They'd have to byte-swap the 32-bit instruction before decoding if they
accepted big-endian instructions or add a bunch of gates with
a dependency on the endianness bit in a control register. That
dependency would add complexity for OoO implementations.

The opcode is in a fixed place in the instruction word. I agree that
it makes sense to pick one byte order for instructions and stay with
it but I still don't see any advantage of one order over the other.

Post by Scott Lurndal
Makes sense, since the main
use for big-endian nowadays is to handle IP packets without byteswapping
and for processing data (e.g. interoperability). Doesn't
really make sense for the instruction stream to be big-endian.

The main use for big-endian nowadays is to run zArchitecture and POWER
code. Byte swapping network data formats isn't that big a deal.

[Peter Maydell]

Post by John Levine

Post by Scott Lurndal
Makes sense, since the main
use for big-endian nowadays is to handle IP packets without byteswapping
and for processing data (e.g. interoperability). Doesn't
really make sense for the instruction stream to be big-endian.

The main use for big-endian nowadays is to run zArchitecture and POWER
code. Byte swapping network data formats isn't that big a deal.

It is apparently a big deal if you have a lot of legacy C code
that was sloppily written to do networking stuff on embedded
MIPS CPUs, because the task of finding where in your millions
of lines of code the missing byteswap function calls need to
be added is nightmarish. It's a lot less risky to say "we'll
migrate CPU architecture for our product but we'll stick to
big-endian" if you've got yourself into that kind of situation.
This is why some architectures retain BE support even when 99%+
of their use is LE, and why Intel has a funky "bi-endian"
compiler where you mark up C typedefs and structs as "this
is big-endian" and the compiler inserts byteswaps for you...

-- PMM

[Ahem A Rivet's Shot]

On 11 Apr 2022 08:20:56 +0100 (BST)

Post by Peter Maydell
It is apparently a big deal if you have a lot of legacy C code
that was sloppily written to do networking stuff on embedded
MIPS CPUs,

Hmm MIPS was very popular with router manufacturers for quite a
while - there'll be a lot of that sort of code I expect.

[Scott Lurndal]

Post by Ahem A Rivet's Shot
On 11 Apr 2022 08:20:56 +0100 (BST)

Post by Peter Maydell
It is apparently a big deal if you have a lot of legacy C code
that was sloppily written to do networking stuff on embedded
MIPS CPUs,

Hmm MIPS was very popular with router manufacturers for quite a
while - there'll be a lot of that sort of code I expect.

I'd have to pull the 10-k for the numbers, but we still sell a substantial
number of MIPS-based chips along with the newer ARMv8-based chips.


https://www.marvell.com/products/data-processing-units.html

[John Levine]

Post by Peter Maydell

Post by John Levine
The main use for big-endian nowadays is to run zArchitecture and POWER
code. Byte swapping network data formats isn't that big a deal.

It is apparently a big deal if you have a lot of legacy C code
that was sloppily written to do networking stuff on embedded
MIPS CPUs, ...

Oh, I totally believe it. Anyone can write bad code, it's not limited
to network data. I would have said there are more POWER chips than
MIPS but now that someone mentioned all the MIPS based routers, who
knows.

I am reminded of the BSD null pointer bug, in which BSD Unix on VAX
happened to have a zero byte at location zero, and a lot of badly
written code depended on being able to dereference a null pointer
and get a null. So a whole generation of early Unix workstations
had to be sure they had a readable null byte at location zero, too.

[Johnny Billquist]

Post by John Levine

Post by Peter Maydell

Post by John Levine
The main use for big-endian nowadays is to run zArchitecture and POWER
code. Byte swapping network data formats isn't that big a deal.

It is apparently a big deal if you have a lot of legacy C code
that was sloppily written to do networking stuff on embedded
MIPS CPUs, ...

Oh, I totally believe it. Anyone can write bad code, it's not limited
to network data. I would have said there are more POWER chips than
MIPS but now that someone mentioned all the MIPS based routers, who
knows.

Yeah. I would have guessed the other way around. Plenty of MIPS in lots
of places. Not seen that many POWER based machines ever. But maybe there
are more out there that I'm not aware of.

Post by John Levine
I am reminded of the BSD null pointer bug, in which BSD Unix on VAX
happened to have a zero byte at location zero, and a lot of badly
written code depended on being able to dereference a null pointer
and get a null. So a whole generation of early Unix workstations
had to be sure they had a readable null byte at location zero, too.

I know this is true for Unix on PDP-11. Part of the reason being that
you don't want to waste a whole page, and people also weren't doing
clever enough things to just loose 64 bytes. But with the limited amount
of virtual memory available, even that might have been considered
wasteful. So it's totally understandable on the PDP-11, even if in a way
unfortunate. But did this really live on on the VAX?
I don't have any older BSD setup on any VAX, so I can't easily check this.

Johnny

[Scott Lurndal]

Post by Johnny Billquist

Post by John Levine

Post by Peter Maydell

Post by John Levine
The main use for big-endian nowadays is to run zArchitecture and POWER
code. Byte swapping network data formats isn't that big a deal.

It is apparently a big deal if you have a lot of legacy C code
that was sloppily written to do networking stuff on embedded
MIPS CPUs, ...

Oh, I totally believe it. Anyone can write bad code, it's not limited
to network data. I would have said there are more POWER chips than
MIPS but now that someone mentioned all the MIPS based routers, who
knows.

Yeah. I would have guessed the other way around. Plenty of MIPS in lots
of places. Not seen that many POWER based machines ever. But maybe there
are more out there that I'm not aware of.

Likewise, I've never seen a Power machine in the real world. MIPS
machines on the other hand (from SGI and in modern networking appliances,
including Cisco and most of the major backbone vendors) abounded.

I also take exception at the characterization of "bad code". When
your design target is big-endian, there's no need to use byteswapping
interfaces.

Post by Johnny Billquist

Post by John Levine
I am reminded of the BSD null pointer bug, in which BSD Unix on VAX
happened to have a zero byte at location zero, and a lot of badly
written code depended on being able to dereference a null pointer
and get a null. So a whole generation of early Unix workstations
had to be sure they had a readable null byte at location zero, too.

I know this is true for Unix on PDP-11. Part of the reason being that
you don't want to waste a whole page, and people also weren't doing
clever enough things to just loose 64 bytes. But with the limited amount
of virtual memory available, even that might have been considered
wasteful. So it's totally understandable on the PDP-11, even if in a way
unfortunate. But did this really live on on the VAX?

Yes. I also spent time circa 1990 fixing broken BSD utilities that
assumed accessing a null pointer would produce a zero value instead of
a SIGSEGV/SIGBUS.

[Ahem A Rivet's Shot]

On Tue, 12 Apr 2022 13:56:45 GMT

Post by Scott Lurndal
I also take exception at the characterization of "bad code". When
your design target is big-endian, there's no need to use byteswapping
interfaces.

Agreed, if you have a task involving manipulation of big endian
entities and have chosen a big endian processor for the job you can
perfectly correctly forget about the problem.

The code isn't bad, just not entirely portable but for embedded use
not portable is fine.

[Peter Maydell]

Post by Ahem A Rivet's Shot
On Tue, 12 Apr 2022 13:56:45 GMT

Post by Scott Lurndal
I also take exception at the characterization of "bad code". When
your design target is big-endian, there's no need to use byteswapping
interfaces.

Agreed, if you have a task involving manipulation of big endian
entities and have chosen a big endian processor for the job you can
perfectly correctly forget about the problem.
The code isn't bad, just not entirely portable but for embedded use
not portable is fine.

...up until the point when you need to switch your embedded
product to a different CPU architecture, when it turns out
that actually it does matter. It's not that hard to put
the conceptually-required-but-happen-to-be-nop transforms in
as you go along. and it's awful to have to go back and
retrofit them, so I maintain that not doing so is indeed
sloppy practice.

-- PMM

[Scott Lurndal]

Post by Peter Maydell

Post by Ahem A Rivet's Shot
On Tue, 12 Apr 2022 13:56:45 GMT

Post by Scott Lurndal
I also take exception at the characterization of "bad code". When
your design target is big-endian, there's no need to use byteswapping
interfaces.

Agreed, if you have a task involving manipulation of big endian
entities and have chosen a big endian processor for the job you can
perfectly correctly forget about the problem.
The code isn't bad, just not entirely portable but for embedded use
not portable is fine.

...up until the point when you need to switch your embedded
product to a different CPU architecture, when it turns out
that actually it does matter. It's not that hard to put
the conceptually-required-but-happen-to-be-nop transforms in
as you go along. and it's awful to have to go back and
retrofit them, so I maintain that not doing so is indeed
sloppy practice.

Actually, the modern CPU's that one would transition that
workload to are generally ARMv8 based, where the applications
can run in little or big-endian mode, while the kernel executes
in either big or little-endian mode.

And for most of those internet protocol accelerator chips (now
known as DPUs), there's custom packet processing hardware in use
that makes porting to other DPU's more complicated leaving aside
any byte order issues.

Most companies using DPUs are transitioning to standard packet processing
frameworks (ODP, etc) rather than using bespoke code which makes
the code more portable to multiple vendors.

[Peter Maydell]

Post by Scott Lurndal

Post by Peter Maydell
...up until the point when you need to switch your embedded
product to a different CPU architecture, when it turns out
that actually it does matter. It's not that hard to put
the conceptually-required-but-happen-to-be-nop transforms in
as you go along. and it's awful to have to go back and
retrofit them, so I maintain that not doing so is indeed
sloppy practice.

Actually, the modern CPU's that one would transition that
workload to are generally ARMv8 based, where the applications
can run in little or big-endian mode, while the kernel executes
in either big or little-endian mode.

Yes, that's where we started. The major reason why
running BE there is even possible is to accomodate all
this legacy sloppily written code.

-- PMM

[Johnny Billquist]

Post by Peter Maydell

Post by Ahem A Rivet's Shot
On Tue, 12 Apr 2022 13:56:45 GMT

Post by Scott Lurndal
I also take exception at the characterization of "bad code". When
your design target is big-endian, there's no need to use byteswapping
interfaces.

Agreed, if you have a task involving manipulation of big endian
entities and have chosen a big endian processor for the job you can
perfectly correctly forget about the problem.
The code isn't bad, just not entirely portable but for embedded use
not portable is fine.

...up until the point when you need to switch your embedded
product to a different CPU architecture, when it turns out
that actually it does matter. It's not that hard to put
the conceptually-required-but-happen-to-be-nop transforms in
as you go along. and it's awful to have to go back and
retrofit them, so I maintain that not doing so is indeed
sloppy practice.

I would disagree since I definitely differentiate between bad code and
non-portable code.

Johnny

[Quadibloc]

Post by Peter Maydell

Post by Ahem A Rivet's Shot
On Tue, 12 Apr 2022 13:56:45 GMT

I also take exception at the characterization of "bad code". When
your design target is big-endian, there's no need to use byteswapping
interfaces.

Agreed, if you have a task involving manipulation of big endian
entities and have chosen a big endian processor for the job you can
perfectly correctly forget about the problem.
The code isn't bad, just not entirely portable but for embedded use
not portable is fine.

...up until the point when you need to switch your embedded
product to a different CPU architecture, when it turns out
that actually it does matter. It's not that hard to put
the conceptually-required-but-happen-to-be-nop transforms in
as you go along. and it's awful to have to go back and
retrofit them, so I maintain that not doing so is indeed
sloppy practice.

I just differ in where to assign the blame.

Why do little-endian CPUs even exist?

Oh, I know, historically it was more efficient to fetch the least
significant part first, and start adding, with the second part
fetched by the time the carry was ready. But there's no excuse
for that today.

Oh, except compatibility with mountains of x86 software.

John Savard

[Andreas Kohlbach]

Post by Quadibloc
Why do little-endian CPUs even exist?

I blame eggs. ;-)

[Rich Alderson]

Post by Andreas Kohlbach

Post by Quadibloc
Why do little-endian CPUs even exist?

I blame eggs. ;-)

A swift response!

[Charlie Gibbs]

Post by Quadibloc
Why do little-endian CPUs even exist?
Oh, I know, historically it was more efficient to fetch the least
significant part first, and start adding, with the second part
fetched by the time the carry was ready. But there's no excuse
for that today.

8080 One little,
8085 Two little,
8086 Three little-endians.
8088 Four little,
80186 Five little,
80286 Six little-endians.
80386 Seven little,
80386SX Eight little,
80486 Nine little-endians.
Pentium DIVIDE ERROR

Post by Quadibloc
Oh, except compatibility with mountains of x86 software.

The only reason everyone uses COBOL is that everyone uses COBOL.
-- me

[Andy Leighton]

Post by Scott Lurndal

Post by Johnny Billquist

Post by John Levine

Post by Peter Maydell

Post by John Levine
The main use for big-endian nowadays is to run zArchitecture and POWER
code. Byte swapping network data formats isn't that big a deal.

It is apparently a big deal if you have a lot of legacy C code
that was sloppily written to do networking stuff on embedded
MIPS CPUs, ...

Oh, I totally believe it. Anyone can write bad code, it's not limited
to network data. I would have said there are more POWER chips than
MIPS but now that someone mentioned all the MIPS based routers, who
knows.

Yeah. I would have guessed the other way around. Plenty of MIPS in lots
of places. Not seen that many POWER based machines ever. But maybe there
are more out there that I'm not aware of.

Likewise, I've never seen a Power machine in the real world.

I used to work at a place that had standardised on IBM RS/6000 which
used POWER CPUs.

Post by Scott Lurndal
MIPS
machines on the other hand (from SGI and in modern networking appliances,
including Cisco and most of the major backbone vendors) abounded.

I would guess that in addition to the IBM stuff, PowerPC also had a load
of Apple Macs and a load of games consoles. As well as a load of older
CISCO and Juniper routers.

[Dan Espen]

Post by Andy Leighton

Post by Scott Lurndal
Likewise, I've never seen a Power machine in the real world.

I used to work at a place that had standardised on IBM RS/6000 which
used POWER CPUs.

Yep, fairly large project were I worked was on RS/6000.
For a while IBM had a line of RS/6000 workstations to compete with Sun.
Never liked smit.

[Andy Leighton]

Post by Dan Espen

Post by Andy Leighton

Post by Scott Lurndal
Likewise, I've never seen a Power machine in the real world.

I used to work at a place that had standardised on IBM RS/6000 which
used POWER CPUs.

Yep, fairly large project were I worked was on RS/6000.
For a while IBM had a line of RS/6000 workstations to compete with Sun.
Never liked smit.

I totally agree about smit. It was horrible. Fortuntely most of the
common things worked and you only had to do something once with smit
and then get the real commands out of the created smit.script

[Ahem A Rivet's Shot]

On Tue, 12 Apr 2022 13:45:43 -0500

Post by Andy Leighton
I totally agree about smit. It was horrible. Fortuntely most of the
common things worked and you only had to do something once with smit
and then get the real commands out of the created smit.script

That was the *only* good thing about smit - it told you how to do
without it.

[Dan Espen]

Post by Ahem A Rivet's Shot
On Tue, 12 Apr 2022 13:45:43 -0500

Post by Andy Leighton
I totally agree about smit. It was horrible. Fortuntely most of the
common things worked and you only had to do something once with smit
and then get the real commands out of the created smit.script

That was the *only* good thing about smit - it told you how to do
without it.

It's almost like the developers at IBM knew how horrible that thing was.

[Anne & Lynn Wheeler]

Yep, fairly large project were I worked was on RS/6000. For a while
IBM had a line of RS/6000 workstations to compete with Sun. Never
liked smit.

the last product did at IBM ... started out HA/6000 to move NYTimes
newspaper system (ATEX) off VAXCluster. I renamed it HA/CMP when I
started doing technically/scientific cluster scaleup with national labs
and commercial cluster scaleup with RDBMS vendors (oracle, informix,
sybase, ingres). It started out relying on the aixv3 journal/logging
filesystem for fast fallover.
https://en.wikipedia.org/wiki/IBM_High_Availability_Cluster_Multiprocessing

The RDBMS vendors all had vaxcluster support in same source base as unix
.. and so I did distributed lock manager with VAXCluster API semantics
to simplify the port. The RDBMS vendors also had their list of
VAXcluster shortcomings that needed improvement .... I had my own list
having worked on mainframe loosely-coupled (cluster) for a couple
decades and having been involved with System/R (original sql/relational)
implementation.

old post about JAN1992 meeting in Ellison's (oracle ceo) conference
room mention 16-way cluster by mid92 and 128-way cluster by ye92
http://www.garlic.com/~lynn/95.html#13

within a few weeks, cluster-scaleup is transferred, announced as
IBM supercomputer (for technical/scientific *ONLY*), and we were told we
couldn't work with anything involving more than four processors. We
leave IBM a few months later. Part of the issue was the mainframe
DB2 people were complaining if we were allowed to continue, it would
be years ahead of them.

After leaving IBM we ware then involved with multiple projects mostly in
the financial industry, although at one point, SUN asks me if I would
consider productizing and shipping
https://en.wikipedia.org/wiki/Spring_(operating_system)
had hardcopy, softcopy gone 404, but lives free at wayback
http://web.archive.org/web/20030404182953/http://java.sun.com/people/kgh/spring/
From one of the Spring Papers:

A Client-Side Stub Interpreter

Petere B. Kessler

Abstract

We have built a research operating system in which all services are
presented through interfaces described by an interface description
language. The system consists of a micro-kernel that supports a small
number of these interfaces, and a large number of interfaces that are
implemented by user-level code. A typical service implements one or
more interfaces, but is a client of many other interfaces that are
implemented elsewhere in the system. We have an interface compiler
that generates client-side and service-side stubs to deliver calls
from clients to services providing location transparency if the client
and server are in different address spaces. The code for client-side
stubs was occupying a large amount of the text space on our clients,
so a stub interpreter was written to replace the client-side stub
methods. The result was that we traded 125k bytes of stub code for 13k
bytes of stub descriptions and 4k bytes of stub interpreter. This
paper describes the stub interpreter, the stub descriptions, and
discusses some alternatives.

... snip ...

There was also financial company that used cluster oracle and HA/SUN for
the first stored-value (gift and merchant) magstripe cards in the US
... and doing large pilot (with a couple large merchants & gas stations)
... there was glitch and database was lost and had to be recreated with
all cards having original $$$ value.

I was brought in to be part of the review ... that opened with SUN VP
giving introducton ... I noted that it was almost word-for-word one of
my sales pitches for HA/CMP.

Turns out it was a couple hardware failures with human errors in between
over a couple month period (disk failure in RAID configuration,
fall-over, a system RAID driver card failure ... and one of the systems
was partially misconfigured).

[Peter Flass]

Post by Dan Espen

Post by Andy Leighton

Post by Scott Lurndal
Likewise, I've never seen a Power machine in the real world.

I used to work at a place that had standardised on IBM RS/6000 which
used POWER CPUs.

Yep, fairly large project were I worked was on RS/6000.
For a while IBM had a line of RS/6000 workstations to compete with Sun.
Never liked smit.

Smitty wasn’t bad. I liked the concept of hand-holding you through a
process once and then giving you the command you could use in the future to
avoid the menu process.

[Dan Espen]

Post by Peter Flass

Post by Dan Espen

Post by Andy Leighton

Post by Scott Lurndal
Likewise, I've never seen a Power machine in the real world.

I used to work at a place that had standardised on IBM RS/6000 which
used POWER CPUs.

Yep, fairly large project were I worked was on RS/6000.
For a while IBM had a line of RS/6000 workstations to compete with Sun.
Never liked smit.

Smitty wasn’t bad. I liked the concept of hand-holding you through a
process once and then giving you the command you could use in the future to
avoid the menu process.

I wonder how many meetings it took to approve the running man animation.

[Chris Adams]

Post by Scott Lurndal
Likewise, I've never seen a Power machine in the real world. MIPS
machines on the other hand (from SGI and in modern networking appliances,
including Cisco and most of the major backbone vendors) abounded.

If you include PowerPC, there of course were a number of generations of
Macs. Some old model TiVo DVRs also used PowerPCs.

While early Ciscos used MIPS CPUs, they moved to custom ASICs a long
time ago for the forwarding plane for better performance and handling of
route table growth. A significant portion of the Internet has run on
Juniper routers as well for quite a while, and they have only ever used
custom ASICs for forwarding, with mostly x86 and some PowerPC used for
the control plane.

--
Chris Adams <***@cmadams.net>

[Peter Flass]

Post by Scott Lurndal

Post by Johnny Billquist

Post by John Levine

Post by Peter Maydell

Post by John Levine
The main use for big-endian nowadays is to run zArchitecture and POWER
code. Byte swapping network data formats isn't that big a deal.

It is apparently a big deal if you have a lot of legacy C code
that was sloppily written to do networking stuff on embedded
MIPS CPUs, ...

Oh, I totally believe it. Anyone can write bad code, it's not limited
to network data. I would have said there are more POWER chips than
MIPS but now that someone mentioned all the MIPS based routers, who
knows.

Yeah. I would have guessed the other way around. Plenty of MIPS in lots
of places. Not seen that many POWER based machines ever. But maybe there
are more out there that I'm not aware of.

Likewise, I've never seen a Power machine in the real world. MIPS
machines on the other hand (from SGI and in modern networking appliances,
including Cisco and most of the major backbone vendors) abounded.

I spent some time on a POWER AIX machine years back. I think now most POWER
chips are used in automotive control.

Post by Scott Lurndal
I also take exception at the characterization of "bad code". When
your design target is big-endian, there's no need to use byteswapping
interfaces.

Post by Johnny Billquist

Post by John Levine
I am reminded of the BSD null pointer bug, in which BSD Unix on VAX
happened to have a zero byte at location zero, and a lot of badly
written code depended on being able to dereference a null pointer
and get a null. So a whole generation of early Unix workstations
had to be sure they had a readable null byte at location zero, too.

I know this is true for Unix on PDP-11. Part of the reason being that
you don't want to waste a whole page, and people also weren't doing
clever enough things to just loose 64 bytes. But with the limited amount
of virtual memory available, even that might have been considered
wasteful. So it's totally understandable on the PDP-11, even if in a way
unfortunate. But did this really live on on the VAX?

Yes. I also spent time circa 1990 fixing broken BSD utilities that
assumed accessing a null pointer would produce a zero value instead of
a SIGSEGV/SIGBUS.

[Peter Flass]

Post by Johnny Billquist

Post by John Levine

Post by Peter Maydell

Post by John Levine
The main use for big-endian nowadays is to run zArchitecture and POWER
code. Byte swapping network data formats isn't that big a deal.

It is apparently a big deal if you have a lot of legacy C code
that was sloppily written to do networking stuff on embedded
MIPS CPUs, ...

Oh, I totally believe it. Anyone can write bad code, it's not limited
to network data. I would have said there are more POWER chips than
MIPS but now that someone mentioned all the MIPS based routers, who
knows.

Yeah. I would have guessed the other way around. Plenty of MIPS in lots
of places. Not seen that many POWER based machines ever. But maybe there
are more out there that I'm not aware of.

Post by John Levine
I am reminded of the BSD null pointer bug, in which BSD Unix on VAX
happened to have a zero byte at location zero, and a lot of badly
written code depended on being able to dereference a null pointer
and get a null. So a whole generation of early Unix workstations
had to be sure they had a readable null byte at location zero, too.

I know this is true for Unix on PDP-11. Part of the reason being that
you don't want to waste a whole page, and people also weren't doing
clever enough things to just loose 64 bytes. But with the limited amount
of virtual memory available, even that might have been considered
wasteful. So it's totally understandable on the PDP-11, even if in a way
unfortunate. But did this really live on on the VAX?
I don't have any older BSD setup on any VAX, so I can't easily check this.
Johnny

On the other hand, there’s no quicker way to root out invalid memory
accesses than to have the machine trap. If nothing else let the OS trap
handler log the access and return null, so the program continues to work,
but now you have a record of what needs to be fixed.

[Peter Maydell]

Post by John Levine

Post by Peter Maydell

Post by John Levine
The main use for big-endian nowadays is to run zArchitecture and POWER
code. Byte swapping network data formats isn't that big a deal.

It is apparently a big deal if you have a lot of legacy C code
that was sloppily written to do networking stuff on embedded
MIPS CPUs, ...

Oh, I totally believe it. Anyone can write bad code, it's not limited
to network data. I would have said there are more POWER chips than
MIPS but now that someone mentioned all the MIPS based routers, who
knows.

I think it's the combination of:
* a widely used big endian CPU in a particular market niche
* a use case that is constantly dealing with big endian
data (ie network packet fields) and so missing byteswaps
are likely to be pervasive rather than limited to a small
part of the codebase
* systems where you can get away with running a completely
different config to everybody else (embedded products can
be built for non-standard endianness; servers running
stock OSes need to go along with the rest of the world)
* directly buying CPUs and designing hardware around them,
not buying off-the-shelf systems

If you don't meet all of those then you just had to bite the
bullet and fix your endianness bugs like the rest of us :-)

-- PMM

[Jorgen Grahn]

Post by Peter Maydell

Post by John Levine

Post by Peter Maydell

Post by John Levine
The main use for big-endian nowadays is to run zArchitecture and POWER
code. Byte swapping network data formats isn't that big a deal.

It is apparently a big deal if you have a lot of legacy C code
that was sloppily written to do networking stuff on embedded
MIPS CPUs, ...

Oh, I totally believe it. Anyone can write bad code, it's not limited
to network data. I would have said there are more POWER chips than
MIPS but now that someone mentioned all the MIPS based routers, who
knows.

* a widely used big endian CPU in a particular market niche
* a use case that is constantly dealing with big endian
data (ie network packet fields) and so missing byteswaps
are likely to be pervasive rather than limited to a small
part of the codebase
* systems where you can get away with running a completely
different config to everybody else (embedded products can
be built for non-standard endianness; servers running
stock OSes need to go along with the rest of the world)

Nitpick: They don't necessarily need to go along: most free Unix
software builds for big-endian and little-endian machines. I'm too
lazy to check if e.g. Debian Linux supports any big-endian
architectures right /now/, but they did supported PowerPC a few years
ago. That's thousands of correctly written programs.

Post by Peter Maydell
* directly buying CPUs and designing hardware around them,
not buying off-the-shelf systems
If you don't meet all of those then you just had to bite the
bullet and fix your endianness bugs like the rest of us :-)

Yes. I find the best way to do that is to treat network buffers etc
as arrays of octets, and never casting them. Unless there's a
performance reason to take shortcuts.

/Jorgen

[Peter Maydell]

Post by Jorgen Grahn

Post by Peter Maydell
* a widely used big endian CPU in a particular market niche
* a use case that is constantly dealing with big endian
data (ie network packet fields) and so missing byteswaps
are likely to be pervasive rather than limited to a small
part of the codebase
* systems where you can get away with running a completely
different config to everybody else (embedded products can
be built for non-standard endianness; servers running
stock OSes need to go along with the rest of the world)

Nitpick: They don't necessarily need to go along: most free Unix
software builds for big-endian and little-endian machines. I'm too
lazy to check if e.g. Debian Linux supports any big-endian
architectures right /now/, but they did supported PowerPC a few years
ago. That's thousands of correctly written programs.

That's kind of what I mean -- Debian doesn't, and never has,
supported big-endian Arm. Now of course Debian totally *could*
build all that software for BE Arm, because it works on
s390x and so on. But there aren't enough general users
out there for anybody to ship a distro for it. Which means
that if you run BE Arm you are absolutely running a
non-standard config where you had to build everything yourself,
and not a stock OS. The set of hardware configurations
you can get a stock OS for is a subset of all the possible
things one might be able to build. (For another example,
you can build x86-based systems that don't look like an
IBM PC, and for some embedded setups you might want to.
Your hardware will work fine, but if you want to run a stock
OS then it's got to look like an x86 PC.)

-- PMM

[Scott Lurndal]

Post by Peter Maydell

Post by Jorgen Grahn

Post by Peter Maydell
* a widely used big endian CPU in a particular market niche
* a use case that is constantly dealing with big endian
data (ie network packet fields) and so missing byteswaps
are likely to be pervasive rather than limited to a small
part of the codebase
* systems where you can get away with running a completely
different config to everybody else (embedded products can
be built for non-standard endianness; servers running
stock OSes need to go along with the rest of the world)

Nitpick: They don't necessarily need to go along: most free Unix
software builds for big-endian and little-endian machines. I'm too
lazy to check if e.g. Debian Linux supports any big-endian
architectures right /now/, but they did supported PowerPC a few years
ago. That's thousands of correctly written programs.

That's kind of what I mean -- Debian doesn't, and never has,
supported big-endian Arm. Now of course Debian totally *could*
build all that software for BE Arm, because it works on

There was a RHEL BE Arm version for a while, IIRC.

Post by Peter Maydell
s390x and so on. But there aren't enough general users
out there for anybody to ship a distro for it. Which means
that if you run BE Arm you are absolutely running a
non-standard config where you had to build everything yourself,

Which is what most networking appliances already do. Custom
linux, generally. ThunderX had both BE and LE builds available
in its software development kit for customers.

Note that you can run BE applications on a LE OS (the OS
just sets SCTLR_EL1[EE] appropriately when scheduling the
process).

Post by Peter Maydell
and not a stock OS. The set of hardware configurations
you can get a stock OS for is a subset of all the possible
things one might be able to build.

Very few network appliances use off-the-shelf operating
systems, and they're the primary users of BE.

As it happens, most customers have chosen to stick with
LE on ARM as modern network stacks handle the byte-swapping
if necessary and most are switching to user-mode frameworks
like https://en.wikipedia.org/wiki/OpenDataPlane.

[Peter Flass]

Post by Scott Lurndal

Post by John Levine

Post by Acceptable Name

Post by John Levine
I have never been able to figure out why DEC made the PDP-11
little-endian, when all previous byte addressed machines were big-endian.

I read somewhere that RISC-V is little endian because that was good for performance.

The PDP-11 was in 1969, RISC-V was four decades later in 2010 by which
time the endian wars had largely burned out.

I might argue that - big-endian processors are still available and
widely used in packet processing hardware such as DPUs. It's true that
most processors default to little-endian, but that's more because of the
ubiquity of x86 than anything else.

Post by John Levine
Data accesses in RISC-V are either endian set by a mode bit, code is
always little-endian. The manual claims that little-endian makes it
easier to look at instruction bits and see how long the instruction is
which I find unpersuasive.

They'd have to byte-swap the 32-bit instruction before decoding if they
accepted big-endian instructions or add a bunch of gates with
a dependency on the endianness bit in a control register. That
dependency would add complexity for OoO implementations.
Same for ARMv8 where the 32-bit instructions are always little-endian.
Makes sense, since the main
use for big-endian nowadays is to handle IP packets without byteswapping
and for processing data (e.g. interoperability). Doesn't
really make sense for the instruction stream to be big-endian.

I would think big-endian is best for instruction decoding. Leaving aside
issues of cache access, the processor can load the first byte to determine
the format (and hence length) of the rest of the instruction, unless the
architecture stores the opcode in the low-order byte and reads that first
in little-endian format.

I forget the details of the Intel 432 architecture, but one of the things
that seems to me to be a misfeature is how much of an instruction had to be
read to begin decoding (IIRC).

[John Levine]

Post by Peter Flass
I would think big-endian is best for instruction decoding. Leaving aside
issues of cache access, the processor can load the first byte to determine
the format (and hence length) of the rest of the instruction, unless the
architecture stores the opcode in the low-order byte and reads that first
in little-endian format.

Look at the x86. Its instruction format treats memory as a stream of
bytes. It is of course little-endian but its instruction format would
work about the same in big-endian.

On the PDP-11 instructions were a sequence of 16 bit words and the
memory was 16 bit words (or later perhaps larger cache lines) so again
instruction decoding would have worked pretty much the same in either
byte order.

[Peter Maydell]

Post by John Levine
On the PDP-11 instructions were a sequence of 16 bit words and the
memory was 16 bit words (or later perhaps larger cache lines) so again
instruction decoding would have worked pretty much the same in either
byte order.

Did the PDP-11 read the whole 16-bit instruction as a single
memory access? (I'm guessing it did.) If you load the whole
instruction at once, as any modern fixed-width-instruction
CPU will, you can lay out the instruction fields in it
however you like, because you've already got all of them.

I think my favourite oddball instruction encoding is
the transputer, which depending on how you think of
it is either a one-byte-per-instruction fixed width encoding,
or else a variable width encoding where you don't know what
the instruction operation is until the very last byte :-)
(Each byte is 4 bits of opcode and 4 bits of immediate
data; if you want a bigger immediate you use the PFIX and
NFIX instructions which shift-and-accumulate their 4 bit
immediate into the internal register that's building up the
immediate value that a subsequent 'real' insn uses.)

-- PMM

[Johnny Billquist]

Post by Peter Maydell

Post by John Levine
On the PDP-11 instructions were a sequence of 16 bit words and the
memory was 16 bit words (or later perhaps larger cache lines) so again
instruction decoding would have worked pretty much the same in either
byte order.

Did the PDP-11 read the whole 16-bit instruction as a single
memory access? (I'm guessing it did.) If you load the whole
instruction at once, as any modern fixed-width-instruction
CPU will, you can lay out the instruction fields in it
however you like, because you've already got all of them.

Basically all memory reads on a PDP-11 is always 16 bits (or more if you
have a larger cache line). If you did an instruction that only referred
to a byte, it still read the whole 16 bits. On writes, the memory could
handle 8-bit writes.

But also, instructions are always 16 bits, and they have to be word
aligned, so which byte order you'd have would make absolutely no difference.

Johnny

[Johnny Billquist]

Post by John Levine

Post by Peter Flass
I would think big-endian is best for instruction decoding. Leaving aside
issues of cache access, the processor can load the first byte to determine
the format (and hence length) of the rest of the instruction, unless the
architecture stores the opcode in the low-order byte and reads that first
in little-endian format.

Look at the x86. Its instruction format treats memory as a stream of
bytes. It is of course little-endian but its instruction format would
work about the same in big-endian.

Same on VAX. Instruction is just a byte, and that's the first byte.
Additional bytes are consumed as needed.

Post by John Levine
On the PDP-11 instructions were a sequence of 16 bit words and the
memory was 16 bit words (or later perhaps larger cache lines) so again
instruction decoding would have worked pretty much the same in either
byte order.

Yup. Cache lines on 11/70 is 32 bits. I think some other J11 based
machines also had a 32-bit cache line.

Johnny

[Scott Lurndal]

Post by Peter Flass

Post by Scott Lurndal

Post by John Levine

Post by Acceptable Name

Post by John Levine
I have never been able to figure out why DEC made the PDP-11
little-endian, when all previous byte addressed machines were big-endian.

I read somewhere that RISC-V is little endian because that was good for performance.

The PDP-11 was in 1969, RISC-V was four decades later in 2010 by which
time the endian wars had largely burned out.

I might argue that - big-endian processors are still available and
widely used in packet processing hardware such as DPUs. It's true that
most processors default to little-endian, but that's more because of the
ubiquity of x86 than anything else.

Post by John Levine
Data accesses in RISC-V are either endian set by a mode bit, code is
always little-endian. The manual claims that little-endian makes it
easier to look at instruction bits and see how long the instruction is
which I find unpersuasive.

They'd have to byte-swap the 32-bit instruction before decoding if they
accepted big-endian instructions or add a bunch of gates with
a dependency on the endianness bit in a control register. That
dependency would add complexity for OoO implementations.
Same for ARMv8 where the 32-bit instructions are always little-endian.
Makes sense, since the main
use for big-endian nowadays is to handle IP packets without byteswapping
and for processing data (e.g. interoperability). Doesn't
really make sense for the instruction stream to be big-endian.

I would think big-endian is best for instruction decoding.

Take a look at the encoding for the ARMv8 - there is no "first byte".
It's a 32-bit word that is not at all easy to decode manually[*].

RISCV does have the concept of an "opcode", which is the lowest
order 6 bits of the 32-bit instruction word, little-endian as it were.

One thing that software people don't generally appreciate is
the level of parallelism in a gate design - each bit in the
instruction word is a signal input to a combinational logic
circuit. Recall that the instruction must be decoded and all
the operands (registers, immediates) determined in a single
clock cycle.

All that said, there's no reason for the instruction stream
to be in any particular endedness. Note that Intel x86 instruction
stream is effectively little-endian as the first instruction
byte is the most significant byte (and often the only byte given
variable length instructions).

[*] Having written an ARMv8 simulator, I envy the hardware guys;
in software it is a sequence of check bit N, if set, check
bit N1, etc until one gets to the instruction group, then
one must decode the function and up to three register
numbers (5-bits each). The C++ code to decode to the
instruction group is about 1000 lines total (with comments),
not counting the decoding of each individual group.

if (!bit::test(instruction, 27))
{
/* 3322222222221111111111 */
/* 10987654321098765432109876543210 */
/* 0 */
if (!bit::test(instruction, 28))
{
/* 3322222222221111111111 */
/* 10987654321098765432109876543210 */
/* 00 */
if (bit::extract(instruction, 31, 21) != 0x1)
{
if (likely(bit::extract(instruction, 28, 25) == 0x2 && cpuState->is_sve_feature_enabled()))
{
/* 3322222222221111111111 */
/* 10987654321098765432109876543210 */
/* 0010 */
/* SVE - Scalable Vector Extension*/
return sve_decode(instruction, flags);
} else {
return instr_illegal(instruction, flags);
}
}
else
{
/* 3322222222221111111111 */
/* 10987654321098765432109876543210 */
/* 00000000001 */
return instr_illegal(instruction, flags);
}
}
...

Effectively, this is modeling the gates in a hardware design.

[Peter Maydell]

Post by Scott Lurndal
[*] Having written an ARMv8 simulator, I envy the hardware guys;
in software it is a sequence of check bit N, if set, check
bit N1, etc until one gets to the instruction group, then
one must decode the function and up to three register
numbers (5-bits each). The C++ code to decode to the
instruction group is about 1000 lines total (with comments),
not counting the decoding of each individual group.
if (!bit::test(instruction, 27))
{
/* 3322222222221111111111 */
/* 10987654321098765432109876543210 */
/* 0 */
if (!bit::test(instruction, 28))
{
/* 3322222222221111111111 */
/* 10987654321098765432109876543210 */
/* 00 */

Is this autogenerated code? For QEMU we ended up settling
on having a code-generator script that reads in instruction
patterns and spits out C code that does all the 'mask
bitfields, test bits, identify which insn this is' work.
It makes it a lot easier to modify to add new instructions
compared to a hand-rolled C decoder: the implementation is
still inevitably serial and sequential, but the human
representation the programmer edits is much closer to
a parallel no-interdependencies one. (Our aarch64 decoder
is still hand-rolled, but we will probably convert it at
some point.)

-- PMM

[Anne & Lynn Wheeler]

Post by Acceptable Name
Re: IBM being different, in the 1990s I learn Logical Volume Manager
(LVM). It was created during the time when OSF/1 was being written by
three-headed monster, IBM, HP and DEC. HP and IBM had essentially the
same commands with different names. IBM used varyonvg for what HP
called vgchange, etc.

... from long ago and far away ....

Date: Thu, 24 Mar 1988 11:46:54 CST
From: wheeler
Subject: system management;

Early rough draft on system management document has been updated on
proto disk. It is sja021 (and includes sja021a and sja006c). It
includes greatly expanded sections on install, logical volume manager,
and boot.

... snip ...

https://en.wikipedia.org/wiki/Logical_volume_management
above says IBM LVM w/AIXv3, 1989 and HP LVM with HP9.x
https://en.wikipedia.org/wiki/HP-UX
1992.

it was part of IBM Austin AIXv3 work for original RS/6000. AIXv3
filesystem also used RIOS (rs/6000 chipset) "transaction" memory
capturing filesystem metadata changes for logging. IBM Palo Alto then
redid filesystem logging purely in software and demo'ed it even ran faster
than transaction memory logging (on same system). IBM Palo Alto had
worked on UCLA LOCUS port
https://en.wikipedia.org/wiki/LOCUS
for AIX/370 and AIX/386
https://en.wikipedia.org/wiki/IBM_AIX#IBM_PS/2_series
https://en.wikipedia.org/wiki/IBM_AIX#AIX/370

... also offered to OS/1
https://en.wikipedia.org/wiki/Open_Software_Foundation
https://en.wikipedia.org/wiki/OSF/1

OSF/1 is a variant of the Unix operating system developed by the Open
Software Foundation during the late 1980s and early 1990s. OSF/1 is one
of the first operating systems to have used the Mach kernel developed at
Carnegie Mellon University, and is probably best known as the native
Unix operating system for DEC Alpha architecture systems.

[Acceptable Name]

Post by Anne & Lynn Wheeler

Post by Acceptable Name
Re: IBM being different, in the 1990s I learn Logical Volume Manager
(LVM). It was created during the time when OSF/1 was being written by
three-headed monster, IBM, HP and DEC. HP and IBM had essentially the
same commands with different names. IBM used varyonvg for what HP
called vgchange, etc.

... from long ago and far away ....
Date: Thu, 24 Mar 1988 11:46:54 CST
From: wheeler
Subject: system management;
Early rough draft on system management document has been updated on
proto disk. It is sja021 (and includes sja021a and sja006c). It
includes greatly expanded sections on install, logical volume manager,
and boot.
... snip ...
https://en.wikipedia.org/wiki/Logical_volume_management
above says IBM LVM w/AIXv3, 1989 and HP LVM with HP9.x
https://en.wikipedia.org/wiki/HP-UX
1992.

I'm really pressed for how to react the right way to this (i.e. "what is the nicest way to say this?"). Yes, I do accept that fact that I did not verify the exact dates and who had the original names and who had the second ones (if in fact the names were not created concurrently). Also the only running copy of OSF/1 (where IBM and HP were teaming) that I've used had AdvFS not LVM so I can't use that for any dates, although I might stumble across yet another copy.

But I do know a fair amount about the Wikipedia* and those article all have banners about numerous issues. The most relevant issue is neither of them have supporting citations for the dates of the versions in which a release of LVM was included, although the dates might be apparent (to someone) and factual. Aside from that, there is a difference between creating something and releasing it so there is a chance both companies did work together and one spent more time debugging before sending out to their customers.

Anyhow, thanks for pointing out to me that I could be thinking the HP acquired IBM's software and changed the command names.

* https://xtools.wmflabs.org/ec/en.wikipedia.org/Jamplevia (me)

[Johnny Billquist]

Post by John Levine
I have never been able to figure out why DEC made the PDP-11
little-endian, when all previous byte addressed machines were big-endian.
If you have a reference about why they did that, I would love to see
it because I have looked and found nothing. If you want to guess about
why, please don't, we've been through that a dozen times already.

What other byte addressable machines were there in 1969?

IBM 360, I assume. But do we have any others?

But disregarding previous machines, the obvious answer is that there is
less headache when wanting to refer to a value with different sizes. You
don't even have to guess about that one.

Johnny

[Scott Lurndal]

Post by Johnny Billquist

Post by John Levine
I have never been able to figure out why DEC made the PDP-11
little-endian, when all previous byte addressed machines were big-endian.
If you have a reference about why they did that, I would love to see
it because I have looked and found nothing. If you want to guess about
why, please don't, we've been through that a dozen times already.

What other byte addressable machines were there in 1969?

The Burroughs medium systems were -digit- addressable (and
thus also byte-addressable). They would have been considered
big-endian, as the most significant digit had the lowest
address - logical as they were BCD machines. Made for interesting
hardware algorithms to handle arithmetic starting from the
MSD position with operands of different lengths (1 to 100 units).

[John Levine]

Post by Johnny Billquist

Post by John Levine
I have never been able to figure out why DEC made the PDP-11
little-endian, when all previous byte addressed machines were big-endian.
If you have a reference about why they did that, I would love to see
it because I have looked and found nothing. If you want to guess about
why, please don't, we've been through that a dozen times already.

What other byte addressable machines were there in 1969?
IBM 360, I assume. But do we have any others?

The IBM Spectra 70 was a 360 semi-clone. Interdata had some
byte addressed minis. They were all big-endian.

Post by Johnny Billquist
But disregarding previous machines, the obvious answer is that there is
less headache when wanting to refer to a value with different sizes. You
don't even have to guess about that one.

I really wish people would stop guessing. None of the material about
the origin of the PDP-11 says anything like that, and when you look at
the screwed up middle-endian addressing of 32 bit numbers on later
models of the -11, it's quite clear that wasn't what they were
thinking.

[Bob Eager]

Post by John Levine

Post by Johnny Billquist

Post by John Levine
I have never been able to figure out why DEC made the PDP-11
little-endian, when all previous byte addressed machines were big-endian.
If you have a reference about why they did that, I would love to see
it because I have looked and found nothing. If you want to guess about
why, please don't, we've been through that a dozen times already.

What other byte addressable machines were there in 1969?
IBM 360, I assume. But do we have any others?

The IBM Spectra 70 was a 360 semi-clone.

And hence the Rnglish Electric System 4.

And from the early 1970s, the ICL 2900 series (later the 3900).
Big endian again.

[Rich Alderson]

Post by John Levine
The IBM Spectra 70 was a 360 semi-clone. Interdata had some
byte addressed minis. They were all big-endian.

s/IBM/RCA/g

[John Levine]

Post by Rich Alderson

Post by John Levine
The IBM Spectra 70 was a 360 semi-clone. Interdata had some
byte addressed minis. They were all big-endian.

s/IBM/RCA/g

Right, I can't type.

The user instruction set and data formats were the same as the 360 but the
supervisor and I/O were different. Needless to say, it was not a big hit.

[Johnny Billquist]

Post by John Levine

Post by Johnny Billquist

Post by John Levine
I have never been able to figure out why DEC made the PDP-11
little-endian, when all previous byte addressed machines were big-endian.
If you have a reference about why they did that, I would love to see
it because I have looked and found nothing. If you want to guess about
why, please don't, we've been through that a dozen times already.

What other byte addressable machines were there in 1969?
IBM 360, I assume. But do we have any others?

The IBM Spectra 70 was a 360 semi-clone. Interdata had some
byte addressed minis. They were all big-endian.

Before 1969? Hmm, maybe they did. Interdata was founded in 1966. They
must have had some product before 1970. Wikipedia claims their
architectures were based on the IBM 360. Never really used any
Interdata. Never liked them...

Post by John Levine

Post by Johnny Billquist
But disregarding previous machines, the obvious answer is that there is
less headache when wanting to refer to a value with different sizes. You
don't even have to guess about that one.

I really wish people would stop guessing. None of the material about
the origin of the PDP-11 says anything like that, and when you look at
the screwed up middle-endian addressing of 32 bit numbers on later
models of the -11, it's quite clear that wasn't what they were
thinking.

I am not guessing. And I know the middle-endian stuff as well. Not that
it has anything to do with this.
DEC hadn't really done something similar to the byte addressable thing
before the PDP-11. Noticeable is that the bit numbering on the PDP-11
was the opposite to what DEC had done on any machine before. Which does
make sense in a similar way. You now suddenly had that the weight of a
bit was 2^n where n was the bit number. On all previous machines, bits
had been numbered from right to left, and started with 1.

And on the PDP-11 you also had that the weight of a byte was 256^n,
where n was the offset from the "base" address. As well as if you
addressed a value, independent of if using a byte or a word instruction,
you got the same value, assuming the value wasn't larger than could be
held in a byte.

These are all facts. Now, did DEC have other/additional reasons? That I
don't know, and I won't try to speculate on it. But the above reasons
clearly exist. And the EIS 32-bit middle-endian things are not relevant
because they were not in the mind of the people who designed the initial
machine. We could have a separate discussion on why the engineers who
did the EIS decided to do the words big-endian. That would be a *really*
interesting question. A whole bunch of DEC software on the PDP-11 still
went little endian, even for 32-bit. So clearly there were disagreements
even inside DEC about that one.

Johnny

[Johnny Billquist]

Post by Johnny Billquist
I am not guessing. And I know the middle-endian stuff as well. Not that
it has anything to do with this.
DEC hadn't really done something similar to the byte addressable thing
before the PDP-11. Noticeable is that the bit numbering on the PDP-11
was the opposite to what DEC had done on any machine before. Which does
make sense in a similar way. You now suddenly had that the weight of a
bit was 2^n where n was the bit number. On all previous machines, bits
had been numbered from right to left, and started with 1.

Sigh. Numbered left to right I should have written. The PDP-11 numbers
the bits from right to left.

Johnny

[Lars Brinkhoff]

Post by Johnny Billquist

Post by Johnny Billquist
On all previous machines, bits
had been numbered from right to left, and started with 1.

Sigh. Numbered left to right I should have written.

On the PDP-6 and 10, the most significant bit is 0. Not 1.

[Johnny Billquist]

Post by Lars Brinkhoff

Post by Johnny Billquist

Post by Johnny Billquist
On all previous machines, bits
had been numbered from right to left, and started with 1.

Sigh. Numbered left to right I should have written.

On the PDP-6 and 10, the most significant bit is 0. Not 1.

I probably should have known/remembered that. Oh well. But they still
number bits from left to right.

The PDP8 (which I've used way more) numbered them from 1 to 12.

Johnny

[Anne & Lynn Wheeler]

Post by Johnny Billquist
Before 1969? Hmm, maybe they did. Interdata was founded in 1966. They
must have had some product before 1970. Wikipedia claims their
architectures were based on the IBM 360. Never really used any
Interdata. Never liked them...

up thread, my post about we built a 360 clone telecommunication using
interdata/3 (design/built channel interface board) ... which was
enhanced to interdata/4 for the channel interface and cluster of
interdata/3 for the port/line scanners.

[John Levine]

Post by Johnny Billquist

The RCA Spectra 70 was a 360 semi-clone. Interdata had some
byte addressed minis. They were all big-endian.

Before 1969?

Yes, the Internet Archive has a magazine ad for Interdata's early
machines from 1967.

Post by Johnny Billquist

I really wish people would stop guessing. None of the material about
the origin of the PDP-11 says anything like that, ...

I am not guessing.

Of course you're guessing. You weren't there, and neither you nor I
know what the people at DEC were thinking when they designed the
PDP-11. Everything you say about the -11 was equally true when IBM
designed the 360, and they made it big-endian.

For all we know, DEC's motivation could have been something short term
like it saved a couple of gates in the KA-11 and let them squeeze the
processor onto one less card.

[Johnny Billquist]

Post by John Levine

Post by Johnny Billquist

Post by John Levine
I really wish people would stop guessing. None of the material about
the origin of the PDP-11 says anything like that, ...

I am not guessing.

Of course you're guessing. You weren't there, and neither you nor I
know what the people at DEC were thinking when they designed the
PDP-11. Everything you say about the -11 was equally true when IBM
designed the 360, and they made it big-endian.

Am I guessing that the addressing is the same if you refer to a value as
a byte or a word gives the same value using the same address?

No. I am not.

Am I guessing that the value of a multibyte integer becomes 256^n where
n is the relative address of the byte from the base?

No. I am not.

Might DEC have had additional reasons? Maybe. But I'm not going to
speculate on that.

(Repeating what I wrote in the previous post. Maybe it gets through this
time? :-) )

Johnny

[John Levine]

Post by Johnny Billquist

Post by John Levine
Of course you're guessing. You weren't there, and neither you nor I
know what the people at DEC were thinking when they designed the
PDP-11. Everything you say about the -11 was equally true when IBM
designed the 360, and they made it big-endian.

Am I guessing that the addressing is the same if you refer to a value as
a byte or a word gives the same value using the same address?
No. I am not. ...

Hi. To repeat the part of my message you apparently didn't read, all
the stuff you say is true. It was equally true about the big-endian
IBM 360.

We have no idea whether any of it affected DEC's design of the PDP-11,
or for that matter, the design of the IBM 360. You're guessing.

If you have any actual info about why DEC did it backward from everyone
else, a lot of us would be delighted to see it. But guesses don't help.

R's,
John

[Johnny Billquist]

Post by John Levine

Post by Johnny Billquist

Post by John Levine
Of course you're guessing. You weren't there, and neither you nor I
know what the people at DEC were thinking when they designed the
PDP-11. Everything you say about the -11 was equally true when IBM
designed the 360, and they made it big-endian.

Am I guessing that the addressing is the same if you refer to a value as
a byte or a word gives the same value using the same address?
No. I am not. ...

Hi. To repeat the part of my message you apparently didn't read, all
the stuff you say is true. It was equally true about the big-endian
IBM 360.

No, it is not.

If you have a byte addressable machine, and you use big-endian order,
then the "weight" of a byte is *not* 256^n where n is the relative
address to the base of the word.

Post by John Levine
We have no idea whether any of it affected DEC's design of the PDP-11,
or for that matter, the design of the IBM 360. You're guessing.

Since it seems you didn't even get my points, maybe I should just stop here.
But I think it's bordering on the silly to assume they did not take my
points into consideration when doing the design.

The one potentially interesting question to which I don't have an answer
is if they had other/additional reasons.

Johnny

[John Levine]

Post by Johnny Billquist

Post by John Levine
Hi. To repeat the part of my message you apparently didn't read, all
the stuff you say is true. It was equally true about the big-endian
IBM 360.

No, it is not.
If you have a byte addressable machine, and you use big-endian order,
then the "weight" of a byte is *not* 256^n where n is the relative
address to the base of the word. ...

Hm, let me see if I can use simpler words. All the reasons to make
the PDP-11 little-endian were just as true in 1963 when IBM made the 360.
If they were a big deal, IBM would have done the 360 the other
way. But they did not. Either the 360 designers were incompetent,
which they were not, or those details weren't important.

Post by Johnny Billquist

Post by John Levine
We have no idea whether any of it affected DEC's design of the PDP-11,
or for that matter, the design of the IBM 360. You're guessing.

What I said. You can imagine that the 360 or PDP-11 designers
considered one argument or another, but they didn't say, neither of us
know, and it is sheer silliness to assume that you or anyone else know
what they were thinking.

[Acceptable Name]

Post by Johnny Billquist

Post by John Levine
Hi. To repeat the part of my message you apparently didn't read, all
the stuff you say is true. It was equally true about the big-endian
IBM 360.

No, it is not.
If you have a byte addressable machine, and you use big-endian order,
then the "weight" of a byte is *not* 256^n where n is the relative
address to the base of the word. ...

Hm, let me see if I can use simpler words. All the reasons to make
the PDP-11 little-endian were just as true in 1963 when IBM made the 360.
If they were a big deal, IBM would have done the 360 the other
way. But they did not. Either the 360 designers were incompetent,
which they were not, or those details weren't important.

Post by Johnny Billquist

Post by John Levine
We have no idea whether any of it affected DEC's design of the PDP-11,
or for that matter, the design of the IBM 360. You're guessing.

What I said. You can imagine that the 360 or PDP-11 designers
considered one argument or another, but they didn't say, neither of us
know, and it is sheer silliness to assume that you or anyone else know
what they were thinking.
--
Regards,
Please consider the environment before reading this e-mail. https://jl.ly

Bravo! Exquisite! I always dreamed of seeing a real USENET flame war in real time. Simply magnificent. I can see the reviews now. I wish USENET had a lobby so I could hand out cigars, bottles of fine wine and bouquets of flowers to all the cast.

[Lars Brinkhoff]

Post by Johnny Billquist
But I think it's bordering on the silly to assume they did not take my
points into consideration when doing the design.

Maybe I can clarify. I'm quite sure John Levine didn't write any such thing.
He did not make any assumption about what what points DEC designers
did *not* take into consideration. He also did not make any assumption about
what they *did* take into consideration. There is a third option: to not make
any assumption what DEC designers were thinking, beyond what can be
found in written records from the time.

[Johnny Billquist]

Post by Lars Brinkhoff

Post by Johnny Billquist
But I think it's bordering on the silly to assume they did not take my
points into consideration when doing the design.

Maybe I can clarify. I'm quite sure John Levine didn't write any such thing.
He did not make any assumption about what what points DEC designers
did *not* take into consideration. He also did not make any assumption about
what they *did* take into consideration. There is a third option: to not make
any assumption what DEC designers were thinking, beyond what can be
found in written records from the time.

I think some people are getting too obsessed about finding explicit
quotes. The facts that I pointed out are obvious and true as such.

To make the assumption that DEC didn't know these facts as well, and
took them into consideration when designing a completely new
architecture is silly, and would assume that DEC did hardware design off
the cuff like noone have ever seen.

So I think we can safely say that the two things I pointed out were most
certainly a part of the reason.

Now, if someone wants to be anal about it and say there is no proof that
they did consider these points, because there is no written record of
it, then so be it. Those same persons should perhaps also ask why DEC
decided to do a binary, and not, say, a trinary computer. Because you
won't find any explanation for choosing binary either. Did they then
just pick binary out of thin air, or was there some reason for that choice?

To bemuse people even more, here are some observations, and some written
document things for you:

The PDP-11, as we know it, came about in a very short time, very late in
the development. For the longest time, the PDP-11 looked *very*
different from what we know. As late as spring 1969, the proposed
architecture was so different that you cannot recognize any of it.
Instructions were 1 to 3 bytes in length, and could start at any
address. Single accumulator thing, with lots of special registers for
different purposes.

However, this earlier architecture (even marked as "final" and "no more
changes" in the sping of 1969) was also little endian.

And there are some potential reasons for this that you can see in the
instruction encoding. Memory reference instructions could be either two
or three bytes. Addresses 0 to FF were encoded with just a two byte
instruction. Basically a little similar to the zero page references in
the PDP-8. The instruction decoding figures out pretty late if this is
going to be an 8 bit or a 16 bit address. When decoding this, you start
stuffing the address bits from the instruction stream into Q (that's
what they call it in the documentation). Now, if you had used a
big-endian mode, this decoding becomes more complicated. Because if it
is a short address, addressing somewhere between 0 and FF, the
instruction stream decode stuff this in the low part of Q, and the high
part is set to 0. But if it is a long address of 16 bits, then the first
byte in the stream needs to go to the high byte of Q, and the next byte
after that needs to go to the low byte of Q.
This is obviously more messy, and makes the whole implementation more
complicated.

You can see this thing if you look at the 1969 design docs in
http://bitsavers.org/pdf/dec/pdp11/memos/.

Now, is that the full answer to why the PDP-11 is little-endian? No. It
is yet another piece of it. Even if this also isn't explicitly written
out. And also, the final PDP-11 have nothing in common with this design.
But it was a factor and input into the next design, which became what we
know as the PDP-11 today.

Most direct, obvious answer to "why was the PDP-11" little-endian could
be answered by "because the previous design for a machine called PDP-11
was little-endian". And that could be the end of the discussion. But of
course, we should examine why that previous design chose to be
little-endian. And here is one reason. Was this the only reason? Most
likely not.

I still don't know all the reasons, and I doubt we will find out. But
clearly there are some reasons we can see or deduce.

We could also try to see if Gordon Bell would be interested in giving
some answers. But he might not remember anymore, or might not have been
involved in that detail.

Johnny

[Peter Flass]

Post by Johnny Billquist

Post by Lars Brinkhoff

Post by Johnny Billquist
But I think it's bordering on the silly to assume they did not take my
points into consideration when doing the design.

Maybe I can clarify. I'm quite sure John Levine didn't write any such thing.
He did not make any assumption about what what points DEC designers
did *not* take into consideration. He also did not make any assumption about
what they *did* take into consideration. There is a third option: to not make
any assumption what DEC designers were thinking, beyond what can be
found in written records from the time.

I think some people are getting too obsessed about finding explicit
quotes. The facts that I pointed out are obvious and true as such.
To make the assumption that DEC didn't know these facts as well, and
took them into consideration when designing a completely new
architecture is silly, and would assume that DEC did hardware design off
the cuff like noone have ever seen.
So I think we can safely say that the two things I pointed out were most
certainly a part of the reason.
Now, if someone wants to be anal about it and say there is no proof that
they did consider these points, because there is no written record of
it, then so be it. Those same persons should perhaps also ask why DEC
decided to do a binary, and not, say, a trinary computer. Because you
won't find any explanation for choosing binary either. Did they then
just pick binary out of thin air, or was there some reason for that choice?
To bemuse people even more, here are some observations, and some written
The PDP-11, as we know it, came about in a very short time, very late in
the development. For the longest time, the PDP-11 looked *very*
different from what we know. As late as spring 1969, the proposed
architecture was so different that you cannot recognize any of it.
Instructions were 1 to 3 bytes in length, and could start at any
address. Single accumulator thing, with lots of special registers for
different purposes.
However, this earlier architecture (even marked as "final" and "no more
changes" in the sping of 1969) was also little endian.
And there are some potential reasons for this that you can see in the
instruction encoding. Memory reference instructions could be either two
or three bytes. Addresses 0 to FF were encoded with just a two byte
instruction. Basically a little similar to the zero page references in
the PDP-8. The instruction decoding figures out pretty late if this is
going to be an 8 bit or a 16 bit address. When decoding this, you start
stuffing the address bits from the instruction stream into Q (that's
what they call it in the documentation). Now, if you had used a
big-endian mode, this decoding becomes more complicated. Because if it
is a short address, addressing somewhere between 0 and FF, the
instruction stream decode stuff this in the low part of Q, and the high
part is set to 0. But if it is a long address of 16 bits, then the first
byte in the stream needs to go to the high byte of Q, and the next byte
after that needs to go to the low byte of Q.
This is obviously more messy, and makes the whole implementation more
complicated.
You can see this thing if you look at the 1969 design docs in
http://bitsavers.org/pdf/dec/pdp11/memos/.
Now, is that the full answer to why the PDP-11 is little-endian? No. It
is yet another piece of it. Even if this also isn't explicitly written
out. And also, the final PDP-11 have nothing in common with this design.
But it was a factor and input into the next design, which became what we
know as the PDP-11 today.
Most direct, obvious answer to "why was the PDP-11" little-endian could
be answered by "because the previous design for a machine called PDP-11
was little-endian". And that could be the end of the discussion. But of
course, we should examine why that previous design chose to be
little-endian. And here is one reason. Was this the only reason? Most
likely not.
I still don't know all the reasons, and I doubt we will find out. But
clearly there are some reasons we can see or deduce.
We could also try to see if Gordon Bell would be interested in giving
some answers. But he might not remember anymore, or might not have been
involved in that detail.
Johnny

Thanks! I didn’t know this.

[Quadibloc]

Post by John Levine
If you have any actual info about why DEC did it backward from everyone
else, a lot of us would be delighted to see it. But guesses don't help.

There doesn't appear to be any documentary information available.

But "guesses", based on the history of computing at that time, seem to
settle the issue well enough that there's no need to worry about it further.

Lots of 16-bit computers of that time, when they did a 32-bit add from
memory to accumulator, operated on quantities stored in memory with
the least-significant 16 bits first.

This was because it made the operation quicker - you could fetch and
add the least significant 16 bits, and then the carry was ready for when
the most significant bits were read in. (Other things, like addressing multi-word
objects by their location at the lowest address, and looping by incrementing,
rather than decrementing, the address were deeply-ingrained conventions.)

Usually, though, when they stored two characters in a 16-bit word, they
stored the first one in the most significant bits.

This meant a messy, inconsistent mapping of the characters of a four-character
string stored in a 32-bit number that no one would ever have used for a computer
with a 32-bit word.

So it is *obvious* why the PDP-11 was what it was. It allowed a _consistent_
ordering of characters stored in a 32-bit word, just as consistent in its own way
as the big-endian order of the IBM 360, but in a way that was suitable for 16-bit
hardware.

That the floating-point was then inconsistent - is obviously due to a failure of
communication in a world where big-endianness was the universal convention.
So this doesn't refute the hypothesis that consistency was the goal.

Documentary evidence would be nice, if it could ever be found, but what was
going on there is basically so *obvious* that I find it hard to understand why
you would feel any pressing need for it.

John Savard

[John Levine]

Post by Quadibloc

Post by John Levine
If you have any actual info about why DEC did it backward from everyone
else, a lot of us would be delighted to see it. But guesses don't help.

There doesn't appear to be any documentary information available.
But "guesses", based on the history of computing at that time, seem to
settle the issue well enough that there's no need to worry about it further.

Well, maybe. Over on comp.arch someone noted that Bitsavers has a
bunch of DEC memos from early 1969 that describe the evolving design
of the PDP-11. Until about the second week in March, the design was
sort of a byte addressed PDP-9, with a single accumulator and a byte
encoded instruction set that would have been easier to implement
little-endian. But by the end of the month it had turned into the
design they shipped, with 8 symmetrical registers, 16 bit datapaths
everywhere, and 16 bit instructions that would have worked equally
well in either byte order. (Don't argue about that last point unless
you actually programmed a PDP-11/20, /05, and /45 like I did.)

So it wasn't that it made the actual PDP-11 easier, it was that it
would have made an earlier paper design easier. There is nothing
explicit about why they chose the novel byte order beyond a comment in
someone's notes that the bits (not bytes) are numbered backwards. It's
not even clear if they knew their byte order was different from
previous byte addressed machines.

[Ahem A Rivet's Shot]

On Thu, 21 Apr 2022 14:34:12 -0700 (PDT)

Post by Quadibloc

Post by John Levine
If you have any actual info about why DEC did it backward from everyone
else, a lot of us would be delighted to see it. But guesses don't help.

There doesn't appear to be any documentary information available.

I would be astonished if there had been a single reason - there
never is for any major design decision IME. After the decision is made
someone *might* write down a convincing reason or two on a justification
document of some kind but that's always just an edited highlight of the
original far ranging (and unrecorded) discussions which cover every aspect
anyone involved can think of IME - and sometimes take place in a single
head.

[Peter Flass]

Post by John Levine

Post by Johnny Billquist

The RCA Spectra 70 was a 360 semi-clone. Interdata had some
byte addressed minis. They were all big-endian.

Before 1969?

Yes, the Internet Archive has a magazine ad for Interdata's early
machines from 1967.

Post by Johnny Billquist

I really wish people would stop guessing. None of the material about
the origin of the PDP-11 says anything like that, ...

I am not guessing.

Of course you're guessing. You weren't there, and neither you nor I
know what the people at DEC were thinking when they designed the
PDP-11. Everything you say about the -11 was equally true when IBM
designed the 360, and they made it big-endian.

IBM published a lot of material about what was going on with 360 design,
but I think all earlier computers were big-endian, so I suspect the issue
never came up. Little-endian was a screwball deviation.

Post by John Levine
For all we know, DEC's motivation could have been something short term
like it saved a couple of gates in the KA-11 and let them squeeze the
processor onto one less card.

[John Levine]

Post by Peter Flass

Post by John Levine
PDP-11. Everything you say about the -11 was equally true when IBM
designed the 360, and they made it big-endian.

IBM published a lot of material about what was going on with 360 design,
but I think all earlier computers were big-endian, so I suspect the issue
never came up.

The 360 was the first byte addressed machine. The earlier IBM
scientific machines were binary 36 bit word addressed (which explains
where the PDP-6, GE 635 and Univac 1100 came from) or decimal. Most of
the decimal machines were digit serial, other than the tube and drum
650 and the transistorized 7070 which were word addressed with 10
digit words. The small decimal scientific 1620 was digit addressed
with variable length numbers, in which an arithmetic instruction
addressed the low digit of the number which was at the highest
address, and it counted down to get the rest of the number, but some
other instructions and I/O addressed the leftmost digit or character
at the lowest address and counted up to get the rest of the record, so
I suppose that was more or less big-endian.

"Architecture of the IBM System/360" in the April 1964 IBM Journal of
R and D says a lot about their decision to use 8 rather than 6 bit
bytes (not totally obvious since characters then were six bits and
memory was expensive), ASCII vs EBCDIC, two's complement arithmetic,
binary registers rather than a stack, no decimal accumulators,
with decimal operand sizes given by a length in the instruction rather
than a field mark as in older machines. It also explains the mistaken
assumptions behind the hex floating point.

It says nothing whatsoever about byte order, other than implicitly in
a diagram about instruction formats and alignment. Evidently it seemed
obvious at the time.

Post by Peter Flass
Little-endian was a screwball deviation.

Indeed.

[Johnny Billquist]

Post by John Levine

Post by Peter Flass
Little-endian was a screwball deviation.

Indeed.

Indeed not. For the human brain, little-endian feels wrong. But from a
computer point of view, there are definitely things speaking for it.

Just as there are about designating the LSB as bit 0, and MSB as bit n,
and not the other way around. But older machines that that the other way
as well. Do you consider numbering bits with LSB as 0 as also being a
screwball deviation?

Johnny

[Peter Flass]

Post by John Levine

Post by Johnny Billquist

Post by John Levine
I have never been able to figure out why DEC made the PDP-11
little-endian, when all previous byte addressed machines were big-endian.
If you have a reference about why they did that, I would love to see
it because I have looked and found nothing. If you want to guess about
why, please don't, we've been through that a dozen times already.

What other byte addressable machines were there in 1969?
IBM 360, I assume. But do we have any others?

The IBM Spectra 70 was a 360 semi-clone. Interdata had some
byte addressed minis. They were all big-endian.

Univac 9x00, which were mostly 360/20 clones. I think NCRs were decimal
machines.

Post by John Levine

Post by Johnny Billquist
But disregarding previous machines, the obvious answer is that there is
less headache when wanting to refer to a value with different sizes. You
don't even have to guess about that one.

I really wish people would stop guessing. None of the material about
the origin of the PDP-11 says anything like that, and when you look at
the screwed up middle-endian addressing of 32 bit numbers on later
models of the -11, it's quite clear that wasn't what they were
thinking.

[Charlie Gibbs]

Post by Peter Flass

Post by John Levine
The IBM Spectra 70 was a 360 semi-clone. Interdata had some
byte addressed minis. They were all big-endian.

Univac 9x00, which were mostly 360/20 clones.

Well, the 9200/9300 anyway. The 9400 had 32-bit registers
and implemented a number of the 32-bit binary operations
(but not things like BXLE). I heard a rumour that the
90/30's non-privileged instruction set was an exact clone
of the 360/50, which is plausible in my experience.

[Ahem A Rivet's Shot]

On Sat, 09 Apr 2022 18:07:56 GMT

Post by Charlie Gibbs
And now we live in the era of Software as a Service (SaaS),
with ever-increasing numbers of mouse clicks required to
accomplish the same simple tasks...

Yep primarily because a rental business is easier to grow and
more predictable than a thing selling business and investors like that so
if the aim is to pull a fortune out of wall street by building a business
and going public then it wants to be a rental business and SaaS fits the
bill just fine.

The other thing is that underneath all those mouse clicks there's
often also an API which with a SMOP can be used to create a decent CLI or
just automate whatever you want doing completely.

[Bob Eager]

Post by John Levine
He was probably comparing it to the much more complex Multics.
CTSS and Unix both had a simple file system, typically one process
connected to each user console, and (at that time) no paging or other
stuff that unified memory and disk.
In the ensuing 45 years since he wrote that paper, Unix has gotten more
Multics-ish with paging and dynamic linking.

It even has the ability to map a file into memory, although it's a shadow
of the way Multics used that.

(confession: I was heavily involved with another system that had no other
way of accessing a file except by mapping it into virtual memory. It had
dynamic linking too. And that started out in the early 1970s too (the
dynamic linking came in the early 1980s).

[John Levine]

Post by Bob Eager

Post by John Levine
In the ensuing 45 years since he wrote that paper, Unix has gotten more
Multics-ish with paging and dynamic linking.

It even has the ability to map a file into memory, although it's a shadow
of the way Multics used that.

They way that Multics unified the file system and the process name
space and doing all inter-module (aka inter-segment) binding on the
fly was extremely clever and elegant, but in retrospect it was a brilliant
solution to the wrong problem.

The way that ELF shared libraries work on Unix or Linux systems isn't
unified with the file system (when you compile and link a program, the
linker makes a table of where to look for each library) but it
provides the practical benefits of everyone sharing the same copy of
each library and doing the file search part of the linking once when
you compile makes running programs a lot faster.

I never used Multics but I don't think they addressed the library version
problem known in the Windows world as DLL Hell. ELF took a very simple
approach of putting a version number on each library and bumping the major
version number when the calling sequence changed.

[Bob Eager]

Post by Bob Eager

Post by John Levine
In the ensuing 45 years since he wrote that paper, Unix has gotten
more Multics-ish with paging and dynamic linking.

It even has the ability to map a file into memory, although it's a
shadow of the way Multics used that.

They way that Multics unified the file system and the process name space
and doing all inter-module (aka inter-segment) binding on the fly was
extremely clever and elegant, but in retrospect it was a brilliant
solution to the wrong problem.
The way that ELF shared libraries work on Unix or Linux systems isn't
unified with the file system (when you compile and link a program, the
linker makes a table of where to look for each library) but it provides
the practical benefits of everyone sharing the same copy of each library
and doing the file search part of the linking once when you compile
makes running programs a lot faster.
I never used Multics but I don't think they addressed the library
version problem known in the Windows world as DLL Hell. ELF took a very
simple approach of putting a version number on each library and bumping
the major version number when the calling sequence changed.

The system I worked on did provide a way to do that, by registering the
library version you wanted to use. In extremis, you could bind a
particular library to an object file directly.

It never seemed to be a problem, and the sharing worked very well.
Mapping files meant that (effectively) processes also shared I/O buffers
(although there weren't actually any buffers at all, of course) because
they would share pages of files in memory.

The link loading thing did make loading slower, but it was pretty fasy
anyway (map the object file, create a temporary file for writeable data,
apply relocations). You could bind an object file to a particular virtual
address, which removed a step or two (and the relocation information was
retained in case that address was in use).

[Bob Eager]

Post by John Levine
The way that ELF shared libraries work on Unix or Linux systems isn't
unified with the file system (when you compile and link a program, the
linker makes a table of where to look for each library) but it provides
the practical benefits of everyone sharing the same copy of each library
and doing the file search part of the linking once when you compile
makes running programs a lot faster.

BTW, I have your book! (Linkers and Loaders).

[Anne & Lynn Wheeler]

Post by Acceptable Name
Ritchie, Dennis M. (1977). The Unix Time-sharing System: A
retrospective. Tenth Hawaii International Conference on the System
Sciences. "...a good case can be made that UNIX is in essence a modern
implementation of MIT’s CTSS system."
https://www.bell-labs.com/usr/dmr/www/retro.pdf
There's the citation. Why did he write that?

reference to unix, AT&T doing a simplified MULTICS
https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch02s01.html
Unix was born in 1969 out of the mind of a computer scientist at Bell
Laboratories, Ken Thompson. Thompson had been a researcher on the
Multics project, an experience which spoiled him for the primitive batch
computing that was the rule almost everywhere else. But the concept of
timesharing was still a novel one in the late 1960s; the first
speculations on it had been uttered barely ten years earlier by computer
scientist John McCarthy (also the inventor of the Lisp language), the
first actual deployment had been in 1962, seven years earlier, and
timesharing operating systems were still experimental and temperamental
beasts.

... snip ...

As I've mentioned several times, Some of the CTSS people
https://en.wikipedia.org/wiki/Compatible_Time-Sharing_System
went to the 5th flr, project mac, and MULTICS.
https://en.wikipedia.org/wiki/Multics
Others went to the 4th flr, IBM Cambridge Science Center, did virtual
machine CP40/CMS (on 360/40 with hardware mods for virtual memory,
morphs into CP67/CMS when 360/67 standard with virtual memory becomes
available)
https://en.wikipedia.org/wiki/CP/CMS
https://en.wikipedia.org/wiki/Conversational_Monitor_System

other drift, CMS as precursor to personal computing; before ms/dos
https://en.wikipedia.org/wiki/MS-DOS
there was Seattle computer
https://en.wikipedia.org/wiki/Seattle_Computer_Products
before Seattle computer, there was cp/m
https://en.wikipedia.org/wiki/CP/M
before developing cp/m, kildall worked on cp/67-cms at npg (gone 404,
but lives on at the wayback machine)
http://web.archive.org/web/20071011100440/http://www.khet.net/gmc/docs/museum/en_cpmName.html
npg
https://en.wikipedia.org/wiki/Naval_Postgraduate_School

This is story from MIT Urban Systems lab CP67 (across tech sq quad from
science center) had somebody down at Harvard wanted to use the system
with a ASCII device with 1200 length ... and made a change to maximum
length (but not my one byte fiddling) ... had 27 crashes in one day (all
before I graduated and left Boeing CFO office for the science center)
http://www.multicians.org/thvv/360-67.html
and some motivation for MULTICS doing new filesystem (because it
took so long for MULTICS to recover the filesystem after a crash,
compared to CP67 ... might be considered a little bit of rivalry
between 5th & 4th flrs)
https://www.multicians.org/nss.html

Three people came out to univ to install CP67 (3rd after CSC itself &
MIT Lincol Labs). Univ shutdown datacenter over the weekend and I had
the place dedicated ... although 48hrs w/o sleep made monday morning
classes hard. CP67 had 2741 & 1052 terminal support and some automagic
terminal identification code (using SAD ccw in 360 terminal controller
to switch line scanner type, trivia: when tty line scanner arrived at
univ for IBM engineers to install in terminal controller, it came in a
Heathkit box). Univ. had some ascii/TTY33&TTY35 terminals, so I added
ascii terminal support (including extending automagic terminal type for
tty, IBM picked up a lot of my CP67 rewrite and shipped it, including
tty support). However I done some fiddling with one byte length values
... the line length change that Van Vleck made at URBAN system lab for
ascii device down at harvard ... didn't catch the one byte fiddling.

later doing some work on UNIX in the 80s, found the (unix) scheduler
code looked a lot like original cp67 scheduler that I complete rewrote
as undergraduate in the 60s (assumed possibly common heritage back to
CTSS).

other trivia/background (comments on Van Vlecks article) in the morph of
CP67->VM370 they greatly simplified and/or dropped a lot of
feature/function ... including much of the code that I had done as
undergraduate in the 60s. IBM user group SHARE kept submitting
resolutions that IBM had my stuff back to VM370. After joining IBM, one
of my hobbies was enhanced production operating systems for internal
datacenters ... and got around to moving lots of the code from CP67 to
VM370 (for internal datacenters).

note, IBM 23June1969 unbundling announce started charging for
(application) software, SE services, maint., etc ... but IBM managed to
make the case that kernel software should still be free.

early 70s, IBM had future system project which was going to completely
replace 370 ... lot more info
http://www.jfsowa.com/computer/memo125.htm

internal politics was killing of 370 efforts (the lack of new 370
products during the period is credited with giving 370 clone makers
their market foothold). Then with the death of FS ... there was mad rush
to get stuff back into the 370 product pipelines (including kicking off
the quick&dirty 3033&3081 in parallel).

The other outcome (because of rise of 370 clones) was decision to start
charging for kernel software, starting with incremental addons (un the
transition to charging for all kernel software). Bunch of my vm370 stuff
(for internal datacenters, much of it originally in cp67) was selected
as guinea pig for charged-for kernel addon (and I had to spend a lot of
time with lawyers and business planners).

TSS comment trivia: Early 80s, AT&T had contracted with IBM to do a
stripped down TSS/370 (called SSUP) that AT&T would layer UNIX kernel
services on top of. Issue was customer mainframe hardware support
required lots of RAS & error reporting ... adding that level of RAS/EREP
to UNIX was many times larger than just porting unix to mainframe
... thus the decision to layer UNIX services on low-level TSS kernel
(providing the required RAS&EREP features). The other approach was
GOLD/UTS ... running it on VM370 in virtual machine ... with VM370
providing the necessary RAS&EREP features. Later IBM did something
similar with the port of UCLA's LOCUS (unix work alike) port to mainframe
as AIX/370 ... running it on VM370.

[Anne & Lynn Wheeler]

Post by Anne & Lynn Wheeler
Three people came out to univ to install CP67 (3rd after CSC itself &
MIT Lincol Labs). Univ shutdown datacenter over the weekend and I had
the place dedicated ... although 48hrs w/o sleep made monday morning
classes hard. CP67 had 2741 & 1052 terminal support and some automagic
terminal identification code (using SAD ccw in 360 terminal controller
to switch line scanner type, trivia: when tty line scanner arrived at
univ for IBM engineers to install in terminal controller, it came in a
Heathkit box). Univ. had some ascii/TTY33&TTY35 terminals, so I added
ascii terminal support (including extending automagic terminal type for
tty

I also wanted to have single dial-in number for all terminals ... hunt group
https://en.wikipedia.org/wiki/Line_hunting

Didn't quite work since I could switch line scanner for each port (on
IBM telecommunication controller), IBM had took short cut and hard wired
line speed for each port (TTY was different line speed from
2741&1052). Thus was born univ. project to do a clone controller, built
a mainframe channel interface board for Interdata/3 programmed to
emulate mainframe telecommunication controller with the addition it
could also do dynamic line speed determination. Later it was enhanced
with Interdata/4 for the channel interface and cluster of Interdata/3s
for the port interfaces. Interdata (and later Perkin/Elmer) sell it
commercially as IBM clone controller. Four of us at the univ. get
written up responsible for (some part of the) clone controller business.
https://en.wikipedia.org/wiki/Interdata
https://en.wikipedia.org/wiki/Perkin-Elmer

around turn of the century ran into one of the descendants of the box
handling majority of the credit card point-of-sale dialup terminals
(east of the mississippi) ... some claim that it still used our original
channel interface board design.

IBM Future System trivia: major motivation for FS was countermeasure to
clone controllers ... make interface so complex that clone makers
couldn't keep up (as it turned out so complex that even IBM wasn't
successful) ... but from the law of unintended consequences, clone
controllers gave rise to FS ... and IBM FS politics killing off 370
efforts, give rise to clone 370s (getting market foothold).

[Acceptable Name]

Post by Anne & Lynn Wheeler

Post by Anne & Lynn Wheeler
Three people came out to univ to install CP67 (3rd after CSC itself &
MIT Lincol Labs). Univ shutdown datacenter over the weekend and I had
the place dedicated ... although 48hrs w/o sleep made monday morning
classes hard. CP67 had 2741 & 1052 terminal support and some automagic
terminal identification code (using SAD ccw in 360 terminal controller
to switch line scanner type, trivia: when tty line scanner arrived at
univ for IBM engineers to install in terminal controller, it came in a
Heathkit box). Univ. had some ascii/TTY33&TTY35 terminals, so I added
ascii terminal support (including extending automagic terminal type for
tty

I also wanted to have single dial-in number for all terminals ... hunt group
https://en.wikipedia.org/wiki/Line_hunting
Didn't quite work since I could switch line scanner for each port (on
IBM telecommunication controller), IBM had took short cut and hard wired
line speed for each port (TTY was different line speed from
2741&1052). Thus was born univ. project to do a clone controller, built
a mainframe channel interface board for Interdata/3 programmed to
emulate mainframe telecommunication controller with the addition it
could also do dynamic line speed determination. Later it was enhanced
with Interdata/4 for the channel interface and cluster of Interdata/3s
for the port interfaces. Interdata (and later Perkin/Elmer) sell it
commercially as IBM clone controller. Four of us at the univ. get
written up responsible for (some part of the) clone controller business.
https://en.wikipedia.org/wiki/Interdata
https://en.wikipedia.org/wiki/Perkin-Elmer
around turn of the century ran into one of the descendants of the box
handling majority of the credit card point-of-sale dialup terminals
(east of the mississippi) ... some claim that it still used our original
channel interface board design.
IBM Future System trivia: major motivation for FS was countermeasure to
clone controllers ... make interface so complex that clone makers
couldn't keep up (as it turned out so complex that even IBM wasn't
successful) ... but from the law of unintended consequences, clone
controllers gave rise to FS ... and IBM FS politics killing off 370
efforts, give rise to clone 370s (getting market foothold).
--
virtualization experience starting Jan1968, online at home since Mar1970

Thanks, this helped me. I was able to locate a video of Corbato explaining how CTSS was built out of polished ideas, not experiments like Multics. UNIX was the same way. DMR's paper uses the word "conservative" in his comparison of UNIX and CTSS showing how UNIX was also built from ideas that were not high risk. As an example, it took four years just to get a working PL/1 compiler for Multics while CTSS and UNIX just used assembler, etc. See

for Corbato's talk.