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

313 views
Skip to first unread message

Acceptable Name

unread,
Apr 6, 2022, 9:30:10 AMApr 6
to
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

unread,
Apr 6, 2022, 12:39:23 PMApr 6
to
According to Acceptable Name <metta....@gmail.com>:
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.

--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Acceptable Name

unread,
Apr 6, 2022, 1:18:48 PMApr 6
to
On Wednesday, April 6, 2022 at 12:39:23 PM UTC-4, John Levine wrote:
> According to Acceptable Name <metta....@gmail.com>:
> >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.

Anne & Lynn Wheeler

unread,
Apr 6, 2022, 1:38:16 PMApr 6
to
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.

--
virtualization experience starting Jan1968, online at home since Mar1970

Anne & Lynn Wheeler

unread,
Apr 6, 2022, 1:50:04 PMApr 6
to
Anne & Lynn Wheeler <ly...@garlic.com> writes:
> 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

unread,
Apr 7, 2022, 8:53:24 AMApr 7
to
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 https://www.youtube.com/watch?v=KZPYBDA6XVo for Corbato's talk.

Peter Flass

unread,
Apr 7, 2022, 3:29:40 PMApr 7
to
John Levine <jo...@taugh.com> wrote:
> According to Acceptable Name <metta....@gmail.com>:
>> 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

Bob Eager

unread,
Apr 7, 2022, 5:15:38 PMApr 7
to
On Wed, 06 Apr 2022 16:39:21 +0000, John Levine wrote:

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



--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

John Levine

unread,
Apr 7, 2022, 8:27:18 PMApr 7
to
According to Bob Eager <news...@eager.cx>:
>> 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

unread,
Apr 8, 2022, 3:58:22 AMApr 8
to
On Fri, 08 Apr 2022 00:27:16 +0000, John Levine wrote:

> According to Bob Eager <news...@eager.cx>:
>>> 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

unread,
Apr 8, 2022, 4:00:51 AMApr 8
to
On Fri, 08 Apr 2022 00:27:16 +0000, John Levine wrote:

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

Acceptable Name

unread,
Apr 8, 2022, 7:10:40 AMApr 8
to
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

unread,
Apr 8, 2022, 7:19:30 AMApr 8
to
Acceptable Name wrote:
> 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

unread,
Apr 8, 2022, 7:23:19 AMApr 8
to
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

unread,
Apr 8, 2022, 8:02:17 AMApr 8
to
Acceptable Name wrote:
> 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

unread,
Apr 8, 2022, 8:43:21 AMApr 8
to
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

unread,
Apr 8, 2022, 8:51:40 AMApr 8
to
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?

Adam Sampson

unread,
Apr 8, 2022, 10:30:05 AMApr 8
to
Acceptable Name <metta....@gmail.com> writes:

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

--
Adam Sampson <a...@offog.org> <http://offog.org/>

Lars Brinkhoff

unread,
Apr 8, 2022, 11:45:07 AMApr 8
to
Acceptable Name wrote:
> 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.

Anne & Lynn Wheeler

unread,
Apr 8, 2022, 2:32:41 PMApr 8
to
Acceptable Name <metta....@gmail.com> writes:
> 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.

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

unread,
Apr 9, 2022, 5:45:00 AMApr 9
to
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,

Acceptable Name

unread,
Apr 9, 2022, 6:16:14 AMApr 9
to
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.

https://www.youtube.com/watch?v=MnZ2kqaChwU&t=288s

Charlie Gibbs

unread,
Apr 9, 2022, 2:07:58 PMApr 9
to
On 2022-04-09, Acceptable Name <metta....@gmail.com> wrote:

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

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

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgi...@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

Peter Flass

unread,
Apr 9, 2022, 3:00:25 PMApr 9
to
There are only so many characters that can be used fir delimiters, or for
line editing.

--
Pete

Peter Flass

unread,
Apr 9, 2022, 3:00:26 PMApr 9
to
Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
> On 2022-04-09, Acceptable Name <metta....@gmail.com> wrote:
>
>> 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.

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

--
Pete

Acceptable Name

unread,
Apr 9, 2022, 3:38:57 PMApr 9
to
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.

John Levine

unread,
Apr 9, 2022, 4:29:48 PMApr 9
to
According to Peter Flass <peter...@yahoo.com>:
>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.

Ahem A Rivet's Shot

unread,
Apr 9, 2022, 4:30:02 PMApr 9
to
On Sat, 09 Apr 2022 18:07:56 GMT
Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:

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

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

Acceptable Name

unread,
Apr 9, 2022, 4:41:40 PMApr 9
to
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

unread,
Apr 9, 2022, 6:08:27 PMApr 9
to
According to Acceptable Name <metta....@gmail.com>:
>> 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.

Anne & Lynn Wheeler

unread,
Apr 9, 2022, 7:19:29 PMApr 9
to
Acceptable Name <metta....@gmail.com> writes:
> 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.

Bob Eager

unread,
Apr 9, 2022, 7:25:06 PMApr 9
to
On Fri, 08 Apr 2022 15:24:42 +0100, Adam Sampson wrote:

> Acceptable Name <metta....@gmail.com> writes:
>
>> (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!

Johnny Billquist

unread,
Apr 10, 2022, 7:16:11 AMApr 10
to
On 2022-04-09 22:29, John Levine wrote:
> 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

Acceptable Name

unread,
Apr 10, 2022, 8:17:07 AMApr 10
to
On Saturday, April 9, 2022 at 7:19:29 PM UTC-4, ly...@garlic.com wrote:
> Acceptable Name <metta....@gmail.com> writes:
> > 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)

Scott Lurndal

unread,
Apr 10, 2022, 10:24:47 AMApr 10
to
Johnny Billquist <b...@softjar.se> writes:
>On 2022-04-09 22:29, John Levine wrote:
>> 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).


