Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Computer Folklore » Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS?
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413868] Wed, 06 April 2022 09:30 Go to next message
Anonymous
Karma:
Originally posted 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?
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413870 is a reply to message #413868] Wed, 06 April 2022 12:39 Go to previous messageGo to next message
John Levine is currently offline  John Levine
Messages: 1405
Registered: December 2011
Karma: 0
Senior Member
According to Acceptable Name <metta.crawler@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.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413871 is a reply to message #413870] Wed, 06 April 2022 13:18 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Acceptable Name

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.

> 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
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413872 is a reply to message #413868] Wed, 06 April 2022 13:38 Go to previous messageGo to next message
Anne &amp; Lynn Wheel is currently offline  Anne &amp; Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
Senior Member
Acceptable Name <metta.crawler@gmail.com> writes:
> 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/ch02s 01.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.ne t/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
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413873 is a reply to message #413872] Wed, 06 April 2022 13:50 Go to previous messageGo to next message
Anne &amp; Lynn Wheel is currently offline  Anne &amp; Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
Senior Member
Anne & Lynn Wheeler <lynn@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).

--
virtualization experience starting Jan1968, online at home since Mar1970
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413880 is a reply to message #413873] Thu, 07 April 2022 08:53 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Acceptable Name

On Wednesday, April 6, 2022 at 1:50:04 PM UTC-4, ly...@garlic.com wrote:
> 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).
> --
> 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 https://www.youtube.com/watch?v=KZPYBDA6XVo for Corbato's talk.
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413886 is a reply to message #413870] Thu, 07 April 2022 15:29 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
John Levine <johnl@taugh.com> wrote:
> According to Acceptable Name <metta.crawler@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
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413890 is a reply to message #413870] Thu, 07 April 2022 17:15 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Bob Eager

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
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413897 is a reply to message #413890] Thu, 07 April 2022 20:27 Go to previous messageGo to next message
John Levine is currently offline  John Levine
Messages: 1405
Registered: December 2011
Karma: 0
Senior Member
According to Bob Eager <news0009@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.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413903 is a reply to message #413897] Fri, 08 April 2022 03:58 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Bob Eager

On Fri, 08 Apr 2022 00:27:16 +0000, John Levine wrote:

> According to Bob Eager <news0009@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).


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

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413904 is a reply to message #413897] Fri, 08 April 2022 04:00 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Bob Eager

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

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

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413905 is a reply to message #413886] Fri, 08 April 2022 07:10 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Acceptable Name

On Thursday, April 7, 2022 at 3:29:40 PM UTC-4, Peter Flass wrote:
> 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

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
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413906 is a reply to message #413905] Fri, 08 April 2022 07:19 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Lars Brinkhoff

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?
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413907 is a reply to message #413906] Fri, 08 April 2022 07:23 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Acceptable Name

On Friday, April 8, 2022 at 7:19:30 AM UTC-4, lars.br...@gmail.com wrote:
> 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?

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".
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413908 is a reply to message #413907] Fri, 08 April 2022 08:02 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Lars Brinkhoff

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"
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413909 is a reply to message #413908] Fri, 08 April 2022 08:43 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Acceptable Name

On Friday, April 8, 2022 at 8:02:17 AM UTC-4, lars.br...@gmail.com wrote:
> 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"

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.
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413910 is a reply to message #413909] Fri, 08 April 2022 08:51 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Acceptable Name

On Friday, April 8, 2022 at 8:43:21 AM UTC-4, Acceptable Name wrote:
> On Friday, April 8, 2022 at 8:02:17 AM UTC-4, lars.br...@gmail.com wrote:
>> 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"
> 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?
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413912 is a reply to message #413905] Fri, 08 April 2022 10:24 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Adam Sampson

Acceptable Name <metta.crawler@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_Dec6 9.pdf

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

--
Adam Sampson <ats@offog.org> <http://offog.org/>
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413913 is a reply to message #413910] Fri, 08 April 2022 11:45 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Lars Brinkhoff

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.
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413916 is a reply to message #413905] Fri, 08 April 2022 14:32 Go to previous messageGo to next message
Anne &amp; Lynn Wheel is currently offline  Anne &amp; Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
Senior Member
Acceptable Name <metta.crawler@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_Communicat ion_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.bobbem er.com/P-BIT.HTM
https://web.archive.org/web/20180402200104/http://www.bobbem er.com/ASCII.HTM
https://web.archive.org/web/20180402194530/http://www.bobbem er.com/FATHEROF.HTM
https://web.archive.org/web/20180402200149/http://www.bobbem er.com/HISTORY.HTM

--
virtualization experience starting Jan1968, online at home since Mar1970
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413927 is a reply to message #413912] Sat, 09 April 2022 05:44 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Acceptable Name

On Friday, April 8, 2022 at 10:30:05 AM UTC-4, 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_Dec6 9.pdf
>
> (The Multics manuals and info segments don't seem quite so similar to
> me...)
>
> --
> Adam Sampson <a...@offog.org> <http://offog.org/>

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,
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413929 is a reply to message #413916] Sat, 09 April 2022 06:16 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Acceptable Name

