High level overview of RT-11, RSX-11, TOPS-10, and RSTS?

[Dale Satterwaite]

I used TOPS-20 years ago and although I remember almost nothing I know it
was a good timesharing system with some nice programming languages and of
course emacs.

The rest of these I only heard of and have no idea what they are really
about. I went over the wikipedia pages but they seem fairly useless and the
other thousands of sites I found seem to be for experts and are over my head
at this point.

Would anyone be willing to explain at a high level what these OS are all
about, what each one is best used for and whether recent versions are
available to run on something like SIMH? I realize they are not developed
anymore I mean recent as in close to the last official release so we are at
least getting the state of the art.

Were these all written in assembly or DEC MACRO language and is the system
interface in assembly or C, etc.? I don't like C very much and I am
looking for a fun platform for developing code on and it would be neat to
find something good that was written not in C.

Thanks,

Dale

[Johnny Billquist]

You're probably going to get several answers with different opinions,
but I'll try to give a brief answer.

First of all, RT-11, RSX and RSTS/E are all for the PDP-11, while
Tops-10 and TOPS-20 are for the PDP-10, so we're talking two different
architectures with very different capabilities.

Anyway...

RT-11 is a small, single user (more or less) realtime system written in
MACRO-11. It have very low demands on the hardware, and really good
response times. It's main target were small lab systems where you needed
realtime systems. It do have a lot of compilers and languages, but the
system is a bit restricted if you start looking at writing large systems
in software. It can run with memory protection, but the basic system
usually runs without.

RSX-11 is a medium size, multi-user realtime system written in MACRO-11,
with some splatters of BLISS. It can run on pretty much any PDP-11
system as well, but it will give you headaches if you run it on systems
without MMU (even if it is possible). It also have good realtime
capabilities, although it naturally will not be as efficient on small
tasks as RT-11 is. You have a larger selection of programming languages
and tools than in RT-11, and it can be used to design larger systems.
RSX-11 exists in three major flavors. -11S which is a diskless system,
-11M which is the basic version, and -11M-PLUS, which is a much expanded
version for the large PDP-11 systems, and much improved capabilities.
They are all realtime in the bottom, even though they are multiuser, and
have some timesharing capabilities. Max users in theory is 255 with
-11M-PLUS.

RSTS/E is a medium sized time sharing system written in MACRO-11. It's a
really nice system for timesharing, but it is not suitable for realtime.
You can have up to 63 users. Just about the same tools and languages
exists as for RSX. RSTS/E is nice in that it gives you runtime systems,
which the programs actually run under, and they can present different
characteristics. So you have both an RT-11 runtime system, and an RSX
runtime system, and must RT-11 programs can run under the RT-11 RTS,
while many RSX programs can run under the RSX RTS. RSTS/E do require a
machine with MMU, as well as some amount of memory.

Tops-10 is also a timesharing system, but for the PDP-10. As far as I
know, it's mostly written in MACRO-10. It's pretty old, going all the
way back to the first PDP-10 (not sure if it might actually also work on
a PDP-6). You have a fair selection of tools and languages, but less
than under TOPS-20. In some ways, Tops-10 might remind people of RT-11
or RSTS/E, if that helps. The PDP-10 (and Tops-10) offers more
capabilities, though, as the machines have much more memory to play with
in a process.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Richard]

[Please do not mail me a copy of your followup]

Johnny Billquist <b...@softjar.se> spake the secret code
<mavj3c$6km$1...@Iltempo.Update.UU.SE> thusly:

>RSTS/E is a medium sized time sharing system written in MACRO-11. It's a
>really nice system for timesharing, but it is not suitable for realtime.
>You can have up to 63 users. Just about the same tools and languages
>exists as for RSX. RSTS/E is nice in that it gives you runtime systems,
>which the programs actually run under, and they can present different
>characteristics. So you have both an RT-11 runtime system, and an RSX
>runtime system, and must RT-11 programs can run under the RT-11 RTS,
>while many RSX programs can run under the RSX RTS. RSTS/E do require a
>machine with MMU, as well as some amount of memory.

<http://bitsavers.trailing-edge.com/pdf/dec/pdp11/rsts/V06/DEC-11-ORSUA-D-D_RSTS_SystemUserGuide_Jul75.pdf>

Has a good introduction to RSTS-11 Version 6. In version 6, once you
logged in you were presented with a "Ready" prompt from the BASIC-PLUS
interpreter. Later versions of RSTS (9 and 10 at least, which I never
used, but looked at the docs on bitsavers) introduced the BASIC command
that invoked the interpreter and gave you a more typical command shell
when you logged-in.

I used V6 and V7 which typically put you in the BASIC-PLUS interpreter
when you logged in. This made the system very friendly to teach
people rudimentary programming. I myself (as a teenager) taught high
school teachers how to program on RSTS/E during summer courses.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Dale Satterwaite]

Hi Johnny,

On 2015-02-05, Johnny Billquist <b...@softjar.se> wrote:

> You're probably going to get several answers with different opinions,
> but I'll try to give a brief answer.

Your answers were great! Very helpful.

> First of all, RT-11, RSX and RSTS/E are all for the PDP-11, while
> Tops-10 and TOPS-20 are for the PDP-10, so we're talking two different
> architectures with very different capabilities.

I totally missed that point.

> RT-11 is a small, single user (more or less) realtime system written in
> MACRO-11. It have very low demands on the hardware, and really good
> response times. It's main target were small lab systems where you needed
> realtime systems. It do have a lot of compilers and languages, but the
> system is a bit restricted if you start looking at writing large systems
> in software. It can run with memory protection, but the basic system
> usually runs without.

Interesting. It sounds a little like DOS or CP/M then. It sounds like fun
but I'm not sure if I should try getting a taste of all these depending how
much system administration is required. I don't have that much free time so
I'm trying to find out as much as I can before going down too many blind alleys.

> RSX-11 is a medium size, multi-user realtime system written in MACRO-11,
> with some splatters of BLISS. It can run on pretty much any PDP-11
> system as well, but it will give you headaches if you run it on systems
> without MMU (even if it is possible).

So this OS uses virtual storage where the RT-11 didn't?

> tasks as RT-11 is. You have a larger selection of programming languages
> and tools than in RT-11, and it can be used to design larger systems.

Is there an official archive for this and the other OS and languages or is
stuff spread out all over the net or is it even available? I saw various
things on the SIMH site but aside from a pregenerated RSTS is it possible
for somebody who knows nothing about these OS to do sysgens from doc or
tutorials or is that beyond the ability of people who never did one back in
the day?

> RSX-11 exists in three major flavors. -11S which is a diskless system,
> -11M which is the basic version, and -11M-PLUS, which is a much expanded
> version for the large PDP-11 systems, and much improved capabilities.
> They are all realtime in the bottom, even though they are multiuser, and
> have some timesharing capabilities. Max users in theory is 255 with
> -11M-PLUS.

When you mentioned max users for ESX and RSTS/E are you talking about
process limits for the whole OS or are you talking about signed-on users or
something else? All those limits seem more than adequate for any use I can
imagine for myself if it is signed-on users. And probably even for
processes.

Are RSX versions available and how recent are they?

> you have both an RT-11 runtime system, and an RSX runtime system, and must
> RT-11 programs can run under the RT-11 RTS, while many RSX programs can
> run under the RSX RTS. RSTS/E do require a machine with MMU, as well as
> some amount of memory.

That sounds interesting too but I don't know if the compatability would be
useful for me since I don't have any DEC applications at all at this point.

> or RSTS/E, if that helps. The PDP-10 (and Tops-10) offers more
> capabilities, though, as the machines have much more memory to play with
> in a process.

I'm looking for that delicate balance between a good development system that
doesn't require much administration (similar to that aspect of UNIX although
there are many other things about UNIX I don't like) and capability. It
seems very few OS get that balance the way a developer wants. Some neat OS
require huge system administration and if you try to create your own system
for development you end up spending most of your time as your own sysadmin.

To sum up first of all thank you very much for all the details. This
information is so helpful and concise and is really what I wanted to know. I
am sort of leaning towards trying RSX based on your description since it
seems to be possibly a good middle ground between RT-11 and RSTS. If RSTS
doesn't require much administration it might be interesting to try that too.

How recent a copy of RSX can we get and is it possible or necessary for a
person with no DEC experience to do a sysgen and set up a nice development
system? What languages are available? I would like FORTRAN, ALGOL, and
SNOBOL if they are available but I am very interested most of all in
learning the DEC MACRO variant for this OS.

Are there user communities for any of these OS or is usenet all there is?

Thanks,

Dale

[Dale Satterwaite]

Hi Richard,

On 2015-02-05, Richard <legaliz...@mail.xmission.com> wrote:

><http://bitsavers.trailing-edge.com/pdf/dec/pdp11/rsts/V06/DEC-11-ORSUA-D-D_RSTS_SystemUserGuide_Jul75.pdf>
>
> Has a good introduction to RSTS-11 Version 6.

Thanks I will look it over and hopefully find a similar book for RSX.

I meant to ask in my reply to Johnny if there are any general PDP-11 books
people recommend or whether the DEC doc is sufficient. It seems to vary
greatly across OS how good the doc is or if it even exists. I heard DEC doc
is good but I really don't know.

> In version 6, once you logged in you were presented with a "Ready" prompt
> from the BASIC-PLUS interpreter. Later versions of RSTS (9 and 10 at
> least, which I never used, but looked at the docs on bitsavers) introduced
> the BASIC command that invoked the interpreter and gave you a more typical
> command shell when you logged-in.

The later versions sound better than because I have no interest in
BASIC. Mostly I am interested in playing around with the machine at the
assembly level.

Thanks,

Dale

[Scott Dorsey]

Dale Satterwaite <satu...@sunday.com> wrote:
>
>> RT-11 is a small, single user (more or less) realtime system written in
>> MACRO-11. It have very low demands on the hardware, and really good
>> response times. It's main target were small lab systems where you needed
>> realtime systems. It do have a lot of compilers and languages, but the
>> system is a bit restricted if you start looking at writing large systems
>> in software. It can run with memory protection, but the basic system
>> usually runs without.
>
>Interesting. It sounds a little like DOS or CP/M then. It sounds like fun
>but I'm not sure if I should try getting a taste of all these depending how
>much system administration is required. I don't have that much free time so
>I'm trying to find out as much as I can before going down too many blind alleys.

CP/M was completely modelled after RT-11. Gary Killdall had used RT-11 and
his goal was to build a system with a similar user interface, similar basic
internal structure, but more compact and stripped down. Most of the commands
from CP/M, such as DIR, PIP, SYSGEN, COPY, etc. all followed the RT-11 format.

MS-DOS was modelled after CP/M by some people at Seattle Business Computing
who didn't really understand CP/M and why it did some things, so they copied
a lot of things badly and broke them, but that is a whole other story.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Christian Corti]

