Talk:TOPS-20

Tenex/ARPANet

I removed the following from the article:

By the early 1970s, almost all of the systems on the ARPANET ran TENEX.

This is not my memory, and it is not what is shown by the logical maps of the Arpanet from the early 1970s. True, the PDP-10 was a popular system on the Arpanet -- at its peak, it probably represented half the machines. And Tenex was probably the majority OS on those systems—though MIT ran ITS (3 machines) and Harvard ran TOPS-10 (1 machine). But that is far from "almost all". As for the late 1970's, RFC 752 has a census of Arpanet hosts in 1979, with information on OS's. About 30% are PDP-10s. True, 81% of those ran Tenex, but that's only 25% of the total. --Macrakis 22:45, 4 Apr 2005 (UTC)

Maybe put it back in as:

By the early 1970s, almost all of the PDP-10 systems on the ARPANET ran TENEX.

which is (as you point out above) perfectly true! Noel (talk) 14:39, 13 Apr 2005 (UTC)

Tenex/TOPS-20

I think TENEX and TOPS-20 deserve separate articles, rather than one giant article which covers them both. The development environment, goals, etc of the two were sufficiently different that there's really not that much overlap between the two, and the TOPS-20 article can simply refer back to the TENEX article. Noel (talk) 14:43, 13 Apr 2005 (UTC)

TOPS-10 / TOPS-20

Re "was preferred by most PDP-10 hackers over TOPS-10", my recollection was that there was a lively, ongoing dialog. I am not sure that the situation was as settled as this indicates (at least by the time that the Jupiter project was canceled). I personally found TOPS-20 more elegant, but for several practical reasons we stayed with TOPS-10 for our principal environment. It is possible that a warmer glow of nostalgia has settled over TOPS-20. I would rather read "was preferred by many PDP-10 hackers over TOPS-10...". Jim 17:58, 12 January 2006 (UTC)

Features

There ought to be some discription of features provided by TOPS-20, most notably command line completion, which was a pretty advanced thing for command interpreters (shells) back then. — Loadmaster 16:02, 6 July 2007 (UTC)

cf. Command_line_completion#History -- Tenex adopted command line completion from the SDS-940 timesharing system, and TOPS-20 continued that. --macrakis (talk) 18:22, 13 January 2009 (UTC)

Virtual memory

From the article, "Known as the DECsystem-10 in the marketplace, the normal operating system was TOPS-10, which did not include any sort of virtual memory system."

Sure it did.

It wasn't a demand paged implementation. In the KA10 it used 2 sets of segmentation/relocation registers. It provided a shared code capability (in a hi seg, low seg arrangement). User addresses were virtual, the hardware translated them to physical addresses on every reference, users were isolated from one another and total user space could greatly exceed physical memory.

The KI10 actually had a page map capability, but I don't think it was demand driven. It was designed to relieve physical memory fragmentation that the segmentation mechanism created. —Preceding unsigned comment added by 128.222.37.20 (talk) 16:20, 13 January 2009 (UTC)

I don't think the segmentation/relocation mechanism is normally called "virtual memory". (cf. Paging#Terminology) Many early systems (before paging and segmentation) had "swapping" features, where a whole program would be copied out to secondary storage when inactive, but could not be run until the whole program was back in main memory. The PDP-10's twist on the feature was to swap user storage (read-write) separately from program storage (read-only) since in a time-sharing context many users might be using the same program. A little like shared libraries, but with only one library per process....

I don't know how the KI10 system worked; the ITS systems used their own (Systems Concepts) paging device. --macrakis (talk) 18:22, 13 January 2009 (UTC)

TOPS10 "virtual memory" feature was demand driven from version 6.01 (about May 1974) onwards. This was true for the KI10 and KS10 processors and probably for the KL10 processors, but probably not for the KA10 and PDP-6 processors.

I rendered a set of benchmark programs including some to test the vm-capability to DEC in autumn 1973, and when I arrived in Maynard, they admitted that TOPS10 could not fulfill this. I agreed to run those programs on TENEX, and some TOPS-10 developers informed me about the state of the implementation of vm in TOPS-10. Our System (KI no. 628) was delivered in April 1974 with TOPS-10 v. 5.07, about two months later we switched to 6.01 and all benchmark programs including those relying on vm ran successfully as acceptance test. --Jkbw (talk) 21:10, 15 January 2009 (UTC)

---

(128.222.37.20): Regarding the above, "I don't think the segmentation/relocation mechanism is normally called "virtual memory"

It was where I went to school, the very article and section you reference talks about it: "In the 1960s, after the concept of virtual memory was introduced—in two variants, either using segments or pages..." If you have dynamic address translation then you have virtual memory otherwise you are accessing physical memory.

Paging is a virtual memory management scheme. It was an improvement on segmentation schemes - it removed system overhead by trading external fragmentation that had to be managed ("the big BLT" in old PDP-10 speak) for internal fragmentation that was self managing by virtue of fixed size slots (pages).

Being demand driven instead of explicitly scheduled is I think your point. Its true, demand driven management is almost always associated with paging, but I think some Borroughs systems had demand based segmented management schemes. (comment by 128.222.37.20)

I may well be mistaken, but I think when people talked about "segmentation" they were talking about a more-or-less indefinite number of segments (as in Multics, say), not just the two with fixed roles (user private memory and shared program code) that the PDP-10 provided. --macrakis (talk) 03:28, 22 January 2009 (UTC)

---

Hi 128.222.37.20. Yes, I think we are discussing different levels of "virtuality": regarding paging or segmentation hardware memory is virtual insofar as consecutive addresses of my program are not necessarily consecutive in physical memory, i.e. you have virtual addressing, but memory remains (real) memory. When regarding operating systems like VMS or TOPS-20, memory is virtual because your information is not necessarily in physical memory at all, and that was really interesting to the user, running a 200 kWord program when only 64 kWord of physical memory were installed (same problem with GBytes today).

I totally agree with Your statement that demand driven vm does not depend on paging under all circumstances.

Best regards from Berlin --Jkbw (talk) 22:24, 21 January 2009 (UTC)

Meaning of name TENEX

What does "TENEX" stand for, assuming it is an acronym? The article discusses the system but is missing information about what the name means, which should be added to the article. —Lowellian (reply) 03:33, 21 October 2009 (UTC)

I forwarded this question to Dan Murphy, my guess was something like "ten" and "extended". Here his answer:

That's about it. Dan Bobrow and I and the others involved in the origins of TENEX kicked around names. It was to be an "extended" OS for the PDP-10, so TEN-EX(tended) was the result. I'm sure there were other possibilities floated, but I don't recall any of them at this point.

Thanks for the query.

-d

--Jkbw (talk) 21:35, 21 October 2009 (UTC)

The name "10-SYS" or "TENSYS" was apparently a thing at some point: https://walden-family.com/bbn/10-SYS/ Lars Brinkhoff (talk) 06:09, 13 April 2022 (UTC)

Small clarifying edit on simultaneous access to full address spaces.

I changed the sentence to "full 18 bit address space of 262144 words of virtual memory". the 262144 is unambiguous, 262k is a mix of decimal and binary. Also I added the word virtual, for clarification. For physical memory, the number of full address spaces that can fit is rather low. physically, 2MW - monitor use = maybe 3 or 4 full user spaces. — Preceding unsigned comment added by Sciencia61 (talk • contribs) 20:30, 18 June 2018 (UTC)