On Friday, April 8, 2022 at 2:32:41 PM UTC-4, ly...@garlic.com wrote:
> 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_Communicat ion_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.bobbem er.com/P-BIT.HTM
> https://web.archive.org/web/20180402200104/http://www.bobbem er.com/ASCII.HTM
> https://web.archive.org/web/20180402194530/http://www.bobbem er.com/FATHEROF.HTM
> https://web.archive.org/web/20180402200149/http://www.bobbem er.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.

https://www.youtube.com/watch?v=MnZ2kqaChwU&t=288s
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413933 is a reply to message #413929] Sat, 09 April 2022 14:07 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
On 2022-04-09, Acceptable Name <metta.crawler@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.
\ / <cgibbs@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.
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413936 is a reply to message #413927] Sat, 09 April 2022 15:00 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
Acceptable Name <metta.crawler@gmail.com> wrote:
> On Friday, April 8, 2022 at 10:30:05 AM UTC-4, 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_Dec6 9.pdf
>>
>> (The Multics manuals and info segments don't seem quite so similar to
>> me...)
>>
>> --
>> Adam Sampson <a...@offog.org> <http://offog.org/>
>
> 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,
>
>

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

--
Pete
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413937 is a reply to message #413933] Sat, 09 April 2022 15:00 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2022-04-09, Acceptable Name <metta.crawler@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
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413938 is a reply to message #413936] Sat, 09 April 2022 15:38 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Acceptable Name

On Saturday, April 9, 2022 at 3:00:25 PM UTC-4, Peter Flass wrote:
> Acceptable Name <metta....@gmail.com> wrote:
>> On Friday, April 8, 2022 at 10:30:05 AM UTC-4, 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_Dec6 9.pdf
>>>
>>> (The Multics manuals and info segments don't seem quite so similar to
>>> me...)
>>>
>>> --
>>> Adam Sampson <a...@offog.org> <http://offog.org/>
>>
>> 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,
>>
>>
> 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.
Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413939 is a reply to message #413937] Sat, 09 April 2022 16:29 Go to previous messageGo to next message
John Levine is currently offline  John Levine
Messages: 1405
Registered: December 2011
Karma: 0
Senior Member
According to Peter Flass <peter_flass@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.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413940 is a reply to message #413933] Sat, 09 April 2022 16:29 Go to previous messageGo to next message
Ahem A Rivet's Shot is currently offline  Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
Senior Member
On Sat, 09 Apr 2022 18:07:56 GMT
Charlie Gibbs <cgibbs@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/
Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413941 is a reply to message #413939] Sat, 09 April 2022 16:41 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Acceptable Name

On Saturday, April 9, 2022 at 4:29:48 PM UTC-4, John Levine wrote:
> 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.
> --
> 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

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.
Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413943 is a reply to message #413941] Sat, 09 April 2022 18:08 Go to previous messageGo to next message
John Levine is currently offline  John Levine
Messages: 1405
Registered: December 2011
Karma: 0
Senior Member
According to Acceptable Name <metta.crawler@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.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413944 is a reply to message #413941] Sat, 09 April 2022 19:19 Go to previous messageGo to next message
Anne &amp; Lynn Wheel is currently offline  Anne &amp; Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
Senior Member
Acceptable Name <metta.crawler@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.

--
virtualization experience starting Jan1968, online at home since Mar1970
Re: Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413945 is a reply to message #413912] Sat, 09 April 2022 19:25 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Bob Eager

On Fri, 08 Apr 2022 15:24:42 +0100, Adam Sampson wrote:

> Acceptable Name <metta.crawler@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_Dec6 9.pdf
>
> (The Multics manuals and info segments don't seem quite so similar to
> me...)

Interesting!

And ... Hi, Adam!



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

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413947 is a reply to message #413939] Sun, 10 April 2022 07:16 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Johnny Billquist

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
Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413948 is a reply to message #413944] Sun, 10 April 2022 08:17 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Acceptable Name

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)
Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413950 is a reply to message #413947] Sun, 10 April 2022 10:24 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
Johnny Billquist <bqt@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).
Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413951 is a reply to message #413943] Sun, 10 April 2022 11:36 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
John Levine <johnl@taugh.com> writes:
> According to Acceptable Name <metta.crawler@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.
Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413953 is a reply to message #413951] Sun, 10 April 2022 18:11 Go to previous messageGo to next message
John Levine is currently offline  John Levine
Messages: 1405
Registered: December 2011
Karma: 0
Senior Member
According to Scott Lurndal <slp53@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.



--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413955 is a reply to message #413947] Sun, 10 April 2022 18:36 Go to previous messageGo to next message
John Levine is currently offline  John Levine
Messages: 1405
Registered: December 2011
Karma: 0
Senior Member
According to Johnny Billquist <bqt@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.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413956 is a reply to message #413955] Sun, 10 April 2022 19:14 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Bob Eager

On Sun, 10 Apr 2022 22:36:20 +0000, John Levine wrote:

> According to Johnny Billquist <bqt@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.

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

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413957 is a reply to message #413955] Sun, 10 April 2022 20:35 Go to previous messageGo to previous message
Rich Alderson is currently offline  Rich Alderson
Messages: 489
Registered: August 2012
Karma: 0
Senior Member
John Levine <johnl@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 news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
Pages (4): [1  2  3  4    »]  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS?
Next Topic: Re: CDC Hawk Disk Drive
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 13:50:55 EDT 2024

Total time taken to generate the page: 0.22000 seconds