Scott Dorsey <klu...@panix.com> wrote:
> CP/M was completely modelled after RT-11. Gary Killdall had used RT-11 and
> his goal was to build a system with a similar user interface, similar basic
> internal structure, but more compact and stripped down. Most of the commands
> from CP/M, such as DIR, PIP, SYSGEN, COPY, etc. all followed the RT-11 format.

One can debate on this, but IMO CP/M and RT-11 are more modelled
after OS/8 and maybe TOPS.

Christian

[Johnny Billquist]

On 2015-02-06 11:33, Dale Satterwaite wrote:
> Hi Richard,
>
> On 2015-02-05, Richard <legaliz...@mail.xmission.com> wrote:
>
>> <http://bitsavers.trailing-edge.com/pdf/dec/pdp11/rsts/V06/DEC-11-ORSUA-D-D_RSTS_SystemUserGuide_Jul75.pdf>
>>
>> Has a good introduction to RSTS-11 Version 6.
>
> Thanks I will look it over and hopefully find a similar book for RSX.

Well, you do have
http://bitsavers.trailing-edge.com/pdf/dec/pdp11/rsx11/RSX11Mplus_V4.x/1/AA-FD03B-TC_RSX-11M_PLUS_V4.0_Introduction_to_RSX-11M_PLUS_Sep87.pdf
which gives a rudimentary introduction to RSX. Useful to just learn to
do basic things, but you need other manuals for more advanced usage as
well as actual programming...

> I meant to ask in my reply to Johnny if there are any general PDP-11 books
> people recommend or whether the DEC doc is sufficient. It seems to vary
> greatly across OS how good the doc is or if it even exists. I heard DEC doc
> is good but I really don't know.

This so very much depends on what kind of information you are looking for.

You have the processor handbooks, which are very good if you are
interested in learning about the architecture and various low level details.

I think there might be one or two books about assembler programming on
the PDP-11, which also are rather OS agnostic. Otherwise it's going to
be more specific per OS.

>> In version 6, once you logged in you were presented with a "Ready" prompt
>> from the BASIC-PLUS interpreter. Later versions of RSTS (9 and 10 at
>> least, which I never used, but looked at the docs on bitsavers) introduced
>> the BASIC command that invoked the interpreter and gave you a more typical
>> command shell when you logged-in.
>
> The later versions sound better than because I have no interest in
> BASIC. Mostly I am interested in playing around with the machine at the
> assembly level.

You can of course program in assembler on those versions of RSTS/E too.
Or on any of the other OSes around.

Johnny

[Scott Dorsey]

This is definitely true. Killdall very specifically credits RT-11
as his model, and RT-11 was clearly derived from OS/8 in many ways.

[Johnny Billquist]

On 2015-02-06 11:30, Dale Satterwaite wrote:
> Hi Johnny,
>
> On 2015-02-05, Johnny Billquist <b...@softjar.se> wrote:
>
>> You're probably going to get several answers with different opinions,
>> but I'll try to give a brief answer.
>
> Your answers were great! Very helpful.

Keep asking, and I'll try to answer...

>> First of all, RT-11, RSX and RSTS/E are all for the PDP-11, while
>> Tops-10 and TOPS-20 are for the PDP-10, so we're talking two different
>> architectures with very different capabilities.
>
> I totally missed that point.

It's a rather important point. The PDP-11 is a 16-bit architecture with
a physical address space of (at most) 22 bits. The PDP-10 is a 36-bit
architecture with a physical address space of (I think) 23 bits.

>> RT-11 is a small, single user (more or less) realtime system written in
>> MACRO-11. It have very low demands on the hardware, and really good
>> response times. It's main target were small lab systems where you needed
>> realtime systems. It do have a lot of compilers and languages, but the
>> system is a bit restricted if you start looking at writing large systems
>> in software. It can run with memory protection, but the basic system
>> usually runs without.
>
> Interesting. It sounds a little like DOS or CP/M then. It sounds like fun
> but I'm not sure if I should try getting a taste of all these depending how
> much system administration is required. I don't have that much free time so
> I'm trying to find out as much as I can before going down too many blind alleys.

Like others said, CP/M and MS-DOS really can trace a lot of heritage
back to RT-11, and beyond...

>> RSX-11 is a medium size, multi-user realtime system written in MACRO-11,
>> with some splatters of BLISS. It can run on pretty much any PDP-11
>> system as well, but it will give you headaches if you run it on systems
>> without MMU (even if it is possible).
>
> So this OS uses virtual storage where the RT-11 didn't?

Yes.

>> tasks as RT-11 is. You have a larger selection of programming languages
>> and tools than in RT-11, and it can be used to design larger systems.
>
> Is there an official archive for this and the other OS and languages or is
> stuff spread out all over the net or is it even available? I saw various
> things on the SIMH site but aside from a pregenerated RSTS is it possible
> for somebody who knows nothing about these OS to do sysgens from doc or
> tutorials or is that beyond the ability of people who never did one back in
> the day?

Unfortunately you opened the can of worms... :-)
As far as PDP-11 software goes, it is all still copyrighted and owned,
and can't officially but put up for grabs.

simh sortof have an exception in the form of a specific license to run
older versions of various DEC software on it. That is a story in itself
as well, but let's just leave it at that for now.

As for doing sysgens, yes, it's all perfectly doable from the manuals.
That said, the manuals are not thin...

There are also several people who have put together shorter how-to pages
on the net on how to do sysgens and similar stuff, which might help you
to a fast start.

>> RSX-11 exists in three major flavors. -11S which is a diskless system,
>> -11M which is the basic version, and -11M-PLUS, which is a much expanded
>> version for the large PDP-11 systems, and much improved capabilities.
>> They are all realtime in the bottom, even though they are multiuser, and
>> have some timesharing capabilities. Max users in theory is 255 with
>> -11M-PLUS.
>
> When you mentioned max users for ESX and RSTS/E are you talking about
> process limits for the whole OS or are you talking about signed-on users or
> something else? All those limits seem more than adequate for any use I can
> imagine for myself if it is signed-on users. And probably even for
> processes.

Max users means interactively logged in users.
In RSX, the number of actual processes are limited by memory. while in
RSTS/E it is more or less the fact that each user can only have one process.

> Are RSX versions available and how recent are they?

People have made the latest versions available. You should be able to
find them at trailing-edge.com, and possibly bitsavers and I don't know
where else.

The last (latest?) version of RSX-11M-PLUS is V4.6, which was released
in 1999.

>> you have both an RT-11 runtime system, and an RSX runtime system, and must
>> RT-11 programs can run under the RT-11 RTS, while many RSX programs can
>> run under the RSX RTS. RSTS/E do require a machine with MMU, as well as
>> some amount of memory.
>
> That sounds interesting too but I don't know if the compatability would be
> useful for me since I don't have any DEC applications at all at this point.

Well, it means you have more flexibility, but as they emulation isn't
complete, it also depends on how advanced you intend to be.

>> or RSTS/E, if that helps. The PDP-10 (and Tops-10) offers more
>> capabilities, though, as the machines have much more memory to play with
>> in a process.
>
> I'm looking for that delicate balance between a good development system that
> doesn't require much administration (similar to that aspect of UNIX although
> there are many other things about UNIX I don't like) and capability. It
> seems very few OS get that balance the way a developer wants. Some neat OS
> require huge system administration and if you try to create your own system
> for development you end up spending most of your time as your own sysadmin.

System admin is going to take some amount of work. no matter which OS
you go for. I don't know if any would be much easier to admin, except
for RT-11, which really don't need much of any admin, since it's like a
PC... :-)

> To sum up first of all thank you very much for all the details. This
> information is so helpful and concise and is really what I wanted to know. I
> am sort of leaning towards trying RSX based on your description since it
> seems to be possibly a good middle ground between RT-11 and RSTS. If RSTS
> doesn't require much administration it might be interesting to try that too.

It's hard to call it a middle ground. RSX is rather different from
RSTS/E, but also rather different than RT-11. From a usage perspective
you could perhaps argue that it's a bit of both, but when you start
working in the systems, they all are very different.

> How recent a copy of RSX can we get and is it possible or necessary for a
> person with no DEC experience to do a sysgen and set up a nice development
> system? What languages are available? I would like FORTRAN, ALGOL, and
> SNOBOL if they are available but I am very interested most of all in
> learning the DEC MACRO variant for this OS.

FORTRAN-77 exists, as do PASCAL, C, BASIC, COBOL, and a bunch of other
ones. I think at least one Algol implementation exists from DECUS, but I
don't remember seeing any SNOBOL for RSX.

MACRO-11 is the same for all three OSes.

You also have a few databases, and other stuff. TCP/IP exists for RSX
and RT-11, but not for RSTS/E. DECnet supposedly exists for all three,
but it appears to be hard to find for RT-11.

> Are there user communities for any of these OS or is usenet all there is?

There are a few mailing lists, as well as usenet, but I'm not aware of
any web forums.

Johnny

[Richard]

[Please do not mail me a copy of your followup]

Dale Satterwaite <satu...@sunday.com> spake the secret code
<mb259o$sp6$2...@speranza.aioe.org> thusly:

>I meant to ask in my reply to Johnny if there are any general PDP-11 books
>people recommend or whether the DEC doc is sufficient.

For getting insight into the PDP-11 architecture and how it fits in
the history of DEC architectures, I recommend this book:

<http://bitsavers.trailing-edge.com/pdf/dec/_Books/Bell-ComputerEngineering.pdf>

[glen herrmannsfeldt]

Scott Dorsey <klu...@panix.com> wrote:
> Dale Satterwaite <satu...@sunday.com> wrote:

(snip on RT-11, and other DEC OSs)

>>Interesting. It sounds a little like DOS or CP/M then.
>> It sounds like fun but I'm not sure if I should try getting a
>> taste of all these depending how much system administration is
>> required. I don't have that much free time so I'm trying to
>> find out as much as I can before going down too many blind alleys.

> CP/M was completely modelled after RT-11. Gary Killdall had
> used RT-11 and his goal was to build a system with a similar
> user interface, similar basic internal structure, but more
> compact and stripped down. Most of the commands from CP/M,
> such as DIR, PIP, SYSGEN, COPY, etc. all followed the RT-11 format.

I had thought CP/M was more modelled after TOPS-10 than RT-11,
but it does seem likely that he used both. There are more stories
of Gary using TOPS-10, though.

> MS-DOS was modelled after CP/M by some people at Seattle
> Business Computing who didn't really understand CP/M and why
> it did some things, so they copied a lot of things badly
> and broke them, but that is a whole other story.

-- glen

[Johnny Billquist]

On 2015-02-06 18:20, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Dale Satterwaite <satu...@sunday.com> spake the secret code
> <mb259o$sp6$2...@speranza.aioe.org> thusly:
>
>> I meant to ask in my reply to Johnny if there are any general PDP-11 books
>> people recommend or whether the DEC doc is sufficient.
>
> For getting insight into the PDP-11 architecture and how it fits in
> the history of DEC architectures, I recommend this book:
>
> <http://bitsavers.trailing-edge.com/pdf/dec/_Books/Bell-ComputerEngineering.pdf>