Scott Lurndal

unread,
Apr 10, 2022, 11:36:20 AMApr 10
to
John Levine <jo...@taugh.com> writes:
>According to Acceptable Name <metta....@gmail.com>:
>>> 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.

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

unread,
Apr 10, 2022, 6:11:15 PMApr 10
to
According to Scott Lurndal <sl...@pacbell.net>:
>>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.

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

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

John Levine

unread,
Apr 10, 2022, 6:36:22 PMApr 10
to
According to Johnny Billquist <b...@softjar.se>:
>On 2022-04-09 22:29, John Levine wrote:
>> 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.

>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

unread,
Apr 10, 2022, 7:14:15 PMApr 10
to
On Sun, 10 Apr 2022 22:36:20 +0000, John Levine wrote:

> According to Johnny Billquist <b...@softjar.se>:
>>On 2022-04-09 22:29, John Levine wrote:
>>> 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

unread,
Apr 10, 2022, 8:35:09 PMApr 10
to
John Levine <jo...@taugh.com> writes:

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

s/IBM/RCA/g

--
Rich Alderson ne...@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

Peter Maydell

unread,
Apr 11, 2022, 3:20:59 AMApr 11
to
In article <t2vkm1$316h$1...@gal.iecc.com>, John Levine <jo...@taugh.com> wrote:
>According to Scott Lurndal <sl...@pacbell.net>:
>>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

unread,
Apr 11, 2022, 4:30:03 AMApr 11
to
On 11 Apr 2022 08:20:56 +0100 (BST)
pmay...@chiark.greenend.org.uk (Peter Maydell) wrote:

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

Johnny Billquist

unread,
Apr 11, 2022, 4:58:38 AMApr 11
to
On 2022-04-11 00:36, John Levine wrote:
> According to Johnny Billquist <b...@softjar.se>:
>> On 2022-04-09 22:29, John Levine wrote:
>>> 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...

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

unread,
Apr 11, 2022, 9:01:22 AMApr 11
to
On 2022-04-11 10:58, Johnny Billquist wrote:
>
> 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

unread,
Apr 11, 2022, 9:23:10 AMApr 11
to
Johnny Billquist wrote:
> > 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.

Scott Lurndal

unread,
Apr 11, 2022, 10:41:01 AMApr 11
to
Ahem A Rivet's Shot <ste...@eircom.net> writes:
>On 11 Apr 2022 08:20:56 +0100 (BST)
>pmay...@chiark.greenend.org.uk (Peter Maydell) wrote:
>
>> 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

Anne & Lynn Wheeler

unread,
Apr 11, 2022, 2:22:59 PMApr 11
to
Johnny Billquist <b...@softjar.se> writes:
> 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

unread,
Apr 11, 2022, 5:22:56 PMApr 11
to
According to Peter Maydell <pmay...@chiark.greenend.org.uk>:
>>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.

John Levine

unread,
Apr 11, 2022, 5:24:29 PMApr 11
to
According to Rich Alderson <ne...@alderson.users.panix.com>:
>John Levine <jo...@taugh.com> writes:
>
>> 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.

John Levine

unread,
Apr 11, 2022, 5:41:36 PMApr 11
to
According to Johnny Billquist <b...@softjar.se>:
>> 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.

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

unread,
Apr 12, 2022, 3:04:29 AMApr 12
to
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

Johnny Billquist

unread,
Apr 12, 2022, 3:07:25 AMApr 12
to
On 2022-04-11 23:41, John Levine wrote:
> According to Johnny Billquist <b...@softjar.se>:
>>> 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

Johnny Billquist

unread,
Apr 12, 2022, 3:13:46 AMApr 12
to
On 2022-04-11 23:22, John Levine wrote:
> According to Peter Maydell <pmay...@chiark.greenend.org.uk>:
>>> 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.

> 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

Peter Maydell

unread,
Apr 12, 2022, 4:26:08 AMApr 12
to
In article <t3267e$2ke5$1...@gal.iecc.com>, John Levine <jo...@taugh.com> wrote:
>According to Peter Maydell <pmay...@chiark.greenend.org.uk>:
>>>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

Scott Lurndal

unread,
Apr 12, 2022, 9:56:48 AMApr 12
to
Johnny Billquist <b...@softjar.se> writes:
>On 2022-04-11 23:22, John Levine wrote:
>> According to Peter Maydell <pmay...@chiark.greenend.org.uk>:
>>>> 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.

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

unread,
Apr 12, 2022, 10:30:03 AMApr 12
to
On Tue, 12 Apr 2022 13:56:45 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:

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

Andy Leighton

unread,
Apr 12, 2022, 12:09:09 PMApr 12
to
On Tue, 12 Apr 2022 13:56:45 GMT, Scott Lurndal <sc...@slp53.sl.home> wrote:
> Johnny Billquist <b...@softjar.se> writes:
>>On 2022-04-11 23:22, John Levine wrote:
>>> According to Peter Maydell <pmay...@chiark.greenend.org.uk>:
>>>>> 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.

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

--
Andy Leighton => an...@azaal.plus.com
"We demand rigidly defined areas of doubt and uncertainty!"
- Douglas Adams

Dan Espen

unread,
Apr 12, 2022, 12:39:55 PMApr 12
to
Andy Leighton <an...@azaal.plus.com> writes:

> On Tue, 12 Apr 2022 13:56:45 GMT, Scott Lurndal <sc...@slp53.sl.home> wrote:
>> Johnny Billquist <b...@softjar.se> writes:
>>>On 2022-04-11 23:22, John Levine wrote:
>> 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.

--
Dan Espen

Chris Adams

unread,
Apr 12, 2022, 1:22:58 PMApr 12
</