That is a really good book, which I'd definitely recommend for anyone
interested in the DEC architectures. Perhaps not the thing if you want
to learn specifics about one architecture, but a lot of really good
stuff on the larger picture.

[Scott Dorsey]

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>Scott Dorsey <klu...@panix.com> wrote:
>> Dale Satterwaite <satu...@sunday.com> wrote:
>
>(snip on RT-11, and other DEC OSs)
>>>Interesting. It sounds a little like DOS or CP/M then.
>>> It sounds like fun but I'm not sure if I should try getting a
>>> taste of all these depending how much system administration is
>>> required. I don't have that much free time so I'm trying to
>>> find out as much as I can before going down too many blind alleys.
>
>> CP/M was completely modelled after RT-11. Gary Killdall had
>> used RT-11 and his goal was to build a system with a similar
>> user interface, similar basic internal structure, but more
>> compact and stripped down. Most of the commands from CP/M,
>> such as DIR, PIP, SYSGEN, COPY, etc. all followed the RT-11 format.
>
>I had thought CP/M was more modelled after TOPS-10 than RT-11,
>but it does seem likely that he used both. There are more stories
>of Gary using TOPS-10, though.

TOPS-10 is a huge operating system with a real pre-emptive multitasking
kernel. That's a hard thing to do on a processor without even test and
set instructions.

[Bob Eager]

I always thought a more apposite starting point was OS/8.



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

[glen herrmannsfeldt]

Scott Dorsey <klu...@panix.com> wrote:

(snip, I wrote)

>>I had thought CP/M was more modelled after TOPS-10 than RT-11,
>>but it does seem likely that he used both. There are more stories
>>of Gary using TOPS-10, though.

> TOPS-10 is a huge operating system with a real pre-emptive multitasking
> kernel. That's a hard thing to do on a processor without even test and
> set instructions.

Yes. But if you consider the "look and feel", instead of the
underlying software and hardware, maybe.

If timesharing works right, an individual user at a terminal,
under normal conditions, does not have to consider that it
is a pre-emptive multitasking system. Only that the commands given
are executed reasonably fast.

-- glen

[Johnny Billquist]

Aw, c'mon. This is too uninformed.
First. Pre-emptive multiprocessing have nothing to do with the existence
of a test-and-set like instruction.
Second. Any processor actually have instructions that can be used for
test-and-set. Typical ones are shift, increment and decrement. Pick one
of them.
If this is too hard to imagine, let me know, and I'll in detail how it
works.

Test-and-set like instructions becomes way more important in
multiprocessor systems, but you need to have ones that are atomic on the
bus. This is where it becomes tricky, and this is a condition that makes
it close to impossible to make multiprocessor systems with some CPUs.

[Scott Dorsey]

Johnny Billquist <b...@softjar.se> wrote:
>Aw, c'mon. This is too uninformed.
>First. Pre-emptive multiprocessing have nothing to do with the existence
>of a test-and-set like instruction.
>Second. Any processor actually have instructions that can be used for
>test-and-set. Typical ones are shift, increment and decrement. Pick one
>of them.
>If this is too hard to imagine, let me know, and I'll in detail how it
>works.

I know how it works, I did it on the 8086, and it was NO FUN.

>Test-and-set like instructions becomes way more important in
>multiprocessor systems, but you need to have ones that are atomic on the
>bus. This is where it becomes tricky, and this is a condition that makes
>it close to impossible to make multiprocessor systems with some CPUs.

If it's not atomic, it's not test and set. (Yeah, you can turn off
interrupts, do the operation, turn interrupts back on.)

[Bob Eager]

On Sun, 08 Feb 2015 10:33:56 -0500, Scott Dorsey wrote:

> Johnny Billquist <b...@softjar.se> wrote:
>>Aw, c'mon. This is too uninformed.
>>First. Pre-emptive multiprocessing have nothing to do with the existence
>>of a test-and-set like instruction.
>>Second. Any processor actually have instructions that can be used for
>>test-and-set. Typical ones are shift, increment and decrement. Pick one
>>of them.
>>If this is too hard to imagine, let me know, and I'll in detail how it
>>works.
>
> I know how it works, I did it on the 8086, and it was NO FUN.

Pretty trivial on the 8086, I thought.

[Johnny Billquist]

On 2015-02-08 16:33, Scott Dorsey wrote:
> Johnny Billquist <b...@softjar.se> wrote:
>> Aw, c'mon. This is too uninformed.
>> First. Pre-emptive multiprocessing have nothing to do with the existence
>> of a test-and-set like instruction.
>> Second. Any processor actually have instructions that can be used for
>> test-and-set. Typical ones are shift, increment and decrement. Pick one
>> of them.
>> If this is too hard to imagine, let me know, and I'll in detail how it
>> works.
>
> I know how it works, I did it on the 8086, and it was NO FUN.

Good that you know. It's really not even hard. Easiest with shift
instruction, since you don't have to back out of that one. It's really
no harder than an explicit test-set instruction.

>> Test-and-set like instructions becomes way more important in
>> multiprocessor systems, but you need to have ones that are atomic on the
>> bus. This is where it becomes tricky, and this is a condition that makes
>> it close to impossible to make multiprocessor systems with some CPUs.
>
> If it's not atomic, it's not test and set. (Yeah, you can turn off
> interrupts, do the operation, turn interrupts back on.)

You are missing the point. Of course it is atomic in the CPU. I'm
talking about being atomic on the bus. That's a different thing...

In multiprocessor systems you cannot lock out interrupts, which is why
it becomes so important...

[Johnny Billquist]

On 2015-02-08 16:43, Bob Eager wrote:
> On Sun, 08 Feb 2015 10:33:56 -0500, Scott Dorsey wrote:
>
>> Johnny Billquist <b...@softjar.se> wrote:
>>> Aw, c'mon. This is too uninformed.
>>> First. Pre-emptive multiprocessing have nothing to do with the existence
>>> of a test-and-set like instruction.
>>> Second. Any processor actually have instructions that can be used for
>>> test-and-set. Typical ones are shift, increment and decrement. Pick one
>>> of them.
>>> If this is too hard to imagine, let me know, and I'll in detail how it
>>> works.
>>
>> I know how it works, I did it on the 8086, and it was NO FUN.
>
> Pretty trivial on the 8086, I thought.

Indeed. A simple shift will give you the test-and-set semantics.

[Johnny Billquist]

...any way, this is still totally irrelevant for a preemptive
multitasking system. You normally do not even care for a test-and-set
instruction for that.

A test-and-set instruction is essential for spin-locks, and spin-locks
are essential for multiprocessor systems.

All because of the fact that you cannot use the interrupt system
disabling to achieve synchronization.

Proof of pudding: the PDP-11 do not have a test-and-set instruction, but
do have preemptive multitasking systems. Now, you could hit back at me
with the fact that there are other instructions, which provide the same
semantics (which I just pointed out). I'll hit back with the PDP-8,
which do not even have that much, but still do have preemptive
multitasking operating systems written for it anyway.

[Bob Eager]

On Sun, 08 Feb 2015 17:22:05 +0100, Johnny Billquist wrote:

> On 2015-02-08 16:43, Bob Eager wrote:
>> On Sun, 08 Feb 2015 10:33:56 -0500, Scott Dorsey wrote:
>>
>>> Johnny Billquist <b...@softjar.se> wrote:
>>>> Aw, c'mon. This is too uninformed.
>>>> First. Pre-emptive multiprocessing have nothing to do with the
>>>> existence of a test-and-set like instruction.
>>>> Second. Any processor actually have instructions that can be used for
>>>> test-and-set. Typical ones are shift, increment and decrement. Pick
>>>> one of them.
>>>> If this is too hard to imagine, let me know, and I'll in detail how
>>>> it works.
>>>
>>> I know how it works, I did it on the 8086, and it was NO FUN.
>>
>> Pretty trivial on the 8086, I thought.
>
> Indeed. A simple shift will give you the test-and-set semantics.

Not locking the bus, though.

[Johnny Billquist]

Probably not, although that is something that must be checked with the
specific CPU.
But that is still not necessary unless you have a multiprocessor system.
Multitasking do not depend on MP. :-)
(Remember where this thread sprung out of...)

[Bob Eager]

On Sun, 08 Feb 2015 22:37:56 +0100, Johnny Billquist wrote:

> On 2015-02-08 22:19, Bob Eager wrote:
>> On Sun, 08 Feb 2015 17:22:05 +0100, Johnny Billquist wrote:
>>
>>> On 2015-02-08 16:43, Bob Eager wrote:
>>>> On Sun, 08 Feb 2015 10:33:56 -0500, Scott Dorsey wrote:
>>>>
>>>>> Johnny Billquist <b...@softjar.se> wrote:
>>>>>> Aw, c'mon. This is too uninformed.
>>>>>> First. Pre-emptive multiprocessing have nothing to do with the
>>>>>> existence of a test-and-set like instruction.
>>>>>> Second. Any processor actually have instructions that can be used
>>>>>> for test-and-set. Typical ones are shift, increment and decrement.
>>>>>> Pick one of them.
>>>>>> If this is too hard to imagine, let me know, and I'll in detail how
>>>>>> it works.
>>>>>
>>>>> I know how it works, I did it on the 8086, and it was NO FUN.
>>>>
>>>> Pretty trivial on the 8086, I thought.
>>>
>>> Indeed. A simple shift will give you the test-and-set semantics.
>>
>> Not locking the bus, though.
>
> Probably not, although that is something that must be checked with the
> specific CPU.
> But that is still not necessary unless you have a multiprocessor system.

DMA?

[glen herrmannsfeldt]

Johnny Billquist <b...@softjar.se> wrote:
> On 2015-02-08 13:06, Scott Dorsey wrote:

(snip, I wrote)

>>> I had thought CP/M was more modelled after TOPS-10 than RT-11,
>>> but it does seem likely that he used both. There are more stories
>>> of Gary using TOPS-10, though.

>> TOPS-10 is a huge operating system with a real pre-emptive multitasking
>> kernel. That's a hard thing to do on a processor without even test and
>> set instructions.

(Besides the fact that I mean "look and feel" and not the underlying
system hardware and software.)

> Aw, c'mon. This is too uninformed.
> First. Pre-emptive multiprocessing have nothing to do with
> the existence of a test-and-set like instruction.

> Second. Any processor actually have instructions that can be used for
> test-and-set. Typical ones are shift, increment and decrement. Pick one
> of them.

Well, partly because people plan ahead. It isn't hard to design
a processor with no read-modify-write instructions. But even then,
you might just have to disable interrupts at the right time.

> If this is too hard to imagine, let me know, and I'll in detail how it
> works.

> Test-and-set like instructions becomes way more important in
> multiprocessor systems, but you need to have ones that are atomic on the
> bus. This is where it becomes tricky, and this is a condition that makes
> it close to impossible to make multiprocessor systems with some CPUs.

And watch for I/O, too.

-- glen

[glen herrmannsfeldt]

Johnny Billquist <b...@softjar.se> wrote:

(snip, regarding the 8086, someone wrote)

>> Not locking the bus, though.

> Probably not, although that is something that must be checked with the
> specific CPU.
> But that is still not necessary unless you have a multiprocessor system.
> Multitasking do not depend on MP. :-)
> (Remember where this thread sprung out of...)

The 8086 has a LOCK prefix, but I forget what it does.

-- glen

[Johnny Billquist]

Well, if you decide to manipulate data in memory that you are currently
doing DMA to, the end result is very undefined/unknown anyway, so there
is no point to implement special locking anyway. So no, still not
necessary unless we're talking multiprocessor systems. :-)

[Johnny Billquist]

On 2015-02-09 08:22, glen herrmannsfeldt wrote:
> Johnny Billquist <b...@softjar.se> wrote:
>> On 2015-02-08 13:06, Scott Dorsey wrote:
>
> (snip, I wrote)
>>>> I had thought CP/M was more modelled after TOPS-10 than RT-11,
>>>> but it does seem likely that he used both. There are more stories
>>>> of Gary using TOPS-10, though.
>
>>> TOPS-10 is a huge operating system with a real pre-emptive multitasking
>>> kernel. That's a hard thing to do on a processor without even test and
>>> set instructions.
>
> (Besides the fact that I mean "look and feel" and not the underlying
> system hardware and software.)
>
>> Aw, c'mon. This is too uninformed.
>> First. Pre-emptive multiprocessing have nothing to do with
>> the existence of a test-and-set like instruction.
>
>> Second. Any processor actually have instructions that can be used for
>> test-and-set. Typical ones are shift, increment and decrement. Pick one
>> of them.
>
> Well, partly because people plan ahead. It isn't hard to design
> a processor with no read-modify-write instructions. But even then,
> you might just have to disable interrupts at the right time.

Most operating systems disable interrupts from time to time. It's almost
required (I haven't researched if it even is possible to write an
multitasking os that do not ever turn off interrupts). And for
multiprocessor systems, that's when you do the spin locks.

But load/store architectures (essentially the ones that do not have
read-modify-write instructions) were not popular back in the day,
because they tend to consume more memory for the code. And memory was an
expensive resource 40 years ago...

>> If this is too hard to imagine, let me know, and I'll in detail how it
>> works.
>
>> Test-and-set like instructions becomes way more important in
>> multiprocessor systems, but you need to have ones that are atomic on the
>> bus. This is where it becomes tricky, and this is a condition that makes
>> it close to impossible to make multiprocessor systems with some CPUs.
>
> And watch for I/O, too.

I/O is actually not such a problem. If you do DMA, you know about it,
and which addresses are affected. You normally do not try to work on
data in those addresses until I/O completes, since you do not know what
data you have there during the I/O, so it isn't really that meaningful.

So locking the bus for read-modify-write instructions is actually not
required for anything when we talk about uniprocessor systems.

[Dale Satterwaite]

Hi Richard,

On 2015-02-06, Richard <legaliz...@mail.xmission.com> wrote:
> [Please do not mail me a copy of your followup]

I know the feeling ;-)

> For getting insight into the PDP-11 architecture and how it fits in
> the history of DEC architectures, I recommend this book:
>
><http://bitsavers.trailing-edge.com/pdf/dec/_Books/Bell-ComputerEngineering.pdf>

Thanks this looks fantastic.

Dale

[Dale Satterwaite]

Hi Scott,

On 2015-02-06, Scott Dorsey <klu...@panix.com> wrote:
> Dale Satterwaite <satu...@sunday.com> wrote:
>>

>>Interesting. It sounds a little like DOS or CP/M then. It sounds like fun
>>but I'm not sure if I should try getting a taste of all these depending how
>>much system administration is required. I don't have that much free time so
>>I'm trying to find out as much as I can before going down too many blind alleys.
>
> CP/M was completely modelled after RT-11. Gary Killdall had used RT-11 and
> his goal was to build a system with a similar user interface, similar basic
> internal structure, but more compact and stripped down. Most of the commands
> from CP/M, such as DIR, PIP, SYSGEN, COPY, etc. all followed the RT-11 format.

What a lucky guess. I was just making a gross comparison by real storage
v. virtual storage. How funny it turned out to be somewhat accurate.

> MS-DOS was modelled after CP/M by some people at Seattle Business Computing
> who didn't really understand CP/M and why it did some things, so they copied
> a lot of things badly and broke them, but that is a whole other story.

That sort of goes without saying as we say the rest is history ;-)

Dale

[Dale Satterwaite]

Hi Johnny,

On 2015-02-06, Johnny Billquist <b...@softjar.se> wrote:
> On 2015-02-06 11:30, Dale Satterwaite wrote:
>>> First of all, RT-11, RSX and RSTS/E are all for the PDP-11, while
>>> Tops-10 and TOPS-20 are for the PDP-10, so we're talking two different
>>> architectures with very different capabilities.
>>
>> I totally missed that point.
>
> It's a rather important point. The PDP-11 is a 16-bit architecture with
> a physical address space of (at most) 22 bits. The PDP-10 is a 36-bit
> architecture with a physical address space of (I think) 23 bits.

It's amazing to remember how little storage people used to do so much with.
So the PDP-11 could have up to 4M real storage. That was actually plenty
back in the day. What kind of virtual storage sizes did the various OS like
RSX and RSTS support?

I didn't know the PDP-10 was bigger than a PDP-11. Sounds counterintuitive.
It is surprising that even with a much bigger wordsize they only had twice
the real storage support. What was the point of the bigger wordsize then?
Maybe the Bell book discusses this. I don't remember DEC being chosen for
number crunching although the few extra bits would have been nice.

> As for doing sysgens, yes, it's all perfectly doable from the manuals.
> That said, the manuals are not thin...

I don't know anything about the hardware either so this might not be too
easy. Hopefully I will find a pregenerated system.

> There are also several people who have put together shorter how-to pages
> on the net on how to do sysgens and similar stuff, which might help you
> to a fast start.

I found a few but it's hard to decide who knows what he's talking about
since I have no idea about this. For now I will continue reading.

> People have made the latest versions available. You should be able to
> find them at trailing-edge.com, and possibly bitsavers and I don't know
> where else.
>
> The last (latest?) version of RSX-11M-PLUS is V4.6, which was released
> in 1999.

I found a 4.6 system but I didn't have time to see whether it is a
pregenerated system or just the distribution media. I still haven't found
any compilers. There seems to be plenty of stuff for TOPS-20 and some for
TOPS-10 on trailing edge but when you click on the tapes you find quite a
lot of broken links. I saw almost nothing of the OS we have been talking
about.

>> system? What languages are available? I would like FORTRAN, ALGOL, and
>> SNOBOL if they are available but I am very interested most of all in
>> learning the DEC MACRO variant for this OS.
>
> FORTRAN-77 exists, as do PASCAL, C, BASIC, COBOL, and a bunch of other
> ones. I think at least one Algol implementation exists from DECUS, but I
> don't remember seeing any SNOBOL for RSX.

Where can I find copies of all these? Can you point me to any ftp sites
etc.? I didn't see anything on bitsavers but maybe I missed it.

> MACRO-11 is the same for all three OSes.

I suppose this comes with the distribution and doesn't have to be found
separately?

> You also have a few databases, and other stuff. TCP/IP exists for RSX
> and RT-11, but not for RSTS/E. DECnet supposedly exists for all three,
> but it appears to be hard to find for RT-11.

I can't imagine wanting to network at this point. I think I have ruled out
playing with RT-11 so I'll look for RSX and RSTS bits and pieces but I have
a few tons of reading to do. It's probably good I don't have real hardware
for this. If I mess something up I can just restore backups in a few seconds
and bring up the system again. Sometimes emulation is actually good ;-)

>
>> Are there user communities for any of these OS or is usenet all there is?
>
> There are a few mailing lists, as well as usenet, but I'm not aware of
> any web forums.

Could you list them possibly? I'm fine about not having web forums. I don't
like those anyway.

Thanks,

Dale

[Johnny Billquist]

On 2015-02-09 14:58, Dale Satterwaite wrote:
> Hi Johnny,
>
> On 2015-02-06, Johnny Billquist <b...@softjar.se> wrote:
>> On 2015-02-06 11:30, Dale Satterwaite wrote:
>>>> First of all, RT-11, RSX and RSTS/E are all for the PDP-11, while
>>>> Tops-10 and TOPS-20 are for the PDP-10, so we're talking two different
>>>> architectures with very different capabilities.
>>>
>>> I totally missed that point.
>>
>> It's a rather important point. The PDP-11 is a 16-bit architecture with
>> a physical address space of (at most) 22 bits. The PDP-10 is a 36-bit
>> architecture with a physical address space of (I think) 23 bits.
>
> It's amazing to remember how little storage people used to do so much with.
> So the PDP-11 could have up to 4M real storage. That was actually plenty
> back in the day. What kind of virtual storage sizes did the various OS like
> RSX and RSTS support?

If you by "real storage" mean memory, as opposed to disk, yes. :-)

As for virtual memory size, I'm not sure about RSTS/E, but for RSX, you
have 64K (16-bit word, remember?). Then if the CPU supported split
I/D-space, you can go for 64K instruction and 64K of data. Finally, if
the CPU supports supervisor mode, your user space program can also have
some stuff in supervisor mode, which adds another 64K of instruction and
64K of data, although you most of the time didn't want supervisor mode
data to be different to user mode data.

RSTS/E either is the same, or else a little more limited.

> I didn't know the PDP-10 was bigger than a PDP-11. Sounds counterintuitive.

The numbering schemes are just related to time. The PDP-10 came before
the PDP-11.
It don't say anything about the capabilities of the machines.

> It is surprising that even with a much bigger wordsize they only had twice
> the real storage support. What was the point of the bigger wordsize then?
> Maybe the Bell book discusses this. I don't remember DEC being chosen for
> number crunching although the few extra bits would have been nice.

You are forgetting something, or else I just failed to realize I should
point it out.
The PDP-11 is byte addressable. The PDP-10 is word addressable.
So, for the PDP-10, you have 8MW maximum (assuming the machines DEC
produced). Each word is 4.5 8-bit bytes, which means that if you count
in 8-bit bytes, the PDP-10 have 36 Mbyte.

However, more importantly, addresses within one program are normally 18
bits, (also word addresses), meaning you can write very large programs
within the virtual address space without problems. Not as easy on the
PDP-11, where you start to have to play with CPU features, or overlays.

More points with the big wordsize. Most instructions just takes one
word, as opposed to the PDP-11, where instructions can be one to three
words (each PDP-11 word is 16 bits).

>> As for doing sysgens, yes, it's all perfectly doable from the manuals.
>> That said, the manuals are not thin...
>
> I don't know anything about the hardware either so this might not be too
> easy. Hopefully I will find a pregenerated system.

I think you should be able to find some quick how-to web pages.

>> There are also several people who have put together shorter how-to pages
>> on the net on how to do sysgens and similar stuff, which might help you
>> to a fast start.
>
> I found a few but it's hard to decide who knows what he's talking about
> since I have no idea about this. For now I will continue reading.

And then you can ask questions here. :-)

>> People have made the latest versions available. You should be able to
>> find them at trailing-edge.com, and possibly bitsavers and I don't know
>> where else.
>>
>> The last (latest?) version of RSX-11M-PLUS is V4.6, which was released
>> in 1999.
>
> I found a 4.6 system but I didn't have time to see whether it is a
> pregenerated system or just the distribution media. I still haven't found
> any compilers. There seems to be plenty of stuff for TOPS-20 and some for
> TOPS-10 on trailing edge but when you click on the tapes you find quite a
> lot of broken links. I saw almost nothing of the OS we have been talking
> about.

Afraid I can't help too much here. The PDP-10 software is legally in a
different situation than the PDP-11 software. The situation for the
PDP-10 stuff is much better, so there it's mostly a case of actually
finding the tapes, and I think they should be available in several places.

PDP-11 software is, as I mentioned, murky water. Sadly... :-(

>>> system? What languages are available? I would like FORTRAN, ALGOL, and
>>> SNOBOL if they are available but I am very interested most of all in
>>> learning the DEC MACRO variant for this OS.
>>
>> FORTRAN-77 exists, as do PASCAL, C, BASIC, COBOL, and a bunch of other
>> ones. I think at least one Algol implementation exists from DECUS, but I
>> don't remember seeing any SNOBOL for RSX.
>
> Where can I find copies of all these? Can you point me to any ftp sites
> etc.? I didn't see anything on bitsavers but maybe I missed it.

Nope. Since, as I mentioned, this is not free software. Some people have
put up copyrighted stuff in some places, but it's random and spread out.

>> MACRO-11 is the same for all three OSes.
>
> I suppose this comes with the distribution and doesn't have to be found
> separately?

Correct.

>> You also have a few databases, and other stuff. TCP/IP exists for RSX
>> and RT-11, but not for RSTS/E. DECnet supposedly exists for all three,
>> but it appears to be hard to find for RT-11.
>
> I can't imagine wanting to network at this point. I think I have ruled out
> playing with RT-11 so I'll look for RSX and RSTS bits and pieces but I have
> a few tons of reading to do. It's probably good I don't have real hardware
> for this. If I mess something up I can just restore backups in a few seconds
> and bring up the system again. Sometimes emulation is actually good ;-)

:-)

>>> Are there user communities for any of these OS or is usenet all there is?
>>
>> There are a few mailing lists, as well as usenet, but I'm not aware of
>> any web forums.
>
> Could you list them possibly? I'm fine about not having web forums. I don't
> like those anyway.

Hmm... info-...@dbit.com, if I remember right. Then you also have
HECnet (hobbyist DECnet) at hec...@update.uu.se.
I don't remember the name, but there is a list for tops20 people as
well, that I know of.
I bet there are others that I don't know about...classiccmp comes to
mind as well.

Johnny

>
> Thanks,
>
> Dale
>

[Johnny Billquist]

By the way, if you just want to play around a little inside RSX, there
is Mim.Update.UU.SE that you can telnet to. It's running RSX-11M-PLUS
V4.6, and have lots of tools and stuff installed. Login as guest,
password guest, and play around.

Johnny

[glen herrmannsfeldt]

Johnny Billquist <b...@softjar.se> wrote:
> On 2015-02-08 23:45, Bob Eager wrote:

(snip)

>> DMA?

> Well, if you decide to manipulate data in memory that you are currently
> doing DMA to, the end result is very undefined/unknown anyway, so there
> is no point to implement special locking anyway. So no, still not
> necessary unless we're talking multiprocessor systems. :-)

I just looked up to be sure, and Test and Set does not provide
protection against channels writing to memory, at least not as
define for S/360 and S/370. (Is there an older version?)

-- glen

[glen herrmannsfeldt]

Johnny Billquist <b...@softjar.se> wrote:

(snip, I wrote)

>> (Besides the fact that I mean "look and feel" and not the underlying
>> system hardware and software.)

>>> Aw, c'mon. This is too uninformed.
>>> First. Pre-emptive multiprocessing have nothing to do with
>>> the existence of a test-and-set like instruction.

>>> Second. Any processor actually have instructions that can be used
>>> for test-and-set. Typical ones are shift, increment and decrement.
>>> Pick one of them.

>> Well, partly because people plan ahead. It isn't hard to design
>> a processor with no read-modify-write instructions. But even then,
>> you might just have to disable interrupts at the right time.

> Most operating systems disable interrupts from time to time.
> It's almost required (I haven't researched if it even is possible
> to write an multitasking os that do not ever turn off interrupts).
> And for multiprocessor systems, that's when you do the spin locks.

> But load/store architectures (essentially the ones that do not have
> read-modify-write instructions) were not popular back in the day,
> because they tend to consume more memory for the code. And memory
> was an expensive resource 40 years ago...

Note that read-modify-write isn't enough. Other than TS, the S/360
read-modify-write instructions do not do interlocked access.

Well, in the days of magnetic core memory, which does destructive
read and so requires that the data be written back, it was possible
to design processors to do read-modify-write by avoiding the otherwise
needed restore. That is more obvious of you do the processing
synchronous with the memory system, such that it is a slightly
longer memory cycle. It might be that some PDP-10 systems did that.

And even DRAM has a destructive read, though the restore is usually
done internally, as part of the whole read cycle. It might be that
some early DRAM had the ability to delay the restore such that one
could still do read-modify-write within a single memory cycle.

-- glen

[Johnny Billquist]

On 2015-02-10 05:54, glen herrmannsfeldt wrote:
> Johnny Billquist <b...@softjar.se> wrote:
>
> (snip, I wrote)
>>> (Besides the fact that I mean "look and feel" and not the underlying
>>> system hardware and software.)
>
>>>> Aw, c'mon. This is too uninformed.
>>>> First. Pre-emptive multiprocessing have nothing to do with
>>>> the existence of a test-and-set like instruction.
>
>>>> Second. Any processor actually have instructions that can be used
>>>> for test-and-set. Typical ones are shift, increment and decrement.
>>>> Pick one of them.
>
>>> Well, partly because people plan ahead. It isn't hard to design
>>> a processor with no read-modify-write instructions. But even then,
>>> you might just have to disable interrupts at the right time.
>
>> Most operating systems disable interrupts from time to time.
>> It's almost required (I haven't researched if it even is possible
>> to write an multitasking os that do not ever turn off interrupts).
>> And for multiprocessor systems, that's when you do the spin locks.
>
>> But load/store architectures (essentially the ones that do not have
>> read-modify-write instructions) were not popular back in the day,
>> because they tend to consume more memory for the code. And memory
>> was an expensive resource 40 years ago...
>
> Note that read-modify-write isn't enough. Other than TS, the S/360
> read-modify-write instructions do not do interlocked access.

Yes. But you missed where this discussion have gone now, Glen. :-)
This comment wasn't about TS anymore, but the ability to design
processors without any read-modify-write instructions.

> Well, in the days of magnetic core memory, which does destructive
> read and so requires that the data be written back, it was possible
> to design processors to do read-modify-write by avoiding the otherwise
> needed restore. That is more obvious of you do the processing
> synchronous with the memory system, such that it is a slightly
> longer memory cycle. It might be that some PDP-10 systems did that.

The PDP-11s normally do this on the Unibus. But it is not interlocked.
No need to... There is nothing else that could step in between. But you
have four transactions on the Unibus:
DATO - Writes a word
DATOB - Writes a byte
DATI - Reads a word
DATIP - Destructive read a word. It is expected to be followed by a DATO

So, core memory do not write the data back in a DATIP cycle.

I'm trying to remember if the PDP-8 also was clever enough to do this,
but I can't recall right now. I would definitely expect the PDP-10 to be
able to.

> And even DRAM has a destructive read, though the restore is usually
> done internally, as part of the whole read cycle. It might be that
> some early DRAM had the ability to delay the restore such that one
> could still do read-modify-write within a single memory cycle.

I doubt any did, but yeah, that could possibly be done.

[Rich Alderson]

Johnny Billquist <b...@softjar.se> writes:

> Tops-10 is also a timesharing system, but for the PDP-10. As far as I know,
> it's mostly written in MACRO-10. It's pretty old, going all the way back to
> the first PDP-10 (not sure if it might actually also work on a PDP-6). You
> have a fair selection of tools and languages, but less than under TOPS-20. In
> some ways, Tops-10 might remind people of RT-11 or RSTS/E, if that helps. The
> PDP-10 (and Tops-10) offers more capabilities, though, as the machines have
> much more memory to play with in a process.

Tops-10 and TOPS-20 are both written entirely in Macro-10 (referred to as
Macro-20 on the later OS, but the same binary on both).

Tops-10 v7.04 (or 7.05, if you believe the update tapes) was the last release,
in 1989. It is a lineal descendant of the PDP-6 monitor, created in 1964.

(To the original poster: The PDP-6 was DEC's first mainframe system, with
timesharing as a standard feature when it was an extra cost add-on for the few
systems that had it. It was a commercial failure for technical reasons, but
the instruction set architecture was so popular that it was reimplemented with
newer technology and sold as the PDP-10.)

Tops-10 actually offered languages and capabilities that TOPS-20 did not (for
example, COBOL, real-time processing), and had a much smaller memory footprint.

(To the original poster: Despite the similar names, Tops-10 and TOPS-20 are
entirely separate, and share no code. The latter is a demand-paged virtual
memory system, while the former was until the 7.0x releases a real-memory
system. The system call mechanism is entirely different between them, as is
the I/O model.)

--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...

[Rich Alderson]

Johnny Billquist <b...@softjar.se> writes:

> It's a rather important point. The PDP-11 is a 16-bit architecture with
> a physical address space of (at most) 22 bits. The PDP-10 is a 36-bit
> architecture with a physical address space of (I think) 23 bits.

The physical address space on the PDP-6 and PDP-10 (KA-10 processor) is 18 bits
= 262,144 words. The KI-10 (2nd generation) and KL-10 (3rd generation)
processors upped that to 22 bits. The KL-10 was capable of 23-bit addressing
by implementing a different pager in microcode.

Later, an extended address space of 30 bits was defined for the architecture,
though not fully implemented in DEC hardware.

(To the original poster: Prior to the KL-10, these were all real hardware
implementations rather than microcoded.)

Tops-10 up through v7.03 was restricted to the physical address space, with
processes restricted to a 256KW address space. TOPS-20 used the 23-bit ucode
pager, but also restricted processes to 256KW through v3A. At v4, "extended
mode" addressing was introduced to the operating system, and up to 23 bits were
available; with v5, user programs could also use extended addressing. At
v7.04, Tops-10 began using the TOPS-20 microcode with extended addressing.

> On 2015-02-06 11:30, Dale Satterwaite wrote:

>>> RSX-11 is a medium size, multi-user realtime system written in MACRO-11,
>>> with some splatters of BLISS. It can run on pretty much any PDP-11
>>> system as well, but it will give you headaches if you run it on systems
>>> without MMU (even if it is possible).

>> So this OS uses virtual storage where the RT-11 didn't?

> Yes.

No. RSX-11, like Tops-10 before 1990 on the PDP-10, is limited to the real
memory on the system. It simply maps different chunks of 32KW (64KB) for
different processes out of the 2MW (4MB) maximum physical memory. There is no
paging to disk, so no virtual storage.

[Johnny Billquist]

On 2015-02-10 22:49, Rich Alderson wrote:
> Johnny Billquist <b...@softjar.se> writes:
>
>> It's a rather important point. The PDP-11 is a 16-bit architecture with
>> a physical address space of (at most) 22 bits. The PDP-10 is a 36-bit
>> architecture with a physical address space of (I think) 23 bits.
>
> The physical address space on the PDP-6 and PDP-10 (KA-10 processor) is 18 bits
> = 262,144 words. The KI-10 (2nd generation) and KL-10 (3rd generation)
> processors upped that to 22 bits. The KL-10 was capable of 23-bit addressing
> by implementing a different pager in microcode.
>
> Later, an extended address space of 30 bits was defined for the architecture,
> though not fully implemented in DEC hardware.
>
> (To the original poster: Prior to the KL-10, these were all real hardware
> implementations rather than microcoded.)
>
> Tops-10 up through v7.03 was restricted to the physical address space, with
> processes restricted to a 256KW address space. TOPS-20 used the 23-bit ucode
> pager, but also restricted processes to 256KW through v3A. At v4, "extended
> mode" addressing was introduced to the operating system, and up to 23 bits were
> available; with v5, user programs could also use extended addressing. At
> v7.04, Tops-10 began using the TOPS-20 microcode with extended addressing.

Thanks for the clarifications, Rich. I stayed with just the DEC KL spec
in my summary, for my own simplistic sake. :-)

>> On 2015-02-06 11:30, Dale Satterwaite wrote:
>
>>>> RSX-11 is a medium size, multi-user realtime system written in MACRO-11,
>>>> with some splatters of BLISS. It can run on pretty much any PDP-11
>>>> system as well, but it will give you headaches if you run it on systems
>>>> without MMU (even if it is possible).
>
>>> So this OS uses virtual storage where the RT-11 didn't?
>
>> Yes.
>
> No. RSX-11, like Tops-10 before 1990 on the PDP-10, is limited to the real
> memory on the system. It simply maps different chunks of 32KW (64KB) for
> different processes out of the 2MW (4MB) maximum physical memory. There is no
> paging to disk, so no virtual storage.

Oh no! Do we really have to have a discussion here about what virtual
memory is?

To sum this up quickly: paging is not the same as virtual memory. You
have can virtual memory without having paging. They are two totally
independent concepts.

I assumed when the OP said "virtual storage" he meant virtual memory. If
that question was meant as "paged memory", then you are correct, Rich,
in that none of these OSes uses paging. However, all but RT-11 (and
unmapped RSX systems) do use virtual memory.

And by the way, you can have processes that consume a total of more than
2MW on an RSX system. That is what the check point space is for (the RSX
word for swapping...)

Johnny

[glen herrmannsfeldt]

Rich Alderson <ne...@alderson.users.panix.com> wrote:
> Johnny Billquist <b...@softjar.se> writes:

>> It's a rather important point. The PDP-11 is a 16-bit architecture with
>> a physical address space of (at most) 22 bits. The PDP-10 is a 36-bit
>> architecture with a physical address space of (I think) 23 bits.

(snip on the PDP-10)

>>> So this OS uses virtual storage where the RT-11 didn't?

>> Yes.

> No. RSX-11, like Tops-10 before 1990 on the PDP-10, is limited to
> the real memory on the system. It simply maps different chunks
> of 32KW (64KB) for different processes out of the 2MW (4MB)
> maximum physical memory. There is no paging to disk,
> so no virtual storage.

Virtual addressing but no virtual storage.

Similar to what MS-DOS did with XMS, when the physical address space
is larger than the user (virtual) address space, use bank switching
to get around the problem.

The usual XMS implementation was bank switched, but I believe that
the specification allowed for a swap to disk implementaion.

Also, RT-11 has the SJ, FB, and XM options where XM allows for
extended addressing similar to that described above for RSX-11.

RT-11 was often used on floppy-only systems, where paging would
be too slow. The RT-11 linker did allow for overlays, though, so one
could write big programs.

I did use RSX-11, but not enough to know the answers to these
questions, other than that it has separate I and D (instruction
and data) addressing space.

-- glen

[glen herrmannsfeldt]

Johnny Billquist <b...@softjar.se> wrote:
> On 2015-02-10 22:49, Rich Alderson wrote:

(snip)

>> available; with v5, user programs could also use extended addressing.
>> At v7.04, Tops-10 began using the TOPS-20 microcode with
>> extended addressing.

> Thanks for the clarifications, Rich. I stayed with just the DEC KL spec
> in my summary, for my own simplistic sake. :-)

(snip)

>> No. RSX-11, like Tops-10 before 1990 on the PDP-10, is limited to the
>> real memory on the system. It simply maps different chunks of
>> 32KW (64KB) for different processes out of the 2MW (4MB) maximum
>> physical memory. There is no paging to disk, so no virtual storage.

> Oh no! Do we really have to have a discussion here about what virtual
> memory is?

> To sum this up quickly: paging is not the same as virtual memory. You
> have can virtual memory without having paging. They are two totally
> independent concepts.

I think I agree with Rich. You have to make a distinction between
virtual addressing and virtual storage. They often go together,
but in this case I think you have to keep them separate.

> I assumed when the OP said "virtual storage" he meant virtual memory. If
> that question was meant as "paged memory", then you are correct, Rich,
> in that none of these OSes uses paging. However, all but RT-11 (and
> unmapped RSX systems) do use virtual memory.

It starts to get confusing. While a PDP-10 system likely has more
than 256KW, without extended addressing a user program can't
address more. But it is still useful, allowing for multiple users.

For the IBM S/370, where I first knew virtual storage, originally
it allowed for full 24 bit addressing when real memory was smaller.
In later models, the real addressing space went up to 26 bits
(extra bits in page table entries) but virtual addresses were
still only 24 bits. Again, useful when more than one program
is running.

> And by the way, you can have processes that consume a total of more than
> 2MW on an RSX system. That is what the check point space is for (the RSX
> word for swapping...)

And there is always overlays, as people used before swapping and paging.
(The KA-10 allows for swapping but not paging.)

And don't forget RT-11 XM.

-- glen

[Johnny Billquist]

On 2015-02-11 04:44, glen herrmannsfeldt wrote:
> Johnny Billquist <b...@softjar.se> wrote:
>> On 2015-02-10 22:49, Rich Alderson wrote:
>
> (snip)

>>> No. RSX-11, like Tops-10 before 1990 on the PDP-10, is limited to the
>>> real memory on the system. It simply maps different chunks of
>>> 32KW (64KB) for different processes out of the 2MW (4MB) maximum
>>> physical memory. There is no paging to disk, so no virtual storage.
>
>> Oh no! Do we really have to have a discussion here about what virtual
>> memory is?
>
>> To sum this up quickly: paging is not the same as virtual memory. You
>> have can virtual memory without having paging. They are two totally
>> independent concepts.
>
> I think I agree with Rich. You have to make a distinction between
> virtual addressing and virtual storage. They often go together,
> but in this case I think you have to keep them separate.

Uh? I can't make sense of what you wrote. You say you agree with Rich,
but you seem to agree that demand paging and virtual memory are two
different things that needs to be kept separate.

Or else I'm failing to parse this in yet some other way...

Virtual addressing, by the way, is just how you address the storage. The
storage still have to exist, somehow...

Virtual memory is one concept. Demand paging is another. The two can be
combined is nice ways, but neither requires the other.

And the backing storage for virtual memory is physical memory. Of
course, the virtual memory can also not map to anything at all, at which
point the OS will get page faults if the process tries to access the
memory. What happens at that point is another story...

>> I assumed when the OP said "virtual storage" he meant virtual memory. If
>> that question was meant as "paged memory", then you are correct, Rich,
>> in that none of these OSes uses paging. However, all but RT-11 (and
>> unmapped RSX systems) do use virtual memory.
>
> It starts to get confusing. While a PDP-10 system likely has more
> than 256KW, without extended addressing a user program can't
> address more. But it is still useful, allowing for multiple users.

Right. But I fail to see the confusion in it.

> For the IBM S/370, where I first knew virtual storage, originally
> it allowed for full 24 bit addressing when real memory was smaller.
> In later models, the real addressing space went up to 26 bits
> (extra bits in page table entries) but virtual addresses were
> still only 24 bits. Again, useful when more than one program
> is running.
>
>> And by the way, you can have processes that consume a total of more than
>> 2MW on an RSX system. That is what the check point space is for (the RSX
>> word for swapping...)
>
> And there is always overlays, as people used before swapping and paging.
> (The KA-10 allows for swapping but not paging.)

Yes. Overlays are actually another form of demand-paging, but done in
userspace instead of provided by the kernel.

And overlays can be used in combination with swapping, and often is.
However, you seldom see overlays in a demand paging system, for the
simple reason that most demand paging systems have a large address space
to start with, which means overlays are not needed.

> And don't forget RT-11 XM.

I intentionally skipped it, to make the picture simpler. :-)

Johnny

[glen herrmannsfeldt]

Johnny Billquist <b...@softjar.se> wrote:

(snip, I wrote)

>> I think I agree with Rich. You have to make a distinction between
>> virtual addressing and virtual storage. They often go together,
>> but in this case I think you have to keep them separate.

> Uh? I can't make sense of what you wrote. You say you agree with Rich,
> but you seem to agree that demand paging and virtual memory are two
> different things that needs to be kept separate.

I am using "Virtual Addressing" to describe any address mapping
system, and "Virtual Storage" to describe accessing of more
than the physical working memory. (Which may or may not be
bigger than the physical addressing space.)

Describing it that way, "Virtual Memory" is ambiguous.

A big advantage of virtual addressing is reducing the problems
of fragmentation that happen in real addressed multi-user systems
like OS/360 MVT. (It doesn't necessarily avoid framentation
in virtual address space.)

> Or else I'm failing to parse this in yet some other way...

> Virtual addressing, by the way, is just how you address the
> storage. The storage still have to exist, somehow...

> Virtual memory is one concept. Demand paging is another. The two can be
> combined is nice ways, but neither requires the other.

> And the backing storage for virtual memory is physical memory. Of
> course, the virtual memory can also not map to anything at all, at which
> point the OS will get page faults if the process tries to access the
> memory. What happens at that point is another story...

Seems to me that the description of RSX doesn't exclude the
ability to write a paging system.

(snip)

>> For the IBM S/370, where I first knew virtual storage, originally
>> it allowed for full 24 bit addressing when real memory was smaller.
>> In later models, the real addressing space went up to 26 bits
>> (extra bits in page table entries) but virtual addresses were
>> still only 24 bits. Again, useful when more than one program
>> is running.

(snip)

> Yes. Overlays are actually another form of demand-paging, but done in
> userspace instead of provided by the kernel.

> And overlays can be used in combination with swapping, and often is.
> However, you seldom see overlays in a demand paging system, for the
> simple reason that most demand paging systems have a large address space
> to start with, which means overlays are not needed.

Yes. It is not so unusual to run the OS/360 Fortran H compiler
on newer VS systems. (IBM uses VM for Virtual Machine, a different
concept.)

The Fortran H compiler uses overlays, from the non-virtual OS/360.

The solution is to run it through the linkage editor without any
control cards, in which case it comes out without overlays.

The OS/360 and successor linkers are unusual in that they know how
to read their own output (and can do actual editing on it).

-- glen

[Bob Koehler]

In article <mddzj8l...@panix5.panix.com>, Rich Alderson <ne...@alderson.users.panix.com> writes:
>
> Tops-10 actually offered languages and capabilities that TOPS-20 did not (for
> example, COBOL, real-time processing), and had a much smaller memory footprint.

We had many thousands of lines of COBOL on our TOPS-20 systems. It
was the only supported interface to DEC's DBMS at the time. VAXen
weren't used because DEC didn't yet sell a DBMS for them at the time
of purchase (VMS 1.5 timeframe).

[Johnny Billquist]

On 2015-02-11 12:33, glen herrmannsfeldt wrote:
> Johnny Billquist <b...@softjar.se> wrote:
>
> (snip, I wrote)
>
>>> I think I agree with Rich. You have to make a distinction between
>>> virtual addressing and virtual storage. They often go together,
>>> but in this case I think you have to keep them separate.
>
>> Uh? I can't make sense of what you wrote. You say you agree with Rich,
>> but you seem to agree that demand paging and virtual memory are two
>> different things that needs to be kept separate.
>
> I am using "Virtual Addressing" to describe any address mapping
> system, and "Virtual Storage" to describe accessing of more
> than the physical working memory. (Which may or may not be
> bigger than the physical addressing space.)
>
> Describing it that way, "Virtual Memory" is ambiguous.

Ah. I personally find such a distinction meaningless. Who cares if the
virtual address space is larger or smaller than the physical address
space? It an even change with newer iterations of processors, which do
not change change anything but some mapping tables in the OS.

Consider the VAX, for example. The virtual address space is 32 bits. In
the last implementation, the NVAX, the actual physical address space is
34 bits. Do that mean that you do not consider VAX or VMS on the VAX to
have virtual storage then? (Or is it just not virtual storage on the
NVAX, but it is virtual storage on all other VAX models? Or is it only
not virtual storage if you actually use the NVAX extension? Do that mean
that on the same CPU, if you just flip a bit in a configuration
register, but everything in the OS works the same way the whole time, it
changes from using virtual storage to not using virtual storage?)

Virtual storage, in your use, is very vague and subjective. Like I said.
I find such a definition to be useless.

What makes sense it to talk about virtual memory as opposed to physical
memory.

And then we can also talk about tricks such as demand paging.

And RSX still uses virtual memory, but do not use demand paging. The
PDP-11 can support demand paging, if you want to, but with only 8 pages,
and much more physical memory than virtual, you might as well just
assure that all pages are valid whenever the process is executing, and
skip the demand paging work. On machines with much larger virtual
address spaces, and many more pages, it makes more sense to go with
demand paging.

> A big advantage of virtual addressing is reducing the problems
> of fragmentation that happen in real addressed multi-user systems
> like OS/360 MVT. (It doesn't necessarily avoid framentation
> in virtual address space.)

That can be an advantage, under some circumstances. It certainly is not
the case on a PDP-11. However, without virtual addressing, you would not
be able to run several copies of the same program in parallel, since
they would all be addressing the same memory addresses. Were that
physical memory, it would obviously not work.
With virtual memory, it do work. Which is the one totally overwhelming
advantage of virtual memory.

>> Or else I'm failing to parse this in yet some other way...
>
>> Virtual addressing, by the way, is just how you address the
>> storage. The storage still have to exist, somehow...
>
>> Virtual memory is one concept. Demand paging is another. The two can be
>> combined is nice ways, but neither requires the other.
>
>> And the backing storage for virtual memory is physical memory. Of
>> course, the virtual memory can also not map to anything at all, at which
>> point the OS will get page faults if the process tries to access the
>> memory. What happens at that point is another story...
>
> Seems to me that the description of RSX doesn't exclude the
> ability to write a paging system.

You could, but the gains would be small, while adding a lot of
complexity. As it is, RSX do not need to deal with page faults. All the
virtual memory is always mapped before the process can run. When not
running (preempted, waiting, stopped, or whatever), it can be swapped
out of memory, and when it is scheduled again, it must first be read
back in to memory somewhere (obviously don't need to be the same
physical memory addresses as before) before it actually schedules.
And a program can have various shared memory libraries, shared common
regions, and what not, mapped in the virtual address space. So it's not
that all virtual memory have to be in contiguous physical memory either.
But it all needs to be in physical memory before the process can be
scheduled.

Johnny

[glen herrmannsfeldt]

Johnny Billquist <b...@softjar.se> wrote:

(snip, I wrote)
>>>> I think I agree with Rich. You have to make a distinction between
>>>> virtual addressing and virtual storage. They often go together,
>>>> but in this case I think you have to keep them separate.

>>> Uh? I can't make sense of what you wrote. You say you agree with Rich,
>>> but you seem to agree that demand paging and virtual memory are two
>>> different things that needs to be kept separate.

>> I am using "Virtual Addressing" to describe any address mapping
>> system, and "Virtual Storage" to describe accessing of more
>> than the physical working memory. (Which may or may not be
>> bigger than the physical addressing space.)

>> Describing it that way, "Virtual Memory" is ambiguous.

> Ah. I personally find such a distinction meaningless. Who cares if the
> virtual address space is larger or smaller than the physical address
> space? It an even change with newer iterations of processors, which do
> not change change anything but some mapping tables in the OS.

Yes, virtual addressing in both cases.

> Consider the VAX, for example. The virtual address space is 32 bits. In
> the last implementation, the NVAX, the actual physical address space is
> 34 bits. Do that mean that you do not consider VAX or VMS on the VAX to
> have virtual storage then? (Or is it just not virtual storage on the
> NVAX, but it is virtual storage on all other VAX models? Or is it only
> not virtual storage if you actually use the NVAX extension? Do that mean
> that on the same CPU, if you just flip a bit in a configuration
> register, but everything in the OS works the same way the whole time, it
> changes from using virtual storage to not using virtual storage?)

Do they run without any paging disks? Well, the VAX addressing space
is divided up in forths, with I believe only 30 bits available to
user programs. If there are no paging disks, and if executable files
are completely loaded into real storage, when no virtual storage
is being used. (Many now use the executable file as backing store
for its pages.)

> Virtual storage, in your use, is very vague and subjective. Like I said.
> I find such a definition to be useless.

> What makes sense it to talk about virtual memory as opposed
> to physical memory.

> And then we can also talk about tricks such as demand paging.

Virtual storage is what is on disk. You may or may not need
to use it.

> And RSX still uses virtual memory, but do not use demand paging. The
> PDP-11 can support demand paging, if you want to, but with only 8 pages,
> and much more physical memory than virtual, you might as well just
> assure that all pages are valid whenever the process is executing, and
> skip the demand paging work. On machines with much larger virtual
> address spaces, and many more pages, it makes more sense to go with
> demand paging.

(snip)

-- glen

[Johnny Billquist]

On 2015-02-12 15:59, glen herrmannsfeldt wrote:
> Johnny Billquist <b...@softjar.se> wrote:
>
> (snip, I wrote)
>>>>> I think I agree with Rich. You have to make a distinction between
>>>>> virtual addressing and virtual storage. They often go together,
>>>>> but in this case I think you have to keep them separate.
>
>>>> Uh? I can't make sense of what you wrote. You say you agree with Rich,
>>>> but you seem to agree that demand paging and virtual memory are two
>>>> different things that needs to be kept separate.
>
>>> I am using "Virtual Addressing" to describe any address mapping
>>> system, and "Virtual Storage" to describe accessing of more
>>> than the physical working memory. (Which may or may not be
>>> bigger than the physical addressing space.)
>
>>> Describing it that way, "Virtual Memory" is ambiguous.
>
>> Ah. I personally find such a distinction meaningless. Who cares if the
>> virtual address space is larger or smaller than the physical address
>> space? It an even change with newer iterations of processors, which do
>> not change change anything but some mapping tables in the OS.
>
> Yes, virtual addressing in both cases.

Right.

>> Consider the VAX, for example. The virtual address space is 32 bits. In
>> the last implementation, the NVAX, the actual physical address space is
>> 34 bits. Do that mean that you do not consider VAX or VMS on the VAX to
>> have virtual storage then? (Or is it just not virtual storage on the
>> NVAX, but it is virtual storage on all other VAX models? Or is it only
>> not virtual storage if you actually use the NVAX extension? Do that mean
>> that on the same CPU, if you just flip a bit in a configuration
>> register, but everything in the OS works the same way the whole time, it
>> changes from using virtual storage to not using virtual storage?)
>
> Do they run without any paging disks? Well, the VAX addressing space
> is divided up in forths, with I believe only 30 bits available to
> user programs. If there are no paging disks, and if executable files
> are completely loaded into real storage, when no virtual storage
> is being used. (Many now use the executable file as backing store
> for its pages.)

A swap file and a page file is optional. I think you can even
enable/disable those files on the fly, but it's been too long since I
played with VMS to be absolutely sure.

Same is true in Unix, by the way. Having a swap/page file is optional,
and nowadays, people are more and more leaning towards actually not
having one. But yes, you still use the original executable as a source
for paging in.

>> Virtual storage, in your use, is very vague and subjective. Like I said.
>> I find such a definition to be useless.
>
>> What makes sense it to talk about virtual memory as opposed
>> to physical memory.
>
>> And then we can also talk about tricks such as demand paging.
>
> Virtual storage is what is on disk. You may or may not need
> to use it.

Well, in that case RSX still falls in the "virtual storage" box, since
it uses a checkpoint file for swapping to and from.
Actually, it is more complex, as a checkpoint file is not mandatory, and
also, programs can checkpoint to their original image file. But that is
no different than any other OS of today...
The only difference is that RSX do not do demand paging.

So, by your (and Rich?) definition, do RSX do virtual storage or not? I
cannot make any sense of your definition. :-)

It definitely uses virtual addressing, and you can have more processes
and memory regions than you have physical memory. But that is more or
less true of any operating system that supports virtual memory.

Johnny

[Antti Louko]

Johnny Billquist wrote:
> On 2015-02-12 15:59, glen herrmannsfeldt wrote:

>> Do they run without any paging disks? Well, the VAX addressing space
>> is divided up in forths, with I believe only 30 bits available to
>> user programs. If there are no paging disks, and if executable files
>> are completely loaded into real storage, when no virtual storage
>> is being used. (Many now use the executable file as backing store
>> for its pages.)
>
> A swap file and a page file is optional. I think you can even enable/disable those files on the fly, but it's been too
> long since I played with VMS to be absolutely sure.
>
> Same is true in Unix, by the way. Having a swap/page file is optional, and nowadays, people are more and more leaning
> towards actually not having one. But yes, you still use the original executable as a source for paging in.

Or just zero filled virtual pages.

Many years ago we had Mach OS running on VAX3000. It had basically 2GB user virtual space. Mach had quite smart VM
implementation and it was possible and fast to allocate 2GB of zero filled memory region with 24MB of RAM. Only
accessing or writing to the memory finally allocated the memory and forced swapping (or paging) to disk.

[Rich Alderson]

I should have said "TOPS-20 did not offer natively". The COBOL compiler on
TOPS-20 was the Tops-10 binary, and ran under a compatibility package that
emulated Tops-10 system calls with TOPS-20 equivalents. Fortunately, compilers
rarely use esoteric system calls.

[Richard]

[Please do not mail me a copy of your followup]

Rich Alderson <ne...@alderson.users.panix.com> spake the secret code
<mddegpt...@panix5.panix.com> thusly:

>I should have said "TOPS-20 did not offer natively". The COBOL compiler on
>TOPS-20 was the Tops-10 binary, and ran under a compatibility package that
>emulated Tops-10 system calls with TOPS-20 equivalents. Fortunately, compilers
>rarely use esoteric system calls.

Did it emit code that used Tops-10 or TOPS-20 system calls?
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Johnny Billquist]

On 2015-02-15 01:15, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Rich Alderson <ne...@alderson.users.panix.com> spake the secret code
> <mddegpt...@panix5.panix.com> thusly:
>
>> I should have said "TOPS-20 did not offer natively". The COBOL compiler on
>> TOPS-20 was the Tops-10 binary, and ran under a compatibility package that
>> emulated Tops-10 system calls with TOPS-20 equivalents. Fortunately, compilers
>> rarely use esoteric system calls.
>
> Did it emit code that used Tops-10 or TOPS-20 system calls?

The COBOL compiler (as well as other software for Tops-10) still emitted
Tops-10 system calls, even when running under TOPS-20. TOPS-20 had a
special module that caught these system calls, and translated it into
TOPS-20 calls. It's called PA1050. I would definitely expect the
resulting code produced by the compilers to still use Tops-10 system
calls as well, meaning that those binaries also had to be trapped by
PA1050. How would the compiler and runtime system ever be able to emit
TOPS-20 calls, when the compiler and RTS was written for Tops-10?

[glen herrmannsfeldt]

Johnny Billquist <b...@softjar.se> wrote:
> On 2015-02-15 01:15, Richard wrote:

(snip regarding COBOL and TOPS-20)

>> Did it emit code that used Tops-10 or TOPS-20 system calls?

> The COBOL compiler (as well as other software for Tops-10) still emitted
> Tops-10 system calls, even when running under TOPS-20. TOPS-20 had a
> special module that caught these system calls, and translated it into
> TOPS-20 calls. It's called PA1050. I would definitely expect the
> resulting code produced by the compilers to still use Tops-10 system
> calls as well, meaning that those binaries also had to be trapped by
> PA1050. How would the compiler and runtime system ever be able to emit
> TOPS-20 calls, when the compiler and RTS was written for Tops-10?

I agree for the compiler, but it would seem not so hard to rewrite
the library routines, and supply a separate version for TOPS-20 users.

You might even have a TOPS-20 only version, and one that would sense
which system it was running on and adapt accordingly.

(Reminds me of floating point in the early MS-DOS days, when the 8087
was available, but you didn't always know at compile time. You could
compile x87 only, or code that would trap to the emulator, then
overwrite the instruction in memory such that future execution would
go directly to the 8087.)

-- glen

[Johnny Billquist]

On 2015-02-15 16:34, glen herrmannsfeldt wrote:
> Johnny Billquist <b...@softjar.se> wrote:
>> On 2015-02-15 01:15, Richard wrote:
>
> (snip regarding COBOL and TOPS-20)
>
>>> Did it emit code that used Tops-10 or TOPS-20 system calls?
>
>> The COBOL compiler (as well as other software for Tops-10) still emitted
>> Tops-10 system calls, even when running under TOPS-20. TOPS-20 had a
>> special module that caught these system calls, and translated it into
>> TOPS-20 calls. It's called PA1050. I would definitely expect the
>> resulting code produced by the compilers to still use Tops-10 system
>> calls as well, meaning that those binaries also had to be trapped by
>> PA1050. How would the compiler and runtime system ever be able to emit
>> TOPS-20 calls, when the compiler and RTS was written for Tops-10?
>
> I agree for the compiler, but it would seem not so hard to rewrite
> the library routines, and supply a separate version for TOPS-20 users.

You'd also need to check if there is any code directly generated by the
compiler that did something Tops-10 specific, and fix that, or else
you'd end up with a binary that tried to do both...

> You might even have a TOPS-20 only version, and one that would sense
> which system it was running on and adapt accordingly.

At which point you'd have a "native" TOPS-20 compiler, which Rich
claimed did not exist. :-)

> (Reminds me of floating point in the early MS-DOS days, when the 8087
> was available, but you didn't always know at compile time. You could
> compile x87 only, or code that would trap to the emulator, then
> overwrite the instruction in memory such that future execution would
> go directly to the 8087.)

I sortof agree that it would not be an impossible, or perhaps even very
difficult, task to do, but as far as I can tell, DEC did not move those
bits and pieces of software over to TOPS-20. Instead they did the
Tops-10 compatibility handling in TOPS-20 to allow those bits and pieces
to just work.

[G.]

On Sun, 15 Feb 2015 00:15:44 +0000 (UTC), legaliz...@mail.xmission.com
(Richard) wrote:

> >I should have said "TOPS-20 did not offer natively". The COBOL compiler on
> >TOPS-20 was the Tops-10 binary, and ran under a compatibility package that
> >emulated Tops-10 system calls with TOPS-20 equivalents. Fortunately, compilers
> >rarely use esoteric system calls.
>
> Did it emit code that used Tops-10 or TOPS-20 system calls?

Well, as others here, I was almost sure that the TOPS-20 COBOL compiler did run
in TOPS-10 mode and I was going to do some tests just to show you and others
that it did emit TOPS-10 code. But I discovered that it does not seem the case,
at least with the latest COBOL-20 compiler.

Let's see:

| @TYPE TEST01.CBL
| IDENTIFICATION DIVISION.
| PROGRAM-ID. TEST01.
| PROCEDURE DIVISION.
| 000-MAIN.
| DISPLAY "*** TOPS-20 COBOL TEST"
| STOP RUN.
| @COBOL
| COBOL>TEST01/ANSI
| COBOL>EXIT
| @I VER
| TOPS-20 DECnet node VENTI, TOPS-20 Monitor 7(21733)
| TOPS-20 Command processor 7(4453)
| Program is COBOL, version is 13(1653) <--- No UUO simulation
| @EXEC TEST01
| LINK: Loading
| [LNKXCT TEST01 execution]
| *** TOPS-20 COBOL TEST
|
| EXIT
| @I VER
| TOPS-20 DECnet node VENTI, TOPS-20 Monitor 7(21733)
| TOPS-20 Command processor 7(4453)
| Program is TEST01, version is 13(1653) <--- No UUO simulation
| @

Instead, MACRO runs in TOPS-10 mode (as expected!):

| @MACRO
|
| *^Z
| @I VER
| TOPS-20 DECnet node VENTI, TOPS-20 Monitor 7(21733)
| TOPS-20 Command processor 7(4453)
| Program is MACRO, version is 53.2(1252)
| UUO simulation in use, version is 5.1(704) <--- TOPS-10 mode

But! The curious thing I would have not believed is that even FORTRAN got
converted to native TOPS-20 calls and code generation:

| @TYPE TEST02.FOR
| PROGRAM TEST02
| TYPE *,'*** TOPS-20 FORTRAN TEST'
| END
| @FORTRA
| FORTRAN>TEST02
| TEST02
| FORTRAN>EXIT
| @I VER
| TOPS-20 DECnet node VENTI, TOPS-20 Monitor 7(21733)
| TOPS-20 Command processor 7(4453)
| Program is FORTRA, version is 11(4606) <--- No UUO simulation
| @EXEC TEST02
| LINK: Loading
| [LNKXCT TEST02 execution]
| *** TOPS-20 FORTRAN TEST
| CPU time 0.31 Elapsed time 0.31
| @I VER
| TOPS-20 DECnet node VENTI, TOPS-20 Monitor 7(21733)
| TOPS-20 Command processor 7(4453)
| Program is TEST02 <--- No UUO simulation

HTH, :)
G.

[three_jeeps]

OMG, COLBOL?!?!?!?! I thought it finally died in the 70's....I hope it is still not around.....

[Bob Koehler]

In article <mddegpt...@panix5.panix.com>, Rich Alderson <ne...@alderson.users.panix.com> writes:

> I should have said "TOPS-20 did not offer natively". The COBOL compiler on
> TOPS-20 was the Tops-10 binary, and ran under a compatibility package that
> emulated Tops-10 system calls with TOPS-20 equivalents. Fortunately, compilers
> rarely use esoteric system calls.

The compiler may not use those calls, but the I/O library would be in
tough shape if it did neither a TOPS-20 JSYS nor a TOPS-10 UUO.

Of course, that could be burried under non-Cobol-specific layers.

[Bob Koehler]

In article <9a45dffb-d386-4ca3...@googlegroups.com>, three_jeeps <jjh...@gmail.com> writes:
>
> OMG, COLBOL?!?!?!?! I thought it finally died in the 70's....I hope it is still not around.....

Do you still write paper checks?

[Bill Gunshannon]

In article <9a45dffb-d386-4ca3...@googlegroups.com>,
three_jeeps <jjh...@gmail.com> writes:

Do you pay taxes in the US? Do you use a credit card? Do you have
insurance? An IRA? All still being done with COBOL and not likely
to change in my or your lifetime.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>