Discussion:
OS Ancestry
(too old to reply)
Bill Gunshannon
2021-05-13 12:21:06 UTC
Permalink
I have become very curious about the ancestry of VMS. (I am
going to look into some others, but for VMS I do have this
outlet for information!)

Both Primos and Unix came from people recently working on
Multics. Primos went in the same direction as Multics while
Unix appeared to go in a very different direction.

VMS is more similar to Primos than Unix. I have seen it said
that RSX-11 was the immediate parent of VMS. Was that true?
Given that, what is the ancestry going back even further?
Where did VMS actually get its start paradigm-wise?

Anybody here have any of this information?

bill
Arne Vajhøj
2021-05-13 12:52:13 UTC
Permalink
I have become very curious about the ancestry of VMS.  (I am
going to look into some others, but for VMS I do have this
outlet for information!)
Both Primos and Unix came from people recently working on
Multics.  Primos went in the same direction as Multics while
Unix appeared to go in a very different direction.
VMS is more similar to Primos than Unix.  I have seen it said
that RSX-11 was the immediate parent of VMS.  Was that true?
Given that, what is the ancestry going back even further?
Where did VMS actually get its start paradigm-wise?
Anybody here have any of this information?
The story in Wikipedia is:

https://en.wikipedia.org/wiki/OpenVMS

<quote>
In April 1975, Digital Equipment Corporation embarked on a hardware
project, code named Star, to design a 32-bit virtual address extension
to its PDP-11 computer line. A companion software project, code named
Starlet, was started in June 1975 to develop a totally new operating
system, based on RSX-11M, for the Star family of processors. These two
projects were tightly integrated from the beginning. Gordon Bell was the
VP lead on the VAX hardware and its architecture. Roger Gourd was the
project lead for the Starlet program, with software engineers Dave
Cutler (who would later lead development of Microsoft's Windows NT),
Dick Hustvedt, and Peter Lipman acting as the technical project leaders,
each having responsibility for a different area of the operating system.
The Star and Starlet projects culminated in the VAX-11/780 computer and
the VAX/VMS operating system. The Starlet name survived in VMS as a name
of several of the main system libraries, including STARLET.OLB and
STARLET.MLB.
</quote>

https://en.wikipedia.org/wiki/RSX-11

<quote>
RSX-11 is a discontinued family of multi-user real-time operating
systems for PDP-11 computers created by Digital Equipment Corporation.
In widespread use through the late 1970s and early 1980s, RSX-11 was
influential in the development of later operating systems such as VMS
and Windows NT.
...
RSX-11 began as a port to the PDP-11 architecture of the earlier RSX-15
operating system for the PDP-15 minicomputer, first released in 1971.
The main architect for RSX-15 (later renamed XVM/RSX) was Dennis “Dan”
Brevik.
...
The porting effort first produced small paper tape based real-time
executives (RSX-11A, RSX-11C) which later gained limited support for
disks (RSX-11B). RSX-11B then evolved into the fully fledged RSX-11D
disk-based operating system, which first appeared on the PDP-11/40 and
PDP-11/45 in early 1973. The project leader for RSX-11D up to version 4
was Henry Krejci. While RSX-11D was being completed, Digital set out to
adapt it for a small memory footprint giving birth to RSX-11M, first
released in 1973. From 1971 to 1976 the RSX-11M project was spearheaded
by noted operating system designer Dave Cutler, then at his first
project. Principles first tried in RSX-11M appear also in later designs
led by Cutler, DEC's VMS and Microsoft's Windows NT.
</quote>

https://en.wikipedia.org/wiki/PDP-15#RSX-15

<quote>
RSX-15 was released by DEC in 1971. The main architect for RSX-15 (later
renamed XVM/RSX) was Dennis "Dan" Brevik.

Once XVM/RSX was released, DEC facilitated that "a PDP-15 can be
field-upgraded to XVM" but it required "the addition of the XM15 memory
processor."

The RSX-11 operating system began as a port of RSX-15 to the PDP-11,
although it later diverged significantly in terms of design and
functionality.
</quote>

All before my time.

But I do remember that VAX and VMS VAX had some PDP-11 and RSX-11
compatibility mode features.

Arne
Bill Gunshannon
2021-05-13 13:06:33 UTC
Permalink
Post by Arne Vajhøj
I have become very curious about the ancestry of VMS.  (I am
going to look into some others, but for VMS I do have this
outlet for information!)
Both Primos and Unix came from people recently working on
Multics.  Primos went in the same direction as Multics while
Unix appeared to go in a very different direction.
VMS is more similar to Primos than Unix.  I have seen it said
that RSX-11 was the immediate parent of VMS.  Was that true?
Given that, what is the ancestry going back even further?
Where did VMS actually get its start paradigm-wise?
Anybody here have any of this information?
https://en.wikipedia.org/wiki/OpenVMS
<quote>
In April 1975, Digital Equipment Corporation embarked on a hardware
project, code named Star, to design a 32-bit virtual address extension
to its PDP-11 computer line. A companion software project, code named
Starlet, was started in June 1975 to develop a totally new operating
system, based on RSX-11M, for the Star family of processors. These two
projects were tightly integrated from the beginning. Gordon Bell was the
VP lead on the VAX hardware and its architecture. Roger Gourd was the
project lead for the Starlet program, with software engineers Dave
Cutler (who would later lead development of Microsoft's Windows NT),
Dick Hustvedt, and Peter Lipman acting as the technical project leaders,
each having responsibility for a different area of the operating system.
The Star and Starlet projects culminated in the VAX-11/780 computer and
the VAX/VMS operating system. The Starlet name survived in VMS as a name
of several of the main system libraries, including STARLET.OLB and
STARLET.MLB.
</quote>
https://en.wikipedia.org/wiki/RSX-11
<quote>
RSX-11 is a discontinued family of multi-user real-time operating
systems for PDP-11 computers created by Digital Equipment Corporation.
In widespread use through the late 1970s and early 1980s, RSX-11 was
influential in the development of later operating systems such as VMS
and Windows NT.
...
RSX-11 began as a port to the PDP-11 architecture of the earlier RSX-15
operating system for the PDP-15 minicomputer, first released in 1971.
The main architect for RSX-15 (later renamed XVM/RSX) was Dennis “Dan”
Brevik.
...
The porting effort first produced small paper tape based real-time
executives (RSX-11A, RSX-11C) which later gained limited support for
disks (RSX-11B). RSX-11B then evolved into the fully fledged RSX-11D
disk-based operating system, which first appeared on the PDP-11/40 and
PDP-11/45 in early 1973. The project leader for RSX-11D up to version 4
was Henry Krejci. While RSX-11D was being completed, Digital set out to
adapt it for a small memory footprint giving birth to RSX-11M, first
released in 1973. From 1971 to 1976 the RSX-11M project was spearheaded
by noted operating system designer Dave Cutler, then at his first
project. Principles first tried in RSX-11M appear also in later designs
led by Cutler, DEC's VMS and Microsoft's Windows NT.
</quote>
https://en.wikipedia.org/wiki/PDP-15#RSX-15
<quote>
RSX-15 was released by DEC in 1971. The main architect for RSX-15 (later
renamed XVM/RSX) was Dennis "Dan" Brevik.
Once XVM/RSX was released, DEC facilitated that "a PDP-15 can be
field-upgraded to XVM" but it required "the addition of the XM15 memory
processor."
The RSX-11 operating system began as a port of RSX-15 to the PDP-11,
although it later diverged significantly in terms of design and
functionality.
</quote>
All before my time.
But I do remember that VAX and VMS VAX had some PDP-11 and RSX-11
compatibility mode features.
Arne
Thank you. That takes me back a little bit further. But I fear the
very origins, the driving model, may be long lost by this time. I
have a number of very early textbooks on Operating Systems and none
of them describe features common in VMS or RSX. It's really just
curiosity, but I wondered where some of the concepts originated.

bill
Dave Froble
2021-05-13 14:25:26 UTC
Permalink
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Bill Gunshannon
I have become very curious about the ancestry of VMS. (I am
going to look into some others, but for VMS I do have this
outlet for information!)
Both Primos and Unix came from people recently working on
Multics. Primos went in the same direction as Multics while
Unix appeared to go in a very different direction.
VMS is more similar to Primos than Unix. I have seen it said
that RSX-11 was the immediate parent of VMS. Was that true?
Given that, what is the ancestry going back even further?
Where did VMS actually get its start paradigm-wise?
Anybody here have any of this information?
https://en.wikipedia.org/wiki/OpenVMS
<quote>
In April 1975, Digital Equipment Corporation embarked on a hardware
project, code named Star, to design a 32-bit virtual address extension
to its PDP-11 computer line. A companion software project, code named
Starlet, was started in June 1975 to develop a totally new operating
system, based on RSX-11M, for the Star family of processors. These two
projects were tightly integrated from the beginning. Gordon Bell was
the VP lead on the VAX hardware and its architecture. Roger Gourd was
the project lead for the Starlet program, with software engineers Dave
Cutler (who would later lead development of Microsoft's Windows NT),
Dick Hustvedt, and Peter Lipman acting as the technical project
leaders, each having responsibility for a different area of the
operating system. The Star and Starlet projects culminated in the
VAX-11/780 computer and the VAX/VMS operating system. The Starlet name
survived in VMS as a name of several of the main system libraries,
including STARLET.OLB and STARLET.MLB.
</quote>
https://en.wikipedia.org/wiki/RSX-11
<quote>
RSX-11 is a discontinued family of multi-user real-time operating
systems for PDP-11 computers created by Digital Equipment Corporation.
In widespread use through the late 1970s and early 1980s, RSX-11 was
influential in the development of later operating systems such as VMS
and Windows NT.
...
RSX-11 began as a port to the PDP-11 architecture of the earlier
RSX-15 operating system for the PDP-15 minicomputer, first released in
1971. The main architect for RSX-15 (later renamed XVM/RSX) was Dennis
“Dan” Brevik.
...
The porting effort first produced small paper tape based real-time
executives (RSX-11A, RSX-11C) which later gained limited support for
disks (RSX-11B). RSX-11B then evolved into the fully fledged RSX-11D
disk-based operating system, which first appeared on the PDP-11/40 and
PDP-11/45 in early 1973. The project leader for RSX-11D up to version
4 was Henry Krejci. While RSX-11D was being completed, Digital set out
to adapt it for a small memory footprint giving birth to RSX-11M,
first released in 1973. From 1971 to 1976 the RSX-11M project was
spearheaded by noted operating system designer Dave Cutler, then at
his first project. Principles first tried in RSX-11M appear also in
later designs led by Cutler, DEC's VMS and Microsoft's Windows NT.
</quote>
https://en.wikipedia.org/wiki/PDP-15#RSX-15
<quote>
RSX-15 was released by DEC in 1971. The main architect for RSX-15
(later renamed XVM/RSX) was Dennis "Dan" Brevik.
Once XVM/RSX was released, DEC facilitated that "a PDP-15 can be
field-upgraded to XVM" but it required "the addition of the XM15
memory processor."
The RSX-11 operating system began as a port of RSX-15 to the PDP-11,
although it later diverged significantly in terms of design and
functionality.
</quote>
All before my time.
But I do remember that VAX and VMS VAX had some PDP-11 and RSX-11
compatibility mode features.
Arne
Thank you. That takes me back a little bit further. But I fear the
very origins, the driving model, may be long lost by this time. I
have a number of very early textbooks on Operating Systems and none
of them describe features common in VMS or RSX. It's really just
curiosity, but I wondered where some of the concepts originated.
bill
Looking at it from a different perspective ....

Back in 1974 I was introduced to a PDP11/40 running RSTS V04b. At the
time, the only supported language was Basic+, an interpreter.

Where RSTS came from, I don't know, but what I was told was that David
Hart of Evens, Griffith, and Hart wrote the original Basic+. David is
no longer with us, but, perhaps John Santos might have some information
of the earlier days.

While DEC ended up with RSTS and Basic+, what it seemed like to me is
that the software people at DEC considered RSX as a proper OS and RSTS
"that other thing". Perhaps where their NIH started, or, perhaps they
already embraced that concept.

I wasn't a user of RSX at the time, so I really don't have any memories
of it on the PDP11.

Some time after 1974, don't know exactly when, DEC produced some type of
RSX subsystem for RSTS, which allowed MACRO-11, and other RSX languages
to run on RSTS. These included BP2 (Basic Plus 2) which was a compiled
version of Basic Plus.

When VAX and VMS came along, VMS inherited much from RSX, as that seemed
to be the preferred choice for the DEC software people. VAX and VMS was
aimed at the scientific market initially. Only when DEC wanted into the
business market did they start incorporating capabilities from RSTS,
since RSTS was heavily used in the business market.

So yeah, VMS was based initially on RSX, and later had RSTS capabilities
added. The result was something better than the sum of RSX and RSTS.

I never heard any stories of where RSTS came from ...
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-05-13 14:56:39 UTC
Permalink
Post by Dave Froble
Post by Arne Vajhøj
I have become very curious about the ancestry of VMS.  (I am
going to look into some others, but for VMS I do have this
outlet for information!)
Both Primos and Unix came from people recently working on
Multics.  Primos went in the same direction as Multics while
Unix appeared to go in a very different direction.
VMS is more similar to Primos than Unix.  I have seen it said
that RSX-11 was the immediate parent of VMS.  Was that true?
Given that, what is the ancestry going back even further?
Where did VMS actually get its start paradigm-wise?
Anybody here have any of this information?
https://en.wikipedia.org/wiki/OpenVMS
<quote>
In April 1975, Digital Equipment Corporation embarked on a hardware
project, code named Star, to design a 32-bit virtual address extension
to its PDP-11 computer line. A companion software project, code named
Starlet, was started in June 1975 to develop a totally new operating
system, based on RSX-11M, for the Star family of processors. These two
projects were tightly integrated from the beginning. Gordon Bell was
the VP lead on the VAX hardware and its architecture. Roger Gourd was
the project lead for the Starlet program, with software engineers Dave
Cutler (who would later lead development of Microsoft's Windows NT),
Dick Hustvedt, and Peter Lipman acting as the technical project
leaders, each having responsibility for a different area of the
operating system. The Star and Starlet projects culminated in the
VAX-11/780 computer and the VAX/VMS operating system. The Starlet name
survived in VMS as a name of several of the main system libraries,
including STARLET.OLB and STARLET.MLB.
</quote>
https://en.wikipedia.org/wiki/RSX-11
<quote>
RSX-11 is a discontinued family of multi-user real-time operating
systems for PDP-11 computers created by Digital Equipment Corporation.
In widespread use through the late 1970s and early 1980s, RSX-11 was
influential in the development of later operating systems such as VMS
and Windows NT.
...
RSX-11 began as a port to the PDP-11 architecture of the earlier
RSX-15 operating system for the PDP-15 minicomputer, first released in
1971. The main architect for RSX-15 (later renamed XVM/RSX) was Dennis
“Dan” Brevik.
...
The porting effort first produced small paper tape based real-time
executives (RSX-11A, RSX-11C) which later gained limited support for
disks (RSX-11B). RSX-11B then evolved into the fully fledged RSX-11D
disk-based operating system, which first appeared on the PDP-11/40 and
PDP-11/45 in early 1973. The project leader for RSX-11D up to version
4 was Henry Krejci. While RSX-11D was being completed, Digital set out
to adapt it for a small memory footprint giving birth to RSX-11M,
first released in 1973. From 1971 to 1976 the RSX-11M project was
spearheaded by noted operating system designer Dave Cutler, then at
his first project. Principles first tried in RSX-11M appear also in
later designs led by Cutler, DEC's VMS and Microsoft's Windows NT.
</quote>
https://en.wikipedia.org/wiki/PDP-15#RSX-15
<quote>
RSX-15 was released by DEC in 1971. The main architect for RSX-15
(later renamed XVM/RSX) was Dennis "Dan" Brevik.
Once XVM/RSX was released, DEC facilitated that "a PDP-15 can be
field-upgraded to XVM" but it required "the addition of the XM15
memory processor."
The RSX-11 operating system began as a port of RSX-15 to the PDP-11,
although it later diverged significantly in terms of design and
functionality.
</quote>
All before my time.
But I do remember that VAX and VMS VAX had some PDP-11 and RSX-11
compatibility mode features.
Arne
Thank you.  That takes me back a little bit further.  But I fear the
very origins, the driving model, may be long lost by this time.  I
have a number of very early textbooks on Operating Systems and none
of them describe features common in VMS or RSX.  It's really just
curiosity, but I wondered where some of the concepts originated.
bill
Looking at it from a different perspective ....
Back in 1974 I was introduced to a PDP11/40 running RSTS V04b.  At the
time, the only supported language was Basic+, an interpreter.
Where RSTS came from, I don't know, but what I was told was that David
Hart of Evens, Griffith, and Hart wrote the original Basic+.  David is
no longer with us, but, perhaps John Santos might have some information
of the earlier days.
While DEC ended up with RSTS and Basic+, what it seemed like to me is
that the software people at DEC considered RSX as a proper OS and RSTS
"that other thing".  Perhaps where their NIH started, or, perhaps they
already embraced that concept.
I wasn't a user of RSX at the time, so I really don't have any memories
of it on the PDP11.
Some time after 1974, don't know exactly when, DEC produced some type of
RSX subsystem for RSTS, which allowed MACRO-11, and other RSX languages
to run on RSTS.  These included BP2 (Basic Plus 2) which was a compiled
version of Basic Plus.
When VAX and VMS came along, VMS inherited much from RSX, as that seemed
to be the preferred choice for the DEC software people.  VAX and VMS was
aimed at the scientific market initially.  Only when DEC wanted into the
business market did they start incorporating capabilities from RSTS,
since RSTS was heavily used in the business market.
So yeah, VMS was based initially on RSX, and later had RSTS capabilities
added.  The result was something better than the sum of RSX and RSTS.
I never heard any stories of where RSTS came from ...
https://en.wikipedia.org/wiki/RSTS/E

<quote>
RSTS (/ˈrɪstɪs/) is a multi-user time-sharing operating system,
initially developed by Evans Griffiths & Hart of Boston, and acquired by
Digital Equipment Corporation (DEC, now part of Hewlett Packard) for the
PDP-11 series of 16-bit minicomputers. The first version of RSTS
(RSTS-11, Version 1) was implemented in 1970 by DEC software engineers
that developed the TSS-8 time-sharing operating system for the PDP-8.

...

1970s

The kernel of RSTS was programmed in the assembly language MACRO-11,
compiled and installed to a disk using the CILUS program, running on a
DOS-11 operating system. RSTS booted into an extended version of the
BASIC programming language which DEC called "BASIC-PLUS". All of the
system software CUSPS for the operating system, including the programs
for resource accounting, login, logout, and managing the system, were
written in BASIC-PLUS. From 1970 to 1973, RSTS ran in only 56K bytes of
magnetic core memory (64 kilobytes including the memory-mapped I/O
space). This would allow a system to have up to 16 terminals with a
maximum of 17 jobs. The maximum program size was 16K bytes. By the end
of 1973 DEC estimated there were 150 licensed systems running RSTS.

In 1973 memory management support was included in RSTS (now RSTS/E) for
the newer DEC PDP-11/40 and PDP-11/45 minicomputers (the PDP-11/20 was
only supported under RSTS-11). The introduction of memory management in
the newer PDP-11 computers not only meant these machines were able to
address four times the amount of memory (18-bit addressing, 256K bytes),
it also paved the way for the developers to separate user mode processes
from the core of the kernel.

In 1975 memory management support was again updated for the newer 22-bit
addressable PDP-11/70. RSTS systems could now be expanded to use as much
as two megabytes of memory running up to 63 jobs. The RTS and CCL
concepts were introduced although they had to be compiled in during
"SYSGEN". Multi-terminal service was introduced which would allow a
single job the ability to control multiple terminals (128 total).
Large-message send/receive and interprocess communication became very
sophisticated and efficient. By August there are 1,200 licensed systems.

In 1977 the installation process for RSTS was no longer dependent on
DOS-11. The RSTS kernel could now be compiled under the RT-11 RTS,
formatted as a kernel file with RT-11 SILUS, and copied to the system or
other disks, while the computer was time-sharing. The BASIC-PLUS RTS (as
well as RT-11, RSX-11, TECO and third party RTSs) all ran as user mode
processes, independent of the RSTS kernel. A systems manager could now
decide during the bootstrap phase which RTS to run as the systems
default KBM. By now, there were some 3,100 licensed systems.

In 1978 the final memory management update was included for all machines
that could support 22bit addressing. RSTS could now use the maximum
amount of memory available to a PDP-11 (4 megabytes). Support was also
included for SUPERVISORY mode which made RSTS the first DEC operating
system with this capability. DECnet was also supported as well as remote
diagnostics from field service technicians at the RDC in Colorado
Springs, Colorado (a DEC subscription service). By the end of the
decade, there are over 5,000 licensed systems.

...

BASIC-PLUS
Programs written in BASIC-PLUS ran under the BASIC RTS, which allowed
them up to 32K bytes of memory (out of 64K total). The language was
interpreted, each different keyword being internally converted to a
unique byte code and the variables and data being indexed and stored
separately within the memory space. The internal byte-code format was
known as PCODE - when the interactive SAVE command was issued, the BASIC
Plus RTS simply saved the working memory area to a disk file with a
".BAC" extension. Although this format was undocumented, two Electronic
Engineering undergraduates from Southampton University in the UK (Nick
de Smith and David Garrod) developed a decompiler that could reverse
engineer BAC files into their original BASIC Plus source, complete with
original line numbers and variable names (both subsequently worked for
DEC). The rest of the memory was used by the BASIC RTS itself. If one
wrote programs in a language that permitted true binary executables such
as BASIC-Plus-2, FORTRAN-IV, or Macro Assembler, then the amount of
memory available would be 56K (8K allocated to the RTS).
</quote>

https://en.wikipedia.org/wiki/BASIC-PLUS

<quote>
BASIC-PLUS is an extended dialect of the BASIC programming language that
was developed by Digital Equipment Corporation (DEC) for use on its
RSTS/E time-sharing operating system for the PDP-11 series of 16-bit
minicomputers in the early 1970s through the 1980s.

BASIC-PLUS was based on BASIC-8 for the TSS/8, itself based very closely
on the original Dartmouth BASIC. BASIC-PLUS added a number of new
structures, as well as features from JOSS concerning conditional
statements and formatting. In turn, BASIC-PLUS was the version on which
the original Microsoft BASIC was patterned.

The language was later rewritten as a true compiler as BASIC-Plus-2, and
was ported to the VAX-11 platform as that machine's native BASIC
implementation. This version survived several platform changes, and is
today known as VSI BASIC for OpenVMS.

...

Syntax and features

BASIC-PLUS is patterned closely on later versions of Dartmouth BASIC,
including its powerful MAT commands. On top of this, DEC added a number
of unique flow-control structures.

Line numbers were positive integers from 1 to 32767.
</quote>

Again way before my time.

Arne
Rich Alderson
2021-05-14 01:14:55 UTC
Permalink
=?UTF-8?Q?Arne_Vajh=c3=b8j?= <***@vajhoej.dk> writes:

[ snip ]
Post by Arne Vajhøj
https://en.wikipedia.org/wiki/BASIC-PLUS
<quote>
BASIC-PLUS is an extended dialect of the BASIC programming language that
was developed by Digital Equipment Corporation (DEC) for use on its
RSTS/E time-sharing operating system for the PDP-11 series of 16-bit
minicomputers in the early 1970s through the 1980s.
BASIC-PLUS was based on BASIC-8 for the TSS/8, itself based very closely
on the original Dartmouth BASIC. BASIC-PLUS added a number of new
structures, as well as features from JOSS concerning conditional
statements and formatting. In turn, BASIC-PLUS was the version on which
the original Microsoft BASIC was patterned.
Wrong.

Microsoft BASIC (originally "Altair BASIC") was based on the BASIC for the
PDP-10 (later rechristened the "DECsystem-10" when a new processor, the KI-10,
was introducec). Bill Gates and Paul Allen learned BASIC first on a GE-635
running GECOS (on the GE Information Systems network), then expanded their use
on a PDP-10 in Seattle.

DISCLAIMER: I worked for Paul Allen for 15 years, building his computer museum,
and was a first reader for his autobiography, so I'm very well aware of where
he learned BASIC. In point of fact, neither of them ever programmed on a
PDP-11 (personal communication from PGA).
--
Rich Alderson ***@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
Arne Vajhøj
2021-05-14 18:18:35 UTC
Permalink
Post by Rich Alderson
[ snip ]
Post by Arne Vajhøj
https://en.wikipedia.org/wiki/BASIC-PLUS
<quote>
BASIC-PLUS is an extended dialect of the BASIC programming language that
was developed by Digital Equipment Corporation (DEC) for use on its
RSTS/E time-sharing operating system for the PDP-11 series of 16-bit
minicomputers in the early 1970s through the 1980s.
BASIC-PLUS was based on BASIC-8 for the TSS/8, itself based very closely
on the original Dartmouth BASIC. BASIC-PLUS added a number of new
structures, as well as features from JOSS concerning conditional
statements and formatting. In turn, BASIC-PLUS was the version on which
the original Microsoft BASIC was patterned.
Wrong.
Microsoft BASIC (originally "Altair BASIC") was based on the BASIC for the
PDP-10 (later rechristened the "DECsystem-10" when a new processor, the KI-10,
was introducec). Bill Gates and Paul Allen learned BASIC first on a GE-635
running GECOS (on the GE Information Systems network), then expanded their use
on a PDP-10 in Seattle.
DISCLAIMER: I worked for Paul Allen for 15 years, building his computer museum,
and was a first reader for his autobiography, so I'm very well aware of where
he learned BASIC. In point of fact, neither of them ever programmed on a
PDP-11 (personal communication from PGA).
https://en.wikipedia.org/wiki/Microsoft_BASIC

explains where the story come from.

<quote>
The Altair BASIC interpreter was developed by Microsoft founders Paul
Allen and Bill Gates using a self-made Intel 8080 emulator running on a
PDP-10 minicomputer.[1] The MS dialect is patterned on Digital Equipment
Corporation's BASIC-PLUS on the PDP-11, which Gates had used in high
school.[2] The first versions supported integer math only, but Monte
Davidoff convinced them that floating-point arithmetic was possible, and
wrote a library which became the Microsoft Binary Format.
</quote>

2. Manes, Stephen (1993). Gates. Doubleday. p. 61. ISBN 9780385420754.

Arne
Rich Alderson
2021-05-14 23:11:45 UTC
Permalink
Post by Arne Vajhøj
Post by Rich Alderson
Microsoft BASIC (originally "Altair BASIC") was based on the BASIC for the
PDP-10 (later rechristened the "DECsystem-10" when a new processor, the KI-10,
was introducec). Bill Gates and Paul Allen learned BASIC first on a GE-635
running GECOS (on the GE Information Systems network), then expanded their use
on a PDP-10 in Seattle.
DISCLAIMER: I worked for Paul Allen for 15 years, building his computer museum,
and was a first reader for his autobiography, so I'm very well aware of where
he learned BASIC. In point of fact, neither of them ever programmed on a
PDP-11 (personal communication from PGA).
https://en.wikipedia.org/wiki/Microsoft_BASIC
explains where the story come from.
<quote>
The Altair BASIC interpreter was developed by Microsoft founders Paul
Allen and Bill Gates using a self-made Intel 8080 emulator running on a
PDP-10 minicomputer.[1] The MS dialect is patterned on Digital Equipment
Corporation's BASIC-PLUS on the PDP-11, which Gates had used in high
school.[2] The first versions supported integer math only, but Monte
Davidoff convinced them that floating-point arithmetic was possible, and
wrote a library which became the Microsoft Binary Format.
</quote>
2. Manes, Stephen (1993). Gates. Doubleday. p. 61. ISBN 9780385420754.
I stand by my access to the authors of MS BASIC rather than an third party who
does not understand that BASIC for the PDP-11

*DID NOT EXIST WHEN THEY WERE IN HIGH SCHOOL*.

Wikipedia is very often wrong.
--
Rich Alderson ***@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
Arne Vajhøj
2021-05-14 23:25:32 UTC
Permalink
Post by Rich Alderson
Post by Arne Vajhøj
Post by Rich Alderson
Microsoft BASIC (originally "Altair BASIC") was based on the BASIC for the
PDP-10 (later rechristened the "DECsystem-10" when a new processor, the KI-10,
was introducec). Bill Gates and Paul Allen learned BASIC first on a GE-635
running GECOS (on the GE Information Systems network), then expanded their use
on a PDP-10 in Seattle.
DISCLAIMER: I worked for Paul Allen for 15 years, building his computer museum,
and was a first reader for his autobiography, so I'm very well aware of where
he learned BASIC. In point of fact, neither of them ever programmed on a
PDP-11 (personal communication from PGA).
https://en.wikipedia.org/wiki/Microsoft_BASIC
explains where the story come from.
<quote>
The Altair BASIC interpreter was developed by Microsoft founders Paul
Allen and Bill Gates using a self-made Intel 8080 emulator running on a
PDP-10 minicomputer.[1] The MS dialect is patterned on Digital Equipment
Corporation's BASIC-PLUS on the PDP-11, which Gates had used in high
school.[2] The first versions supported integer math only, but Monte
Davidoff convinced them that floating-point arithmetic was possible, and
wrote a library which became the Microsoft Binary Format.
</quote>
2. Manes, Stephen (1993). Gates. Doubleday. p. 61. ISBN 9780385420754.
I stand by my access to the authors of MS BASIC rather than an third party who
does not understand that BASIC for the PDP-11
*DID NOT EXIST WHEN THEY WERE IN HIGH SCHOOL*.
Wikipedia is very often wrong.
And in this case it claims that Basic+ goes back to 1970
and Bill Gates graduated high school in 1973.

Arne
Rich Alderson
2021-05-15 23:28:39 UTC
Permalink
Post by Arne Vajhøj
And in this case it claims that Basic+ goes back to 1970
and Bill Gates graduated high school in 1973.
I repeat: Neither Bill Gates nor Paul Allen programmed on a PDP-11, in high
school or after graduation.
--
Rich Alderson ***@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
Dave Froble
2021-05-14 23:23:44 UTC
Permalink
Post by Arne Vajhøj
Post by Rich Alderson
[ snip ]
Post by Arne Vajhøj
https://en.wikipedia.org/wiki/BASIC-PLUS
<quote>
BASIC-PLUS is an extended dialect of the BASIC programming language that
was developed by Digital Equipment Corporation (DEC) for use on its
RSTS/E time-sharing operating system for the PDP-11 series of 16-bit
minicomputers in the early 1970s through the 1980s.
BASIC-PLUS was based on BASIC-8 for the TSS/8, itself based very closely
on the original Dartmouth BASIC. BASIC-PLUS added a number of new
structures, as well as features from JOSS concerning conditional
statements and formatting. In turn, BASIC-PLUS was the version on which
the original Microsoft BASIC was patterned.
Wrong.
Microsoft BASIC (originally "Altair BASIC") was based on the BASIC for the
PDP-10 (later rechristened the "DECsystem-10" when a new processor, the KI-10,
was introducec). Bill Gates and Paul Allen learned BASIC first on a GE-635
running GECOS (on the GE Information Systems network), then expanded their use
on a PDP-10 in Seattle.
DISCLAIMER: I worked for Paul Allen for 15 years, building his computer museum,
and was a first reader for his autobiography, so I'm very well aware of where
he learned BASIC. In point of fact, neither of them ever programmed on a
PDP-11 (personal communication from PGA).
https://en.wikipedia.org/wiki/Microsoft_BASIC
explains where the story come from.
<quote>
The Altair BASIC interpreter was developed by Microsoft founders Paul
Allen and Bill Gates using a self-made Intel 8080 emulator running on a
PDP-10 minicomputer.[1] The MS dialect is patterned on Digital Equipment
Corporation's BASIC-PLUS on the PDP-11, which Gates had used in high
school.[2] The first versions supported integer math only, but Monte
Davidoff convinced them that floating-point arithmetic was possible, and
wrote a library which became the Microsoft Binary Format.
</quote>
2. Manes, Stephen (1993). Gates. Doubleday. p. 61. ISBN 9780385420754.
Arne
Not everything on Wikipedia is correct. I've found things about me that
were incorrect.

As for Gates and Allen, I remember their work on that version of Basic.
The reason I remember it so well, is because they didn't use bytes for
some things, they used nibbles. Memory was rather valuable in those days.

I can also say that there is much difference between that Basic and
Basic Plus.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
ni...@desmith.net
2022-03-15 10:32:07 UTC
Permalink
Nice to get a mention in that. It was 40 years ago and the first bit of commercial s/w I wrote!

Nick
Post by Arne Vajhøj
https://en.wikipedia.org/wiki/RSTS/E
<quote>
RSTS (/ˈrɪstɪs/) is a multi-user time-sharing operating system,
initially developed by Evans Griffiths & Hart of Boston, and acquired by
Digital Equipment Corporation (DEC, now part of Hewlett Packard) for the
PDP-11 series of 16-bit minicomputers. The first version of RSTS
(RSTS-11, Version 1) was implemented in 1970 by DEC software engineers
that developed the TSS-8 time-sharing operating system for the PDP-8.
...
1970s
The kernel of RSTS was programmed in the assembly language MACRO-11,
compiled and installed to a disk using the CILUS program, running on a
DOS-11 operating system. RSTS booted into an extended version of the
BASIC programming language which DEC called "BASIC-PLUS". All of the
system software CUSPS for the operating system, including the programs
for resource accounting, login, logout, and managing the system, were
written in BASIC-PLUS. From 1970 to 1973, RSTS ran in only 56K bytes of
magnetic core memory (64 kilobytes including the memory-mapped I/O
space). This would allow a system to have up to 16 terminals with a
maximum of 17 jobs. The maximum program size was 16K bytes. By the end
of 1973 DEC estimated there were 150 licensed systems running RSTS.
In 1973 memory management support was included in RSTS (now RSTS/E) for
the newer DEC PDP-11/40 and PDP-11/45 minicomputers (the PDP-11/20 was
only supported under RSTS-11). The introduction of memory management in
the newer PDP-11 computers not only meant these machines were able to
address four times the amount of memory (18-bit addressing, 256K bytes),
it also paved the way for the developers to separate user mode processes
from the core of the kernel.
In 1975 memory management support was again updated for the newer 22-bit
addressable PDP-11/70. RSTS systems could now be expanded to use as much
as two megabytes of memory running up to 63 jobs. The RTS and CCL
concepts were introduced although they had to be compiled in during
"SYSGEN". Multi-terminal service was introduced which would allow a
single job the ability to control multiple terminals (128 total).
Large-message send/receive and interprocess communication became very
sophisticated and efficient. By August there are 1,200 licensed systems.
In 1977 the installation process for RSTS was no longer dependent on
DOS-11. The RSTS kernel could now be compiled under the RT-11 RTS,
formatted as a kernel file with RT-11 SILUS, and copied to the system or
other disks, while the computer was time-sharing. The BASIC-PLUS RTS (as
well as RT-11, RSX-11, TECO and third party RTSs) all ran as user mode
processes, independent of the RSTS kernel. A systems manager could now
decide during the bootstrap phase which RTS to run as the systems
default KBM. By now, there were some 3,100 licensed systems.
In 1978 the final memory management update was included for all machines
that could support 22bit addressing. RSTS could now use the maximum
amount of memory available to a PDP-11 (4 megabytes). Support was also
included for SUPERVISORY mode which made RSTS the first DEC operating
system with this capability. DECnet was also supported as well as remote
diagnostics from field service technicians at the RDC in Colorado
Springs, Colorado (a DEC subscription service). By the end of the
decade, there are over 5,000 licensed systems.
...
BASIC-PLUS
Programs written in BASIC-PLUS ran under the BASIC RTS, which allowed
them up to 32K bytes of memory (out of 64K total). The language was
interpreted, each different keyword being internally converted to a
unique byte code and the variables and data being indexed and stored
separately within the memory space. The internal byte-code format was
known as PCODE - when the interactive SAVE command was issued, the BASIC
Plus RTS simply saved the working memory area to a disk file with a
".BAC" extension. Although this format was undocumented, two Electronic
Engineering undergraduates from Southampton University in the UK (Nick
de Smith and David Garrod) developed a decompiler that could reverse
engineer BAC files into their original BASIC Plus source, complete with
original line numbers and variable names (both subsequently worked for
DEC). The rest of the memory was used by the BASIC RTS itself. If one
wrote programs in a language that permitted true binary executables such
as BASIC-Plus-2, FORTRAN-IV, or Macro Assembler, then the amount of
memory available would be 56K (8K allocated to the RTS).
</quote>
https://en.wikipedia.org/wiki/BASIC-PLUS
<quote>
BASIC-PLUS is an extended dialect of the BASIC programming language that
was developed by Digital Equipment Corporation (DEC) for use on its
RSTS/E time-sharing operating system for the PDP-11 series of 16-bit
minicomputers in the early 1970s through the 1980s.
BASIC-PLUS was based on BASIC-8 for the TSS/8, itself based very closely
on the original Dartmouth BASIC. BASIC-PLUS added a number of new
structures, as well as features from JOSS concerning conditional
statements and formatting. In turn, BASIC-PLUS was the version on which
the original Microsoft BASIC was patterned.
The language was later rewritten as a true compiler as BASIC-Plus-2, and
was ported to the VAX-11 platform as that machine's native BASIC
implementation. This version survived several platform changes, and is
today known as VSI BASIC for OpenVMS.
...
Syntax and features
BASIC-PLUS is patterned closely on later versions of Dartmouth BASIC,
including its powerful MAT commands. On top of this, DEC added a number
of unique flow-control structures.
Line numbers were positive integers from 1 to 32767.
</quote>
Again way before my time.
Arne
Henry Crun
2022-03-15 12:06:07 UTC
Permalink
Post by ***@desmith.net
Nice to get a mention in that. It was 40 years ago and the first bit of commercial s/w I wrote!
Nick
Post by Arne Vajhøj
https://en.wikipedia.org/wiki/RSTS/E
<quote>
RSTS (/ˈrɪstɪs/) is a multi-user time-sharing operating system,
initially developed by Evans Griffiths & Hart of Boston, and acquired by
Digital Equipment Corporation (DEC, now part of Hewlett Packard) for the
PDP-11 series of 16-bit minicomputers. The first version of RSTS
(RSTS-11, Version 1) was implemented in 1970 by DEC software engineers
that developed the TSS-8 time-sharing operating system for the PDP-8.
...
1970s
The kernel of RSTS was programmed in the assembly language MACRO-11,
compiled and installed to a disk using the CILUS program, running on a
DOS-11 operating system. RSTS booted into an extended version of the
BASIC programming language which DEC called "BASIC-PLUS". All of the
system software CUSPS for the operating system, including the programs
for resource accounting, login, logout, and managing the system, were
written in BASIC-PLUS. From 1970 to 1973, RSTS ran in only 56K bytes of
magnetic core memory (64 kilobytes including the memory-mapped I/O
space). This would allow a system to have up to 16 terminals with a
maximum of 17 jobs. The maximum program size was 16K bytes. By the end
of 1973 DEC estimated there were 150 licensed systems running RSTS.
In 1973 memory management support was included in RSTS (now RSTS/E) for
the newer DEC PDP-11/40 and PDP-11/45 minicomputers (the PDP-11/20 was
only supported under RSTS-11). The introduction of memory management in
the newer PDP-11 computers not only meant these machines were able to
address four times the amount of memory (18-bit addressing, 256K bytes),
it also paved the way for the developers to separate user mode processes
from the core of the kernel.
In 1975 memory management support was again updated for the newer 22-bit
addressable PDP-11/70. RSTS systems could now be expanded to use as much
as two megabytes of memory running up to 63 jobs. The RTS and CCL
concepts were introduced although they had to be compiled in during
"SYSGEN". Multi-terminal service was introduced which would allow a
single job the ability to control multiple terminals (128 total).
Large-message send/receive and interprocess communication became very
sophisticated and efficient. By August there are 1,200 licensed systems.
In 1977 the installation process for RSTS was no longer dependent on
DOS-11. The RSTS kernel could now be compiled under the RT-11 RTS,
formatted as a kernel file with RT-11 SILUS, and copied to the system or
other disks, while the computer was time-sharing. The BASIC-PLUS RTS (as
well as RT-11, RSX-11, TECO and third party RTSs) all ran as user mode
processes, independent of the RSTS kernel. A systems manager could now
decide during the bootstrap phase which RTS to run as the systems
default KBM. By now, there were some 3,100 licensed systems.
In 1978 the final memory management update was included for all machines
that could support 22bit addressing. RSTS could now use the maximum
amount of memory available to a PDP-11 (4 megabytes). Support was also
included for SUPERVISORY mode which made RSTS the first DEC operating
system with this capability. DECnet was also supported as well as remote
diagnostics from field service technicians at the RDC in Colorado
Springs, Colorado (a DEC subscription service). By the end of the
decade, there are over 5,000 licensed systems.
...
BASIC-PLUS
Programs written in BASIC-PLUS ran under the BASIC RTS, which allowed
them up to 32K bytes of memory (out of 64K total). The language was
interpreted, each different keyword being internally converted to a
unique byte code and the variables and data being indexed and stored
separately within the memory space. The internal byte-code format was
known as PCODE - when the interactive SAVE command was issued, the BASIC
Plus RTS simply saved the working memory area to a disk file with a
".BAC" extension. Although this format was undocumented, two Electronic
Engineering undergraduates from Southampton University in the UK (Nick
de Smith and David Garrod) developed a decompiler that could reverse
engineer BAC files into their original BASIC Plus source, complete with
original line numbers and variable names (both subsequently worked for
DEC). The rest of the memory was used by the BASIC RTS itself. If one
wrote programs in a language that permitted true binary executables such
as BASIC-Plus-2, FORTRAN-IV, or Macro Assembler, then the amount of
memory available would be 56K (8K allocated to the RTS).
</quote>
https://en.wikipedia.org/wiki/BASIC-PLUS
<quote>
BASIC-PLUS is an extended dialect of the BASIC programming language that
was developed by Digital Equipment Corporation (DEC) for use on its
RSTS/E time-sharing operating system for the PDP-11 series of 16-bit
minicomputers in the early 1970s through the 1980s.
BASIC-PLUS was based on BASIC-8 for the TSS/8, itself based very closely
on the original Dartmouth BASIC. BASIC-PLUS added a number of new
structures, as well as features from JOSS concerning conditional
statements and formatting. In turn, BASIC-PLUS was the version on which
the original Microsoft BASIC was patterned.
The language was later rewritten as a true compiler as BASIC-Plus-2, and
was ported to the VAX-11 platform as that machine's native BASIC
implementation. This version survived several platform changes, and is
today known as VSI BASIC for OpenVMS.
...
Syntax and features
BASIC-PLUS is patterned closely on later versions of Dartmouth BASIC,
including its powerful MAT commands. On top of this, DEC added a number
of unique flow-control structures.
Line numbers were positive integers from 1 to 32767.
</quote>
Again way before my time.
Arne
Story goes:

Programmer entered a BASIC program
1! PROGRAM NAME
32767 end

and could then report to his manager:
"Program is ready, just a few lines missing in the middle..."
--
Mike R.
Home: http://alpha.mike-r.com/
QOTD: http://alpha.mike-r.com/qotd.php
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before
and: http://alpha.mike-r.com/jargon/T/top-post.html
Missile address: N31.7624/E34.9691
Jeffrey H. Coffield
2021-05-13 16:15:20 UTC
Permalink
Post by Dave Froble
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Bill Gunshannon
I have become very curious about the ancestry of VMS. (I am
going to look into some others, but for VMS I do have this
outlet for information!)
Both Primos and Unix came from people recently working on
Multics. Primos went in the same direction as Multics while
Unix appeared to go in a very different direction.
VMS is more similar to Primos than Unix. I have seen it said
that RSX-11 was the immediate parent of VMS. Was that true?
Given that, what is the ancestry going back even further?
Where did VMS actually get its start paradigm-wise?
Anybody here have any of this information?
https://en.wikipedia.org/wiki/OpenVMS
<quote>
In April 1975, Digital Equipment Corporation embarked on a hardware
project, code named Star, to design a 32-bit virtual address extension
to its PDP-11 computer line. A companion software project, code named
Starlet, was started in June 1975 to develop a totally new operating
system, based on RSX-11M, for the Star family of processors. These two
projects were tightly integrated from the beginning. Gordon Bell was
the VP lead on the VAX hardware and its architecture. Roger Gourd was
the project lead for the Starlet program, with software engineers Dave
Cutler (who would later lead development of Microsoft's Windows NT),
Dick Hustvedt, and Peter Lipman acting as the technical project
leaders, each having responsibility for a different area of the
operating system. The Star and Starlet projects culminated in the
VAX-11/780 computer and the VAX/VMS operating system. The Starlet name
survived in VMS as a name of several of the main system libraries,
including STARLET.OLB and STARLET.MLB.
</quote>
https://en.wikipedia.org/wiki/RSX-11
<quote>
RSX-11 is a discontinued family of multi-user real-time operating
systems for PDP-11 computers created by Digital Equipment Corporation.
In widespread use through the late 1970s and early 1980s, RSX-11 was
influential in the development of later operating systems such as VMS
and Windows NT.
...
RSX-11 began as a port to the PDP-11 architecture of the earlier
RSX-15 operating system for the PDP-15 minicomputer, first released in
1971. The main architect for RSX-15 (later renamed XVM/RSX) was Dennis
“Dan” Brevik.
...
The porting effort first produced small paper tape based real-time
executives (RSX-11A, RSX-11C) which later gained limited support for
disks (RSX-11B). RSX-11B then evolved into the fully fledged RSX-11D
disk-based operating system, which first appeared on the PDP-11/40 and
PDP-11/45 in early 1973. The project leader for RSX-11D up to version
4 was Henry Krejci. While RSX-11D was being completed, Digital set out
to adapt it for a small memory footprint giving birth to RSX-11M,
first released in 1973. From 1971 to 1976 the RSX-11M project was
spearheaded by noted operating system designer Dave Cutler, then at
his first project. Principles first tried in RSX-11M appear also in
later designs led by Cutler, DEC's VMS and Microsoft's Windows NT.
</quote>
https://en.wikipedia.org/wiki/PDP-15#RSX-15
<quote>
RSX-15 was released by DEC in 1971. The main architect for RSX-15
(later renamed XVM/RSX) was Dennis "Dan" Brevik.
Once XVM/RSX was released, DEC facilitated that "a PDP-15 can be
field-upgraded to XVM" but it required "the addition of the XM15
memory processor."
The RSX-11 operating system began as a port of RSX-15 to the PDP-11,
although it later diverged significantly in terms of design and
functionality.
</quote>
All before my time.
But I do remember that VAX and VMS VAX had some PDP-11 and RSX-11
compatibility mode features.
Arne
Thank you. That takes me back a little bit further. But I fear the
very origins, the driving model, may be long lost by this time. I
have a number of very early textbooks on Operating Systems and none
of them describe features common in VMS or RSX. It's really just
curiosity, but I wondered where some of the concepts originated.
bill
Looking at it from a different perspective ....
Back in 1974 I was introduced to a PDP11/40 running RSTS V04b. At the
time, the only supported language was Basic+, an interpreter.
Where RSTS came from, I don't know, but what I was told was that David
Hart of Evens, Griffith, and Hart wrote the original Basic+. David is
no longer with us, but, perhaps John Santos might have some information
of the earlier days.
While DEC ended up with RSTS and Basic+, what it seemed like to me is
that the software people at DEC considered RSX as a proper OS and RSTS
"that other thing". Perhaps where their NIH started, or, perhaps they
already embraced that concept.
I wasn't a user of RSX at the time, so I really don't have any memories
of it on the PDP11.
Some time after 1974, don't know exactly when, DEC produced some type of
RSX subsystem for RSTS, which allowed MACRO-11, and other RSX languages
to run on RSTS. These included BP2 (Basic Plus 2) which was a compiled
version of Basic Plus.
When VAX and VMS came along, VMS inherited much from RSX, as that seemed
to be the preferred choice for the DEC software people. VAX and VMS was
aimed at the scientific market initially. Only when DEC wanted into the
business market did they start incorporating capabilities from RSTS,
since RSTS was heavily used in the business market.
So yeah, VMS was based initially on RSX, and later had RSTS capabilities
added. The result was something better than the sum of RSX and RSTS.
I never heard any stories of where RSTS came from ...
I believe RSX and RSTE were predated by RT-11 which heavily influenced
CP/M and later DOS. TSX-11 (which ran on RT-11) was considered a cheaper
version of RSTS.

https://en.wikipedia.org/wiki/RT-11


Jeff
Jonathan
2021-05-13 23:42:49 UTC
Permalink
Back in 1974 I was introduced to a PDP11/40 running RSTS V04b. At the
time, the only supported language was Basic+, an interpreter.
Where RSTS came from, I don't know, but what I was told was that David
Hart of Evens, Griffith, and Hart wrote the original Basic+. David is
no longer with us, but, perhaps John Santos might have some information
of the earlier days.
Tim Hart, not David. Tim also wrote the first LISP compiler. He hired me out of college in 1978 and I’m still at EGH.
A great friend, mentor and boss.
While DEC ended up with RSTS and Basic+, what it seemed like to me is
that the software people at DEC considered RSX as a proper OS and RSTS
"that other thing". Perhaps where their NIH started, or, perhaps they
already embraced that concept.
I wasn't a user of RSX at the time, so I really don't have any memories
of it on the PDP11.
Some time after 1974, don't know exactly when, DEC produced some type of
RSX subsystem for RSTS, which allowed MACRO-11, and other RSX languages
to run on RSTS. These included BP2 (Basic Plus 2) which was a compiled
version of Basic Plus.
I think the first macro-11 ran under an RT-11-emulating RTS (Run Time System)
When VAX and VMS came along, VMS inherited much from RSX, as that seemed
to be the preferred choice for the DEC software people. VAX and VMS was
aimed at the scientific market initially. Only when DEC wanted into the
business market did they start incorporating capabilities from RSTS,
since RSTS was heavily used in the business market.
So yeah, VMS was based initially on RSX, and later had RSTS capabilities
added. The result was something better than the sum of RSX and RSTS.
I never heard any stories of where RSTS came from ...
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Dave Froble
2021-05-14 00:17:08 UTC
Permalink
Post by Jonathan
Back in 1974 I was introduced to a PDP11/40 running RSTS V04b. At the
time, the only supported language was Basic+, an interpreter.
Where RSTS came from, I don't know, but what I was told was that David
Hart of Evens, Griffith, and Hart wrote the original Basic+. David is
no longer with us, but, perhaps John Santos might have some information
of the earlier days.
Tim Hart, not David. Tim also wrote the first LISP compiler. He hired me out of college in 1978 and I’m still at EGH.
A great friend, mentor and boss.
Sorry about the name. It's been many years. I met Tim once when I was
at your offices, getting some lessons from John. Hope things are going
well for you guys.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Bob Eager
2021-05-13 15:55:31 UTC
Permalink
Post by Bill Gunshannon
Thank you. That takes me back a little bit further. But I fear the
very origins, the driving model, may be long lost by this time. I have
a number of very early textbooks on Operating Systems and none of them
describe features common in VMS or RSX.
Which features were you thinking of, as a matter of interest?
--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor
David Jones
2021-05-13 16:25:17 UTC
Permalink
Post by Bob Eager
Thank you. That takes me back a little bit further. But I fear the
very origins, the driving model, may be long lost by this time. I have
a number of very early textbooks on Operating Systems and none of them
describe features common in VMS or RSX.
Which features were you thinking of, as a matter of interest?
When I took a micro-architecture class in college (~1983), the concept of an
I/O interrupt completely baffled about half the students. The programming
assignments on PCs running CP/M, though I had been using RSX-11M on
an 11/44 for a couple years.
Bob Eager
2021-05-13 20:21:11 UTC
Permalink
Post by David Jones
Post by Bob Eager
Thank you. That takes me back a little bit further. But I fear the
very origins, the driving model, may be long lost by this time. I
have a number of very early textbooks on Operating Systems and none
of them describe features common in VMS or RSX.
Which features were you thinking of, as a matter of interest?
When I took a micro-architecture class in college (~1983), the concept
of an I/O interrupt completely baffled about half the students. The
programming assignments on PCs running CP/M, though I had been using
RSX-11M on an 11/44 for a couple years.
I/O interrupts were ther back in the 1960s, and possibly earlier. I
started teaching OD theory and practice in 1978, and it was an absolute
given.

We had an interesting assignment which required students (using a 68000
board) to handle interrupts and time black-white transitions from a basic
bar code reader, then work out a threshold and decode the value.
--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor
Simon Clubley
2021-05-13 18:15:59 UTC
Permalink
Post by Bill Gunshannon
Thank you. That takes me back a little bit further. But I fear the
very origins, the driving model, may be long lost by this time. I
have a number of very early textbooks on Operating Systems and none
of them describe features common in VMS or RSX. It's really just
curiosity, but I wondered where some of the concepts originated.
At one point, there used to be a couple of timeline documents available
online, one about VMS and one about the history of DEC itself.

I wonder if they have been lost to time ?

I had a look for the one about the history of DEC, but couldn't find it.

I did find this however, which might be useful:

https://en.wikipedia.org/wiki/History_of_Digital_Equipment_Corporation

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Chris Scheers
2021-05-13 19:19:45 UTC
Permalink
Post by Bill Gunshannon
I have become very curious about the ancestry of VMS. (I am
going to look into some others, but for VMS I do have this
outlet for information!)
Both Primos and Unix came from people recently working on
Multics. Primos went in the same direction as Multics while
Unix appeared to go in a very different direction.
VMS is more similar to Primos than Unix. I have seen it said
that RSX-11 was the immediate parent of VMS. Was that true?
Given that, what is the ancestry going back even further?
Where did VMS actually get its start paradigm-wise?
Anybody here have any of this information?
Early on, I noticed some similarities between VMS and Xerox CP-V.

At a conference 15 or 20 years ago, I ran into Andy Goldstein and asked
him about this.

He said that, yes, there were 1 or 2 members of the Xerox CP-V
development team on the VMS development team, but he didn't remember
what they were responsible for.

This is all anecdotal.
--
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: ***@applied-synergy.com
Fax: 817-237-3074
k***@gmail.com
2021-05-13 22:16:18 UTC
Permalink
-----Original Message-----
Gunshannon via Info-vax
Sent: May-13-21 9:21 AM
Subject: [Info-vax] OS Ancestry
I have become very curious about the ancestry of VMS. (I am going to look
into some others, but for VMS I do have this outlet for information!)
Both Primos and Unix came from people recently working on Multics. Primos
went in the same direction as Multics while Unix appeared to go in a very
different direction.
VMS is more similar to Primos than Unix. I have seen it said that RSX-11
was
the immediate parent of VMS. Was that true?
Given that, what is the ancestry going back even further?
Where did VMS actually get its start paradigm-wise?
Anybody here have any of this information?
bill
A few history links of interest:

VAX / VMS Timeline: (click on year)
<http://gordonbell.azurewebsites.net/digital/timeline/tmlnhome.htm>
<http://gordonbell.azurewebsites.net/digital/timeline/32-bit.htm>

VMS Release History:
<http://www.polarhome.com/vms/vms_hist.html>

VMS Clusters:
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.74.727&rep=rep1&ty
pe=pdf>

VMS vs UNIX (Neil's site)
<http://www3.sympatico.ca/n.rieck/docs/vms_vs_unix.html>
<
http://www3.sympatico.ca/n.rieck/docs/Windows-NT_is_VMS_re-implemented.html#
forward>

Dave Cutler storey from '98
<https://www.itprotoday.com/compute-engines/windows-nt-and-vms-rest-story>


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
--
This email has been checked for viruses by AVG.
https://www.avg.com
k***@gmail.com
2021-05-15 22:52:26 UTC
Permalink
-----Original Message-----
Gunshannon via Info-vax
Sent: May-13-21 9:21 AM
Subject: [Info-vax] OS Ancestry
I have become very curious about the ancestry of VMS. (I am going to look
into some others, but for VMS I do have this outlet for information!)
Both Primos and Unix came from people recently working on Multics. Primos
went in the same direction as Multics while Unix appeared to go in a very
different direction.
VMS is more similar to Primos than Unix. I have seen it said that RSX-11
was
the immediate parent of VMS. Was that true?
Given that, what is the ancestry going back even further?
Where did VMS actually get its start paradigm-wise?
Anybody here have any of this information?
bill
Another pretty good link for those looking for VMS history:

<http://gordonbell.azurewebsites.net/digital/Bell_Retrospective_PDP11_paper_
c1998.htm>

"A Retrospective on What We Have Learned From the PDP-11:
What Else Did We Need to Know That Could Have Been Useful in the Design of
the VAX-11 to Make Alpha Easier?

"VMS is the Architecture That Mattered. not PDP-11, VAX, or Alpha"

Gordon Bell
Senior Researcher, Microsoft Corp.
Bay Area Research Center, San Francisco, CA


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
--
This email has been checked for viruses by AVG.
https://www.avg.com
Simon Clubley
2021-05-17 12:18:01 UTC
Permalink
Post by k***@gmail.com
<http://gordonbell.azurewebsites.net/digital/Bell_Retrospective_PDP11_paper_
c1998.htm>
What Else Did We Need to Know That Could Have Been Useful in the Design of
the VAX-11 to Make Alpha Easier?
"VMS is the Architecture That Mattered. not PDP-11, VAX, or Alpha"
From that link:

| Thus, our real oversight was not understanding that VMS should have been
| built on the C machine for portability across any architecture.

This. 5 zillion times this. VMS could have become like Unix in dominance
if this had been the case.

Want to move VMS to a new architecture in this setup ? It would have been
a comparable effort to what is involved in porting Linux to yet another
architecture, instead of the current effort that is involved.

VMS was designed at too low of an abstraction level.

Also, while he mentions BLISS, he skips over all the Macro-32 usage
and, based on discussions here, all the internal calling conventions
within the VMS kernel that requires those registers.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-05-17 12:22:39 UTC
Permalink
Post by Simon Clubley
Post by k***@gmail.com
<http://gordonbell.azurewebsites.net/digital/Bell_Retrospective_PDP11_paper_
c1998.htm>
What Else Did We Need to Know That Could Have Been Useful in the Design of
the VAX-11 to Make Alpha Easier?
"VMS is the Architecture That Mattered. not PDP-11, VAX, or Alpha"
| Thus, our real oversight was not understanding that VMS should have been
| built on the C machine for portability across any architecture.
This. 5 zillion times this. VMS could have become like Unix in dominance
if this had been the case.
Want to move VMS to a new architecture in this setup ? It would have been
a comparable effort to what is involved in porting Linux to yet another
architecture, instead of the current effort that is involved.
VMS was designed at too low of an abstraction level.
But it is worth remembering that back then (second half 1970's) then
it was not common to write OS in C. Assembler and proprietary languages
was common. That changed in the next 10-15 years.

But that one would be better off if one was able to predict the
future 10 years out is rather obvious.

Arne
Chris Townley
2021-05-17 12:59:36 UTC
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
Post by k***@gmail.com
<http://gordonbell.azurewebsites.net/digital/Bell_Retrospective_PDP11_paper_
c1998.htm>
What Else Did We Need to Know That Could Have Been Useful in the Design of
the VAX-11 to Make Alpha Easier?
"VMS is the Architecture That Mattered. not PDP-11, VAX, or Alpha"
| Thus, our real oversight was not understanding that VMS should have been
| built on the C machine for portability across any architecture.
This. 5 zillion times this. VMS could have become like Unix in dominance
if this had been the case.
Want to move VMS to a new architecture in this setup ? It would have been
a comparable effort to what is involved in porting Linux to yet another
architecture, instead of the current effort that is involved.
VMS was designed at too low of an abstraction level.
But it is worth remembering that back then (second half 1970's) then
it was not common to write OS in C. Assembler and proprietary languages
was common. That changed in the next 10-15 years.
But that one would be better off if one was able to predict the
future 10 years out is rather obvious.
Arne
Didn't Unix change that? Was it not built in C from day 1?
--
Chris Townley
Bill Gunshannon
2021-05-17 13:19:04 UTC
Permalink
Post by Chris Townley
Post by Arne Vajhøj
Post by Simon Clubley
Post by k***@gmail.com
<http://gordonbell.azurewebsites.net/digital/Bell_Retrospective_PDP11_paper_
c1998.htm>
What Else Did We Need to Know That Could Have Been Useful in the Design of
the VAX-11 to Make Alpha Easier?
"VMS is the Architecture That Mattered. not PDP-11, VAX, or Alpha"
| Thus, our real oversight was not understanding that VMS should have been
| built on the C machine for portability across any architecture.
This. 5 zillion times this. VMS could have become like Unix in dominance
if this had been the case.
Want to move VMS to a new architecture in this setup ? It would have been
a comparable effort to what is involved in porting Linux to yet another
architecture, instead of the current effort that is involved.
VMS was designed at too low of an abstraction level.
But it is worth remembering that back then (second half 1970's) then
it was not common to write OS in C. Assembler and proprietary languages
was common. That changed in the next 10-15 years.
But that one would be better off if one was able to predict the
future 10 years out is rather obvious.
Arne
Didn't Unix change that? Was it not built in C from day 1?
No, it started as PDP-7 Assembler and was originally called Unics,
a pun on Multics.

bill
Arne Vajhøj
2021-05-17 13:20:23 UTC
Permalink
Post by Chris Townley
Post by Arne Vajhøj
Post by Simon Clubley
Post by k***@gmail.com
<http://gordonbell.azurewebsites.net/digital/Bell_Retrospective_PDP11_paper_
c1998.htm>
What Else Did We Need to Know That Could Have Been Useful in the Design of
the VAX-11 to Make Alpha Easier?
"VMS is the Architecture That Mattered. not PDP-11, VAX, or Alpha"
| Thus, our real oversight was not understanding that VMS should have been
| built on the C machine for portability across any architecture.
This. 5 zillion times this. VMS could have become like Unix in dominance
if this had been the case.
Want to move VMS to a new architecture in this setup ? It would have been
a comparable effort to what is involved in porting Linux to yet another
architecture, instead of the current effort that is involved.
VMS was designed at too low of an abstraction level.
But it is worth remembering that back then (second half 1970's) then
it was not common to write OS in C. Assembler and proprietary languages
was common. That changed in the next 10-15 years.
But that one would be better off if one was able to predict the
future 10 years out is rather obvious.
Didn't Unix change that? Was it not built in C from day 1?
Unix was supposedly first written in assembler and a few year later
rewritten in C.

But it was in C when VMS was created.

The point is that at that time then Unix was not a big thing.

IBM, CDC, Sperry, Burroughs, HP etc. all had non-C OS.

Arne
Dave Froble
2021-05-17 13:20:45 UTC
Permalink
Post by Simon Clubley
Post by k***@gmail.com
<http://gordonbell.azurewebsites.net/digital/Bell_Retrospective_PDP11_paper_
c1998.htm>
What Else Did We Need to Know That Could Have Been Useful in the Design of
the VAX-11 to Make Alpha Easier?
"VMS is the Architecture That Mattered. not PDP-11, VAX, or Alpha"
| Thus, our real oversight was not understanding that VMS should have been
| built on the C machine for portability across any architecture.
This. 5 zillion times this. VMS could have become like Unix in dominance
if this had been the case.
Want to move VMS to a new architecture in this setup ? It would have been
a comparable effort to what is involved in porting Linux to yet another
architecture, instead of the current effort that is involved.
VMS was designed at too low of an abstraction level.
Also, while he mentions BLISS, he skips over all the Macro-32 usage
and, based on discussions here, all the internal calling conventions
within the VMS kernel that requires those registers.
Simon.
But is the implementation language the only issue? I'd think not. As
John and minions have demonstrated, perhaps with some effort, they can
handle the multiple languages.

Rather, perhaps it is the concepts that are different enough that it's
apples and oranges, not two different types of apples?

For an example, FORK doesn't seem too easy to implement on VMS,
regardless of the language. Though, I'll admit that this example has
little to do with your claim of ease of porting.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-05-17 13:26:41 UTC
Permalink
Post by Simon Clubley
Post by k***@gmail.com
<http://gordonbell.azurewebsites.net/digital/Bell_Retrospective_PDP11_paper_
c1998.htm>
What Else Did We Need to Know That Could Have Been Useful in the Design of
the VAX-11 to Make Alpha Easier?
"VMS is the Architecture That Mattered. not PDP-11, VAX, or Alpha"
| Thus, our real oversight was not understanding that VMS should have been
| built on the C machine for portability across any architecture.
This. 5 zillion times this. VMS could have become like Unix in dominance
if this had been the case.
Want to move VMS to a new architecture in this setup ? It would have been
a comparable effort to what is involved in porting Linux to yet another
architecture, instead of the current effort that is involved.
VMS was designed at too low of an abstraction level.
Also, while he mentions BLISS, he skips over all the Macro-32 usage
and, based on discussions here, all the internal calling conventions
within the VMS kernel that requires those registers.
But is the implementation language the only issue?  I'd think not.  As
John and minions have demonstrated, perhaps with some effort, they can
handle the multiple languages.
Rather, perhaps it is the concepts that are different enough that it's
apples and oranges, not two different types of apples?
For an example, FORK doesn't seem too easy to implement on VMS,
regardless of the language.  Though, I'll admit that this example has
little to do with your claim of ease of porting.
Given that it looks like the treading model has won over
traditional forking, then I don't think the missing fork
was the problem.

Arne

PS: Note that I used the term "traditional forking" not just
"forking" - I believe on Linux then threads are implemented
using fork mechanism under the hood.
Simon Clubley
2021-05-17 19:12:23 UTC
Permalink
Post by Dave Froble
Post by Simon Clubley
| Thus, our real oversight was not understanding that VMS should have been
| built on the C machine for portability across any architecture.
This. 5 zillion times this. VMS could have become like Unix in dominance
if this had been the case.
Want to move VMS to a new architecture in this setup ? It would have been
a comparable effort to what is involved in porting Linux to yet another
architecture, instead of the current effort that is involved.
VMS was designed at too low of an abstraction level.
Also, while he mentions BLISS, he skips over all the Macro-32 usage
and, based on discussions here, all the internal calling conventions
within the VMS kernel that requires those registers.
But is the implementation language the only issue? I'd think not. As
John and minions have demonstrated, perhaps with some effort, they can
handle the multiple languages.
It's a massive part of it but you also have to think about the 4-modes
versus 2-modes issue. If you were looking at a C machine model, that
would also mean a design where you were not tied to any architecture
specific modes, so VMS would have been designed around a 2-mode model
in that case.

That means either supervisor mode disappears and DCL runs in a different
process or DCL never sees privileges from the programs it activates.

RMS is the more interesting case. Either that gets folded into the
kernel, or some other mechanism would have to be developed to isolate
it from the user mode code in the same way that executive mode does.

The reason any implementation language (and the functionality in the
lowest supported application language) matters is because of the level
of abstractions you can rely on when writing your operating system and
when implementing the APIs the user's application programs are going to use.

For example, if your lowest level is C, you can define a pointer variable
like this:

unsigned char *ptr;

The size of that pointer is abstracted away from you and you simply
don't care about that pointer size unless you are working with some
hardware where it matters.

You can compile that line of source code (and anything that uses it)
in either 32-bit or 64-bit mode and it simply doesn't matter to the
source code. A portable VMS would just need to know whether it is
dealing with a 32-bit or 64-bit image and that information would be
provided by the image activator.

In the current VMS design, your lowest level is Macro-32 so you don't
have that level of abstraction and the size of the pointers are _very_
visible to you and your source code.

That means your APIs have to be designed around that lack of abstraction
and you can't move from 32-bit to 64-bit by simply (mostly!) recompiling
your application source code.

Imagine if, for example, RMS had been designed in a world where C was
the lowest level instead of Macro-32. You would not need any of the
32-bit versus 64-bit RMS APIs (it would be just one API at source code
level) and your program would either be a pure 32-bit application or a
pure 64-bit application.

Likewise with the kernel. That would be written in C using internal
function calls with clean interfaces. There would be none of this
Macro-32 call and jump instructions jumping around in a chain of kernel
functions stuff with specific registers reserved for specific parameters.

Any such details would be implemented by the compiler as part of
the ABI for the architecture (and would be different for every
architecture) and this would be hidden from most of the kernel
source code, just as with application code written in C and above.

You would still have everything that makes VMS what it is (DLM,
clusters, and everything else) but that code would be vastly more
easy to port than it currently is.
Post by Dave Froble
Rather, perhaps it is the concepts that are different enough that it's
apples and oranges, not two different types of apples?
Operating system concepts mostly have nothing to do with portability.
Post by Dave Froble
For an example, FORK doesn't seem too easy to implement on VMS,
regardless of the language. Though, I'll admit that this example has
little to do with your claim of ease of porting.
A missing fork() is a question of functionality, not a question of
portability between architectures.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-05-17 19:38:20 UTC
Permalink
Post by Simon Clubley
Post by Dave Froble
Post by Simon Clubley
| Thus, our real oversight was not understanding that VMS should have been
| built on the C machine for portability across any architecture.
This. 5 zillion times this. VMS could have become like Unix in dominance
if this had been the case.
Want to move VMS to a new architecture in this setup ? It would have been
a comparable effort to what is involved in porting Linux to yet another
architecture, instead of the current effort that is involved.
VMS was designed at too low of an abstraction level.
Also, while he mentions BLISS, he skips over all the Macro-32 usage
and, based on discussions here, all the internal calling conventions
within the VMS kernel that requires those registers.
But is the implementation language the only issue? I'd think not. As
John and minions have demonstrated, perhaps with some effort, they can
handle the multiple languages.
It's a massive part of it but you also have to think about the 4-modes
versus 2-modes issue. If you were looking at a C machine model, that
would also mean a design where you were not tied to any architecture
specific modes, so VMS would have been designed around a 2-mode model
in that case.
The 4 modes would of course be a complication, but VSI has solved it
(mapping 4 logical modes to 2 hardware modes) for the x86-64 port.
Post by Simon Clubley
The reason any implementation language (and the functionality in the
lowest supported application language) matters is because of the level
of abstractions you can rely on when writing your operating system and
when implementing the APIs the user's application programs are going to use.
For example, if your lowest level is C, you can define a pointer variable
unsigned char *ptr;
The size of that pointer is abstracted away from you and you simply
don't care about that pointer size unless you are working with some
hardware where it matters.
You can compile that line of source code (and anything that uses it)
in either 32-bit or 64-bit mode and it simply doesn't matter to the
source code. A portable VMS would just need to know whether it is
dealing with a 32-bit or 64-bit image and that information would be
provided by the image activator.
In the current VMS design, your lowest level is Macro-32 so you don't
have that level of abstraction and the size of the pointers are _very_
visible to you and your source code.
That means your APIs have to be designed around that lack of abstraction
and you can't move from 32-bit to 64-bit by simply (mostly!) recompiling
your application source code.
Imagine if, for example, RMS had been designed in a world where C was
the lowest level instead of Macro-32. You would not need any of the
32-bit versus 64-bit RMS APIs (it would be just one API at source code
level) and your program would either be a pure 32-bit application or a
pure 64-bit application.
Note that there is no such thing as 32 bit and 64 bit mode on VMS.

The CPU on Alpha, Itanium and x86-64 is always in 64 bit mode. Effective
addresses are always 64 bit.

Pointers in memory can just contain all 64 bits or just 32 bits with an
assumption about the high bits.

But it is a per pointer characteristic not a per program
characteristic - it is possible to have both 64 bit and 32
bit pointers in the same program.

If all code on VMS had been nice standard ANSI C, then a lot of
things would have been easy.

The reality was different. Not just Macro-32 .blkl but
also Fortran INTEGER*4 and possible other languages
as well.

Arne
Simon Clubley
2021-05-18 18:33:11 UTC
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
Imagine if, for example, RMS had been designed in a world where C was
the lowest level instead of Macro-32. You would not need any of the
32-bit versus 64-bit RMS APIs (it would be just one API at source code
level) and your program would either be a pure 32-bit application or a
pure 64-bit application.
Note that there is no such thing as 32 bit and 64 bit mode on VMS.
VAX. Which is where VMS started (and 32-bit processors are where Unix
and Linux started). It was a lot easier to get 32-bit Unix/Linux working
on 64-bit architectures than it was VMS.
Post by Arne Vajhøj
The CPU on Alpha, Itanium and x86-64 is always in 64 bit mode. Effective
addresses are always 64 bit.
Pointers in memory can just contain all 64 bits or just 32 bits with an
assumption about the high bits.
But in a portable implementation, then this detail (mostly) would not
matter as it would be mostly hidden from the source code within the ABI.
Post by Arne Vajhøj
But it is a per pointer characteristic not a per program
characteristic - it is possible to have both 64 bit and 32
bit pointers in the same program.
But in a portable implementation, you would have either a 32-bit
process or a 64-bit process. There would be no need for the hybrid
mode and all the extra APIs that go with it.
Post by Arne Vajhøj
If all code on VMS had been nice standard ANSI C, then a lot of
things would have been easy.
The reality was different. Not just Macro-32 .blkl but
also Fortran INTEGER*4 and possible other languages
as well.
But this is about a portable version of VMS, not the non-portable
version that was created. In a portable version of VMS, you would
not have Macro-32 as a supported application language and the only
place you would see it is in little bits of architecture-specific
code on VAX that couldn't be written in C or a higher-level language..

BTW, how is INTEGER*4 handled on Unix or was Fortran code never
written that way on Unix ? (It's been a very long time since I
wrote any Fortran code.)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-05-18 18:54:21 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
The CPU on Alpha, Itanium and x86-64 is always in 64 bit mode. Effective
addresses are always 64 bit.
Pointers in memory can just contain all 64 bits or just 32 bits with an
assumption about the high bits.
But in a portable implementation, then this detail (mostly) would not
matter as it would be mostly hidden from the source code within the ABI.
Post by Arne Vajhøj
But it is a per pointer characteristic not a per program
characteristic - it is possible to have both 64 bit and 32
bit pointers in the same program.
But in a portable implementation, you would have either a 32-bit
process or a 64-bit process. There would be no need for the hybrid
mode and all the extra APIs that go with it.
Post by Arne Vajhøj
If all code on VMS had been nice standard ANSI C, then a lot of
things would have been easy.
The reality was different. Not just Macro-32 .blkl but
also Fortran INTEGER*4 and possible other languages
as well.
But this is about a portable version of VMS, not the non-portable
version that was created. In a portable version of VMS, you would
not have Macro-32 as a supported application language and the only
place you would see it is in little bits of architecture-specific
code on VAX that couldn't be written in C or a higher-level language..
If DEC in 1976-1977 had prioritized making VMS portable and
if applications from that time and forward had done the same, then
a lot of things would have been easier today.

But I believe that line of thinking is a rather futile mental
exercise. If I could see out in the future then I could become
rich from either the stock market or playing the lottery.
But I can't. DEC could not see out in the future back then either.
Post by Simon Clubley
BTW, how is INTEGER*4 handled on Unix or was Fortran code never
written that way on Unix ? (It's been a very long time since I
wrote any Fortran code.)
INTEGER*4 is not a problem if used to store a 32 bit
integer data. It only becomes a problem if it is used to store
an address.

Like:

STRUCTURE /ITEMLIST/
INTEGER*2 BUFLEN,CODE
INTEGER*4 BUFADR,RETLENADR
ENDSTRUCTURE

Point is that non-portable data types used for addresses is
not a Macro-32 only problem.

Another problem with going only 64 bit pointers in Alpha
would have been VEST. When the tool saw a MOVL should it guess
on whether it was moving data or moving an address?

Arne
Simon Clubley
2021-05-18 19:03:10 UTC
Permalink
Post by Arne Vajhøj
Another problem with going only 64 bit pointers in Alpha
would have been VEST. When the tool saw a MOVL should it guess
on whether it was moving data or moving an address?
In a portable VMS, that problem probably would not exist and if
it was required for some reason, it would be handled in the same
way as however the Macro-32 compiler works in that case on Alpha.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-05-18 19:05:58 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Another problem with going only 64 bit pointers in Alpha
would have been VEST. When the tool saw a MOVL should it guess
on whether it was moving data or moving an address?
In a portable VMS, that problem probably would not exist
It would.

char *p1, *p2;
p2 = p1;

may be portable but in the binary it would either move 4 bytes
or 8 bytes.
Post by Simon Clubley
and if
it was required for some reason, it would be handled in the same
way as however the Macro-32 compiler works in that case on Alpha.
The Macro-32 compiler uses 32 bit pointers on 64 bit VMS.

Arne
Simon Clubley
2021-05-18 19:08:37 UTC
Permalink
Post by Arne Vajhøj
Post by Bob Eager
and if
it was required for some reason, it would be handled in the same
way as however the Macro-32 compiler works in that case on Alpha.
The Macro-32 compiler uses 32 bit pointers on 64 bit VMS.
Then your translated VEST image would work in the same way.

After all, the image is coming from a 32-bit environment.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-05-18 19:11:27 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by Bob Eager
and if
it was required for some reason, it would be handled in the same
way as however the Macro-32 compiler works in that case on Alpha.
The Macro-32 compiler uses 32 bit pointers on 64 bit VMS.
Then your translated VEST image would work in the same way.
After all, the image is coming from a 32-bit environment.
And it did.

But that means 32 bit pointers.

And then Macro-32 is obviously fine as it uses the same 32 bit pointers.

Arne
Bill Gunshannon
2021-05-18 18:54:49 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by Simon Clubley
Imagine if, for example, RMS had been designed in a world where C was
the lowest level instead of Macro-32. You would not need any of the
32-bit versus 64-bit RMS APIs (it would be just one API at source code
level) and your program would either be a pure 32-bit application or a
pure 64-bit application.
Note that there is no such thing as 32 bit and 64 bit mode on VMS.
VAX. Which is where VMS started (and 32-bit processors are where Unix
and Linux started).
PDP-7? PDP-11?


bill
Simon Clubley
2021-05-18 19:05:21 UTC
Permalink
Post by Bill Gunshannon
Post by Simon Clubley
Post by Arne Vajhøj
Post by Simon Clubley
Imagine if, for example, RMS had been designed in a world where C was
the lowest level instead of Macro-32. You would not need any of the
32-bit versus 64-bit RMS APIs (it would be just one API at source code
level) and your program would either be a pure 32-bit application or a
pure 64-bit application.
Note that there is no such thing as 32 bit and 64 bit mode on VMS.
VAX. Which is where VMS started (and 32-bit processors are where Unix
and Linux started).
PDP-7? PDP-11?
Good point. IIRC, Unix in C first happened on the PDP-11. That
makes Unix even more portable (but I would not fancy working with
K&R C :-) ).

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Rich Alderson
2021-05-22 02:06:20 UTC
Permalink
Post by Simon Clubley
VAX. Which is where VMS started (and 32-bit processors are where Unix
and Linux started). It was a lot easier to get 32-bit Unix/Linux working
on 64-bit architectures than it was VMS.
NB: For the purposes of this discussion, Unix started on a *16*-bit
architecture. (We'll ignore the fact that it actually started on an 18-bit
word addressed architecture.)
--
Rich Alderson ***@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
Simon Clubley
2021-05-24 12:28:32 UTC
Permalink
Post by Rich Alderson
Post by Simon Clubley
VAX. Which is where VMS started (and 32-bit processors are where Unix
and Linux started). It was a lot easier to get 32-bit Unix/Linux working
on 64-bit architectures than it was VMS.
NB: For the purposes of this discussion, Unix started on a *16*-bit
architecture. (We'll ignore the fact that it actually started on an 18-bit
word addressed architecture.)
Yes, oops. :-) Somebody already reminded me about this a few days ago
and as I pointed out in response this just shows how much more portable
things are when you are using an implemention language not tied to the
architecture.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Bob Eager
2021-05-24 12:57:24 UTC
Permalink
Post by Simon Clubley
Post by Rich Alderson
Post by Simon Clubley
VAX. Which is where VMS started (and 32-bit processors are where Unix
and Linux started). It was a lot easier to get 32-bit Unix/Linux
working on 64-bit architectures than it was VMS.
NB: For the purposes of this discussion, Unix started on a *16*-bit
architecture. (We'll ignore the fact that it actually started on an
18-bit word addressed architecture.)
Yes, oops. :-) Somebody already reminded me about this a few days ago
and as I pointed out in response this just shows how much more portable
things are when you are using an implemention language not tied to the
architecture.
They still made some mistakes. Such as a 16 bit limit for the number of
sectors on a disk (they solved that one by inventing partitions). And the
16 bit seek distance (in bytes, solved by inventing lseek in Seventh
Edition).

The language isn't everyting.
--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor
John Wallace
2021-05-24 13:24:14 UTC
Permalink
Post by Simon Clubley
Post by Rich Alderson
Post by Simon Clubley
VAX. Which is where VMS started (and 32-bit processors are where Unix
and Linux started). It was a lot easier to get 32-bit Unix/Linux working
on 64-bit architectures than it was VMS.
NB: For the purposes of this discussion, Unix started on a *16*-bit
architecture. (We'll ignore the fact that it actually started on an 18-bit
word addressed architecture.)
Yes, oops. :-) Somebody already reminded me about this a few days ago
and as I pointed out in response this just shows how much more portable
things are when you are using an implemention language not tied to the
architecture.
Simon.
Yeah sure, UNIX code was so portable that back in the 1980s anything
much more complex than "Hello World" had little chance of being portable
between (e.g.) BSD and System V even on the very same hardware.

When the two main camps can't even agree on the basics of opening a file
from C,
as in fd = open(...),
it's no wonder there was a customer/vendor need for a Single UNIX
Specification.

Fortunately times have moved on since then.
Bill Gunshannon
2021-05-24 13:59:40 UTC
Permalink
Post by John Wallace
Post by Simon Clubley
Post by Simon Clubley
VAX. Which is where VMS started (and 32-bit processors are where Unix
and Linux started). It was a lot easier to get 32-bit Unix/Linux working
on 64-bit architectures than it was VMS.
NB:  For the purposes of this discussion, Unix started on a *16*-bit
architecture.  (We'll ignore the fact that it actually started on an
18-bit
word addressed architecture.)
Yes, oops. :-) Somebody already reminded me about this a few days ago
and as I pointed out in response this just shows how much more portable
things are when you are using an implemention language not tied to the
architecture.
Simon.
Yeah sure, UNIX code was so portable that back in the 1980s anything
much more complex than "Hello World" had little chance of being portable
between (e.g.) BSD and System V even on the very same hardware.
When the two main camps can't even agree on the basics of opening a file
from C,
as in fd = open(...),
it's no wonder there was a customer/vendor need for a Single UNIX
Specification.
Fortunately times have moved on since then.
That had a lot more to do with deliberate proprietariness than
anything else. AT&T saw itself losing what little bit of the
market they had grabbed and decided making theirs different and
incompatible was good business. Eventually SYSV versions ended
out including BSD compatibility libraries because it was obvious
which way was better. I don't remember seeing any BSD product
coming with a SYSV compatibility library.

bill
chris
2021-05-24 23:59:06 UTC
Permalink
Post by Bill Gunshannon
Post by John Wallace
Post by Simon Clubley
Post by Rich Alderson
Post by Simon Clubley
VAX. Which is where VMS started (and 32-bit processors are where Unix
and Linux started). It was a lot easier to get 32-bit Unix/Linux working
on 64-bit architectures than it was VMS.
NB: For the purposes of this discussion, Unix started on a *16*-bit
architecture. (We'll ignore the fact that it actually started on an 18-bit
word addressed architecture.)
Yes, oops. :-) Somebody already reminded me about this a few days ago
and as I pointed out in response this just shows how much more portable
things are when you are using an implemention language not tied to the
architecture.
Simon.
Yeah sure, UNIX code was so portable that back in the 1980s anything
much more complex than "Hello World" had little chance of being
portable between (e.g.) BSD and System V even on the very same hardware.
When the two main camps can't even agree on the basics of opening a
file from C,
as in fd = open(...),
it's no wonder there was a customer/vendor need for a Single UNIX
Specification.
Fortunately times have moved on since then.
That had a lot more to do with deliberate proprietariness than
anything else. AT&T saw itself losing what little bit of the
market they had grabbed and decided making theirs different and
incompatible was good business. Eventually SYSV versions ended
out including BSD compatibility libraries because it was obvious
which way was better. I don't remember seeing any BSD product
coming with a SYSV compatibility library.
bill
That's quite true, though Sun started off with a BSD flavour unix,
(SunOs) then incorporated the more useful bits of SysV when later
editions of Solaris were released. Streams being one such idea, but
there were others as well. Quite a bit of cross fertilisation...

Chris
Bill Gunshannon
2021-05-25 01:14:09 UTC
Permalink
Post by chris
Post by Bill Gunshannon
Post by John Wallace
Post by Simon Clubley
Post by Simon Clubley
VAX. Which is where VMS started (and 32-bit processors are where Unix
and Linux started). It was a lot easier to get 32-bit Unix/Linux working
on 64-bit architectures than it was VMS.
NB:  For the purposes of this discussion, Unix started on a *16*-bit
architecture.  (We'll ignore the fact that it actually started on an
18-bit
word addressed architecture.)
Yes, oops. :-) Somebody already reminded me about this a few days ago
and as I pointed out in response this just shows how much more portable
things are when you are using an implemention language not tied to the
architecture.
Simon.
Yeah sure, UNIX code was so portable that back in the 1980s anything
much more complex than "Hello World" had little chance of being
portable between (e.g.) BSD and System V even on the very same hardware.
When the two main camps can't even agree on the basics of opening a
file from C,
as in fd = open(...),
it's no wonder there was a customer/vendor need for a Single UNIX
Specification.
Fortunately times have moved on since then.
That had a lot more to do with deliberate proprietariness than
anything else. AT&T saw itself losing what little bit of the
market they had grabbed and decided making theirs different and
incompatible was good business. Eventually SYSV versions ended
out including BSD compatibility libraries because it was obvious
which way was better. I don't remember seeing any BSD product
coming with a SYSV compatibility library.
bill
That's quite true, though Sun started off with a BSD flavour unix,
(SunOs) then incorporated the more useful bits of SysV when later
editions of Solaris were released. Streams being one such idea, but
there were others as well. Quite a bit of cross fertilisation...
I don't remember any SYSVisms in SunOS. Certainly not STREAMS.
And Solaris was Suns attempt to abandon BSD in favor of SYSV.
For those of us who had been with SUN since M68000 days this
was pretty disastrous. Early Solaris performed badly and as you
might expect existing SunOS code could not be compiled to run
on Solaris without heavy modification. Even with all of the
BSD compatibility stuff included. It resulted in the University
I was working at beginning its migration away from SUN. I
expect the same happened elsewhere as well.

bill
Arne Vajhøj
2021-05-25 01:26:16 UTC
Permalink
Post by chris
Post by Bill Gunshannon
That had a lot more to do with deliberate proprietariness than
anything else. AT&T saw itself losing what little bit of the
market they had grabbed and decided making theirs different and
incompatible was good business. Eventually SYSV versions ended
out including BSD compatibility libraries because it was obvious
which way was better. I don't remember seeing any BSD product
coming with a SYSV compatibility library.
That's quite true, though Sun started off with a BSD flavour unix,
(SunOs) then incorporated the more useful bits of SysV when later
editions of Solaris were released. Streams being one such idea, but
there were others as well. Quite a bit of cross fertilisation...
I don't remember any SYSVisms in SunOS.  Certainly not STREAMS.
And Solaris was Suns attempt to abandon BSD in favor of SYSV.
For those of us who had been with SUN since M68000 days this
was pretty disastrous. Early Solaris performed badly and as you
might expect existing SunOS code could not be compiled to run
on Solaris without heavy modification.  Even with all of the
BSD compatibility stuff included.  It resulted in the University
I was working at beginning its migration away from SUN.  I
expect the same happened elsewhere as well.
SunOS 1.x - 4.x was BSD (wiki claims some SysV stuff from
3.0 specifically IPC).

SunOS 5.x was SysV.

SunOS 4.x = Solaris 1.x and SunOS 5.x = Solaris 2.x.

Arne
Simon Clubley
2021-05-24 18:05:42 UTC
Permalink
Post by John Wallace
Post by Simon Clubley
Yes, oops. :-) Somebody already reminded me about this a few days ago
and as I pointed out in response this just shows how much more portable
things are when you are using an implemention language not tied to the
architecture.
Yeah sure, UNIX code was so portable that back in the 1980s anything
much more complex than "Hello World" had little chance of being portable
between (e.g.) BSD and System V even on the very same hardware.
When the two main camps can't even agree on the basics of opening a file
from C,
as in fd = open(...),
it's no wonder there was a customer/vendor need for a Single UNIX
Specification.
Fortunately times have moved on since then.
You are confusing functionality of an operating system with the
portability of an operating system between architectures.

Your comments above talk about functionality within an operating
system. I am talking about the ease of porting an operating system
from one architecture to another.

The choice of implementation language does not decide the functionality
of an operating system. It is however a major factor in how easy or not
it is to port that operating system to another architecture.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-05-24 23:58:23 UTC
Permalink
Post by Simon Clubley
Post by John Wallace
Post by Simon Clubley
Yes, oops. :-) Somebody already reminded me about this a few days ago
and as I pointed out in response this just shows how much more portable
things are when you are using an implemention language not tied to the
architecture.
Yeah sure, UNIX code was so portable that back in the 1980s anything
much more complex than "Hello World" had little chance of being portable
between (e.g.) BSD and System V even on the very same hardware.
When the two main camps can't even agree on the basics of opening a file
from C,
as in fd = open(...),
it's no wonder there was a customer/vendor need for a Single UNIX
Specification.
Fortunately times have moved on since then.
You are confusing functionality of an operating system with the
portability of an operating system between architectures.
Your comments above talk about functionality within an operating
system. I am talking about the ease of porting an operating system
from one architecture to another.
The choice of implementation language does not decide the functionality
of an operating system. It is however a major factor in how easy or not
it is to port that operating system to another architecture.
Even when (hawk, spit, gag) C doesn't work the same on different
architectures?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
chris
2021-05-25 00:01:47 UTC
Permalink
Post by Dave Froble
Post by Simon Clubley
Post by John Wallace
Post by Simon Clubley
Yes, oops. :-) Somebody already reminded me about this a few days ago
and as I pointed out in response this just shows how much more portable
things are when you are using an implemention language not tied to the
architecture.
Yeah sure, UNIX code was so portable that back in the 1980s anything
much more complex than "Hello World" had little chance of being portable
between (e.g.) BSD and System V even on the very same hardware.
When the two main camps can't even agree on the basics of opening a file
from C,
as in fd = open(...),
it's no wonder there was a customer/vendor need for a Single UNIX
Specification.
Fortunately times have moved on since then.
You are confusing functionality of an operating system with the
portability of an operating system between architectures.
Your comments above talk about functionality within an operating
system. I am talking about the ease of porting an operating system
from one architecture to another.
The choice of implementation language does not decide the functionality
of an operating system. It is however a major factor in how easy or not
it is to port that operating system to another architecture.
Even when (hawk, spit, gag) C doesn't work the same on different
architectures?
No problem if you write portable code and don't rely on invisible
underlying architecture or OS differences. Code I wrote decades ago
is still usable now...

Chris
Arne Vajhøj
2021-05-25 00:16:26 UTC
Permalink
Post by chris
Post by Dave Froble
Post by Simon Clubley
Post by John Wallace
Post by Simon Clubley
Yes, oops. :-) Somebody already reminded me about this a few days ago
and as I pointed out in response this just shows how much more portable
things are when you are using an implemention language not tied to the
architecture.
Yeah sure, UNIX code was so portable that back in the 1980s anything
much more complex than "Hello World" had little chance of being portable
between (e.g.) BSD and System V even on the very same hardware.
When the two main camps can't even agree on the basics of opening a file
from C,
as in fd = open(...),
it's no wonder there was a customer/vendor need for a Single UNIX
Specification.
Fortunately times have moved on since then.
You are confusing functionality of an operating system with the
portability of an operating system between architectures.
Your comments above talk about functionality within an operating
system. I am talking about the ease of porting an operating system
from one architecture to another.
The choice of implementation language does not decide the functionality
of an operating system. It is however a major factor in how easy or not
it is to port that operating system to another architecture.
Even when (hawk, spit, gag) C doesn't work the same on different
architectures?
No problem if you write portable code and don't rely on invisible
underlying architecture or OS differences. Code I wrote decades ago
is still usable now...
It is certainly possible to write portable C code.

But it is not trivial to write portable C code. Usage
of implementation specific behavior, assumptions
about various sizes etc..

Arne
Arne Vajhøj
2021-05-25 00:11:30 UTC
Permalink
Post by Dave Froble
Post by Simon Clubley
Post by John Wallace
Post by Simon Clubley
Yes, oops. :-) Somebody already reminded me about this a few days ago
and as I pointed out in response this just shows how much more portable
things are when you are using an implemention language not tied to the
architecture.
Yeah sure, UNIX code was so portable that back in the 1980s anything
much more complex than "Hello World" had little chance of being portable
between (e.g.) BSD and System V even on the very same hardware.
When the two main camps can't even agree on the basics of opening a file
from C,
as in fd = open(...),
it's no wonder there was a customer/vendor need for a Single UNIX
Specification.
Fortunately times have moved on since then.
You are confusing functionality of an operating system with the
portability of an operating system between architectures.
Your comments above talk about functionality within an operating
system. I am talking about the ease of porting an operating system
from one architecture to another.
The choice of implementation language does not decide the functionality
of an operating system. It is however a major factor in how easy or not
it is to port that operating system to another architecture.
Even when (hawk, spit, gag) C doesn't work the same on different
architectures?
I think the answer depends on the question.

Can you just compile an OS written in C for a different
platform and it will run?

No. There may be differences in C implementation. And there
will also be some code that has to be platform specific.

Is it easier to port an OS written in to another platform
than to port an OS written in assembler to another
platform?

Yes. A lot of code will just work. And some careful
ifdef'ing can minimize the impact from the remaining
problems.

Arne
chris
2021-05-25 14:51:03 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Post by Simon Clubley
Post by John Wallace
Post by Simon Clubley
Yes, oops. :-) Somebody already reminded me about this a few days ago
and as I pointed out in response this just shows how much more portable
things are when you are using an implemention language not tied to the
architecture.
Yeah sure, UNIX code was so portable that back in the 1980s anything
much more complex than "Hello World" had little chance of being portable
between (e.g.) BSD and System V even on the very same hardware.
When the two main camps can't even agree on the basics of opening a file
from C,
as in fd = open(...),
it's no wonder there was a customer/vendor need for a Single UNIX
Specification.
Fortunately times have moved on since then.
You are confusing functionality of an operating system with the
portability of an operating system between architectures.
Your comments above talk about functionality within an operating
system. I am talking about the ease of porting an operating system
from one architecture to another.
The choice of implementation language does not decide the functionality
of an operating system. It is however a major factor in how easy or not
it is to port that operating system to another architecture.
Even when (hawk, spit, gag) C doesn't work the same on different
architectures?
I think the answer depends on the question.
Can you just compile an OS written in C for a different
platform and it will run?
No. There may be differences in C implementation. And there
will also be some code that has to be platform specific.
C has been standardised for decades, but the C library can
cause problems between os's because of the required header
files, which vary between, say, Linux and FreeBSD.

The real problem is where the OS interfaces with the hardware.
That is taken care of in modern OS's with a hardware
abstraction layer, but some assembler will always be required
at low level, to deal with differing architectures, memory
management etc.
Post by Arne Vajhøj
Is it easier to port an OS written in to another platform
than to port an OS written in assembler to another
platform?
Yes. A lot of code will just work. And some careful
ifdef'ing can minimize the impact from the remaining
problems.
Arne
Bill Gunshannon
2021-05-25 01:06:28 UTC
Permalink
Post by Dave Froble
Post by Simon Clubley
Post by John Wallace
Post by Simon Clubley
Yes, oops. :-) Somebody already reminded me about this a few days ago
and as I pointed out in response this just shows how much more portable
things are when you are using an implemention language not tied to the
architecture.
Yeah sure, UNIX code was so portable that back in the 1980s anything
much more complex than "Hello World" had little chance of being portable
between (e.g.) BSD and System V even on the very same hardware.
When the two main camps can't even agree on the basics of opening a file
from C,
as in fd = open(...),
it's no wonder there was a customer/vendor need for a Single UNIX
Specification.
Fortunately times have moved on since then.
You are confusing functionality of an operating system with the
portability of an operating system between architectures.
Your comments above talk about functionality within an operating
system. I am talking about the ease of porting an operating system
from one architecture to another.
The choice of implementation language does not decide the functionality
of an operating system. It is however a major factor in how easy or not
it is to port that operating system to another architecture.
Even when (hawk, spit, gag) C doesn't work the same on different
architectures?
Got any good examples? Are you sure it wasn't just a bad
implementation?

bill
Arne Vajhøj
2021-05-25 12:46:28 UTC
Permalink
Post by Dave Froble
Post by Simon Clubley
The choice of implementation language does not decide the functionality
of an operating system. It is however a major factor in how easy or not
it is to port that operating system to another architecture.
Even when (hawk, spit, gag) C doesn't work the same on different
architectures?
Got any good examples?  Are you sure it wasn't just a bad
implementation?
C compiler bugs are getting relative rare today.

But the C standard leaves a lot to the implementation.

Character set, actual size of basic data types, ones vs
twos complement, FP format, data alignment, actual size of
size_t, a lot around volatile etc.etc..

This makes it possible to write a "hardware close"
C compiler on any platform.

But it also makes it a bit tricky to write a C
program with guaranteed behavior on all
standard compliant C compilers.

Arne
Bill Gunshannon
2021-05-25 13:31:38 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Post by Simon Clubley
The choice of implementation language does not decide the functionality
of an operating system. It is however a major factor in how easy or not
it is to port that operating system to another architecture.
Even when (hawk, spit, gag) C doesn't work the same on different
architectures?
Got any good examples?  Are you sure it wasn't just a bad
implementation?
C compiler bugs are getting relative rare today.
But the C standard leaves a lot to the implementation.
Character set, actual size of basic data types, ones vs
twos complement, FP format, data alignment, actual size of
size_t, a lot around volatile etc.etc..
Except6 for "volatile" all of this is architecturally or OS
dependent and not a part of the C language.
Post by Arne Vajhøj
This makes it possible to write a "hardware close"
C compiler on any platform.
Probably a deliberate decision.
Post by Arne Vajhøj
But it also makes it a bit tricky to write a C
program with guaranteed behavior on all
standard compliant C compilers.
The parts that are C will behave the same under any non-broken
C compiler. But stuff that is not a part of the C language is
obviously going to be a crap shoot.

The same being true of pretty much every other language. Where
does Fortran define size_t? Where does Pascal define floating
point format? Where does Python define data alignment? COBOL
does let you select character set but it, too, is limited to
what is supported by the architecture or OS. Can't select
Fielddata on a PC using Ryan/McFarland COBOL. :-)

There was a company once that made a car that also functioned
as a boat. Can we now say that all other cars are deficient
because they don't float?

bill
Arne Vajhøj
2021-05-25 14:35:45 UTC
Permalink
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Dave Froble
Post by Simon Clubley
The choice of implementation language does not decide the
functionality
of an operating system. It is however a major factor in how easy or not
it is to port that operating system to another architecture.
Even when (hawk, spit, gag) C doesn't work the same on different
architectures?
Got any good examples?  Are you sure it wasn't just a bad
implementation?
C compiler bugs are getting relative rare today.
But the C standard leaves a lot to the implementation.
Character set, actual size of basic data types, ones vs
twos complement, FP format, data alignment, actual size of
size_t, a lot around volatile etc.etc..
Except6 for "volatile" all of this is architecturally or OS
dependent and not a part of the C language.
All these items are explicit listed as implementation
defined in the C standard.

And defined in other more high level
languages standard.
Post by Bill Gunshannon
Post by Arne Vajhøj
This makes it possible to write a "hardware close"
C compiler on any platform.
Probably a deliberate decision.
Yes.
Post by Bill Gunshannon
Post by Arne Vajhøj
But it also makes it a bit tricky to write a C
program with guaranteed behavior on all
standard compliant C compilers.
The parts that are C will behave the same under any non-broken
C compiler.  But stuff that is not a part of the C language is
obviously going to be a crap shoot.
Not true.

Implementation defined behavior is features that exist in
all implementations of the language but behave differently.

Let us take the example of int. Most C programs will have
a lot of variables of that type.

But the C standard only guarantees that it can keep values
from -32767 to +32767. Any C program that relies on an
int variable keeping a value outside of that range is not
guaranteed to produce same result everywhere.

Doing an >> on it? Better be sure that it is positive. The
result of right shifting a negative int is also implementation
defined.
Post by Bill Gunshannon
The same being true of pretty  much every other language.
No. It may be true of many languages more than 40 years old,
but it is not generally true of newer languages.

Most newer languages define integers that are 16/32/64 bit
two's complement, FP's that are 32/64 bit IEEE, sizes/lengths that
are fixed bit size, memory models that define volatile
behavior etc.. And in memory alignment is typical made
irrelevant because it has to be specified explicit as part
of marshalling and unmarshalling.
Post by Bill Gunshannon
  Where
does Fortran define size_t?  Where does Pascal define floating
point format?  Where does Python define data alignment?  COBOL
does let you select character set but it, too, is limited to
what is supported by the architecture or OS.  Can't select
Fielddata on a PC using Ryan/McFarland COBOL.  :-)
Fortran 1957
Cobol 1959
Pascal 1970

Python does not define alignment for ctypes Structure. But we can blame
that on C.

Documentation states:

<quote>
By default, Structure and Union fields are aligned in the same way the C
compiler does it. It is possible to override this behavior by specifying
a _pack_ class attribute in the subclass definition. This must be set to
a positive integer and specifies the maximum alignment for the fields.
This is what #pragma pack(n) also does in MSVC.
</quote>

So if C got it then Python would get it.
Post by Bill Gunshannon
There was a company once that made a car that also functioned
as a boat.  Can we now say that all other cars are deficient
because they don't float?
No.

But one can say that both floating and non-floating are not
guaranteed characteristics of a car.

Arne
Simon Clubley
2021-05-25 18:07:18 UTC
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
But it also makes it a bit tricky to write a C
program with guaranteed behavior on all
standard compliant C compilers.
The parts that are C will behave the same under any non-broken
C compiler.  But stuff that is not a part of the C language is
obviously going to be a crap shoot.
Not true.
Implementation defined behavior is features that exist in
all implementations of the language but behave differently.
Let us take the example of int. Most C programs will have
a lot of variables of that type.
Even when they should be using unsigned integers but that's no
different to any other languages that make signed integers the default.
Post by Arne Vajhøj
But the C standard only guarantees that it can keep values
from -32767 to +32767. Any C program that relies on an
int variable keeping a value outside of that range is not
guaranteed to produce same result everywhere.
As you should well know Arne, that has been irrelevant for any new code
for at least a couple of decades due to the introduction of data types
whose size (and signed/unsigned attribute) _are_ guaranteed as part of
the standard.

I am of course talking about (for example) uint8_t, int16_t, uint32_t, etc.

If you need a guaranteed integer size in your code, use one of the
above or one of the various other similar data types instead of an int.
Post by Arne Vajhøj
Post by Bill Gunshannon
The same being true of pretty  much every other language.
No. It may be true of many languages more than 40 years old,
but it is not generally true of newer languages.
Most newer languages define integers that are 16/32/64 bit
two's complement, FP's that are 32/64 bit IEEE, sizes/lengths that
are fixed bit size, memory models that define volatile
behavior etc.. And in memory alignment is typical made
irrelevant because it has to be specified explicit as part
of marshalling and unmarshalling.
C also has rules about the scope of volatile statements and what
reordering of statements is and is not allowed by the standard
between volatile points.

Beyond that, you have to know your architecture for the small bits
of your code that need volatile attributes and that level of detail
does not depend on the programming language.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-05-25 18:57:06 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
But it also makes it a bit tricky to write a C
program with guaranteed behavior on all
standard compliant C compilers.
The parts that are C will behave the same under any non-broken
C compiler.  But stuff that is not a part of the C language is
obviously going to be a crap shoot.
Not true.
Implementation defined behavior is features that exist in
all implementations of the language but behave differently.
Let us take the example of int. Most C programs will have
a lot of variables of that type.
Even when they should be using unsigned integers but that's no
different to any other languages that make signed integers the default.
Sometimes signed is needed.

But there are certainly a lot that should be unsigned.
Post by Simon Clubley
Post by Arne Vajhøj
But the C standard only guarantees that it can keep values
from -32767 to +32767. Any C program that relies on an
int variable keeping a value outside of that range is not
guaranteed to produce same result everywhere.
As you should well know Arne, that has been irrelevant for any new code
for at least a couple of decades due to the introduction of data types
whose size (and signed/unsigned attribute) _are_ guaranteed as part of
the standard.
I am of course talking about (for example) uint8_t, int16_t, uint32_t, etc.
If you need a guaranteed integer size in your code, use one of the
above or one of the various other similar data types instead of an int.
Then you know that your code will either work or not compile.

But there is no guarantee that it will work.

These types are optional in the standard.

int_leastn_t and uint_leastn_t are not optional but they are not
exactly widely used.
Post by Simon Clubley
Post by Arne Vajhøj
Post by Bill Gunshannon
The same being true of pretty  much every other language.
No. It may be true of many languages more than 40 years old,
but it is not generally true of newer languages.
Most newer languages define integers that are 16/32/64 bit
two's complement, FP's that are 32/64 bit IEEE, sizes/lengths that
are fixed bit size, memory models that define volatile
behavior etc.. And in memory alignment is typical made
irrelevant because it has to be specified explicit as part
of marshalling and unmarshalling.
C also has rules about the scope of volatile statements and what
reordering of statements is and is not allowed by the standard
between volatile points.
C volatile guarantees that access is not optimized away and that
volatile accesses are not reordered.

Which may be fine when used for direct HW access, but it totally
insufficient for multi-threaded programming.

A bunch of atomic stuff has been added to C 11 to try and solve that.
Post by Simon Clubley
Beyond that, you have to know your architecture for the small bits
of your code that need volatile attributes and that level of detail
does not depend on the programming language.
For many languages the behavior of volatile is defined in the
languages memory model. The generated code and runtime has to
ensure compliant behavior.

Arne
Bob Eager
2021-05-25 20:52:21 UTC
Permalink
Doing an >> on it? Better be sure that it is positive. The result of
right shifting a negative int is also implementation defined.
Which is why one uses unsigned ints.
--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor
Dennis Boone
2021-05-25 22:53:11 UTC
Permalink
Post by Arne Vajhøj
C compiler bugs are getting relative rare today.
Hah! 95 gcc bugs reported in the last week.

https://gcc.gnu.org/bugzilla/buglist.cgi?chfield=%5BBug%20creation%5D&chfieldfrom=7d

De
Arne Vajhøj
2021-05-26 00:50:08 UTC
Permalink
Post by Dennis Boone
Post by Arne Vajhøj
C compiler bugs are getting relative rare today.
Hah! 95 gcc bugs reported in the last week.
https://gcc.gnu.org/bugzilla/buglist.cgi?chfield=%5BBug%20creation%5D&chfieldfrom=7d
Maybe it would be better to say that C compilers have plenty of bugs
today, but rarely impacts the ability to comply with the C standard.

The list above contains for C:
* problem with -Woverride-init
* problem with __builtin_cpu_init()
* problem with __attribute__((unused))
* problem with -Wformat-extra-args
* problem with -Wvla-parameter

Arne
John Dallman
2021-05-17 19:46:00 UTC
Permalink
If you were looking at a C machine model, that would also mean a
design where you were not tied to any architecture specific modes,
so VMS would have been designed around a 2-mode model in that case.
I don't think it's quite that clear. The VAX hardware was designed in
conjunction with VMS, I believe? And more than two modes was picked to
allow the kernel to be protected from bad drivers? There's nothing about
programming in C in itself that dictates a two-model model; UNIX always
works that way, but that's because it evolved to that model.
For example, if your lowest level is C, you can define a pointer
unsigned char *ptr;
The size of that pointer is abstracted away from you and you simply
don't care about that pointer size unless you are working with some
hardware where it matters.
There are more cases than that when you care, notably when you're writing
memory management code, but you can easily find out the size with the
sizeof() function.
In the current VMS design, your lowest level is Macro-32 so you
don't have that level of abstraction and the size of the pointers are
_very_ visible to you and your source code.
Indeed. If addressing other than 32-bit had been considered when the API
was designed, it should have been fairly easy to write a suite of macros
that allowed for instancing the API by address size. However, this was
not done, and it has not been retrofitted, which would be much harder
work. In 1976-78, addressing bigger than 32-bit must have seemed far away.


John
Simon Clubley
2021-05-18 18:43:39 UTC
Permalink
Post by John Dallman
If you were looking at a C machine model, that would also mean a
design where you were not tied to any architecture specific modes,
so VMS would have been designed around a 2-mode model in that case.
I don't think it's quite that clear. The VAX hardware was designed in
conjunction with VMS, I believe? And more than two modes was picked to
allow the kernel to be protected from bad drivers? There's nothing about
programming in C in itself that dictates a two-model model; UNIX always
works that way, but that's because it evolved to that model.
Yes the hardware was designed in that way, but the point of the portable
VMS discussed in the linked article is that portable VMS would not use
any features that tied it to one specific architecture, such as 4 modes
when everyone else is using 2 modes.

BTW, the 4 modes in VMS was a missed opportunity. Unfortunately, the
drivers run in kernel mode along with the rest of the VMS kernel.

Executive mode is where RMS is located.

Supervisor mode is where DCL lives. (It cannot be in user mode because,
due to the design of VMS, DCL has access to the privileges of the
programs it runs).

User mode is where normal user applications run.

VMS as implemented only uses 3 inner modes to protect against
accidental damage. From a security point of view, there is only
one inner mode.

Unix works with only 2 modes because it was designed to be portable
and most of the architectures it runs on only have 2 modes.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Stephen Hoffman
2021-05-19 16:20:54 UTC
Permalink
...Operating system concepts mostly have nothing to do with portability...
Gonna have to decide if you're building new with ease of porting
OpenVMS apps to the new, or building new with close OpenVMS
compatibility with the old.

The former presumably with a path toward more updates and new work and
evolving, while the latter maintaining the existing apps and with less
work for the developers porting the apps.

DEC MICA tried to split this, allowing what amounted to containers for
the operating systems. The modern version being paravirtualized
hypervisors, and Sector7-style porting environments.

The trade-offs continue from there too, including the two- or
four-modes discussions, whether drivers will be included, how much of
POSIX or of .NET, and many thousands of other choices.

And I don't see a viable market for stasis; for OpenVMS not moving
forward, and quickly. Nor a viable market for an alternative to OpenVMS
that isn't moving forward.

I don't see itemlists or descriptors or FAB/RAB/NAML/XAB or the rest of
the existing OpenVMS API design being particularly interesting to
developers, either—not outside of existing code.

Support for OO and FRP would be expected, either in the existing
OpenVMS environment, or as an upgrade path for OpenVMS apps.

Looking at current and future hardware too, we're getting more cores,
more memory and with NUMA and clustering, and with faster storage. But
we're not getting robust support for more modes. Not past two modes
plus hypervisor and enclave support.

But the scale of operating system development work here is
change-back-from-your-billion and that over a decade of work and a
decade of trade-offs, and I'd have to check the couch cushions for that
kind of cash and schedule time.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2021-05-19 17:38:50 UTC
Permalink
Post by Stephen Hoffman
...Operating system concepts mostly have nothing to do with portability...
Gonna have to decide if you're building new with ease of porting
OpenVMS apps to the new, or building new with close OpenVMS
compatibility with the old.
My comment refers back to the linked article where the regret was
that VAX was the architecture instead of VMS being the architecture
that was implemented on a C machine.

With a 2-mode architecture with C as an implementation language, you
could either have had everything that is currently VMS (clusters,
the DLM, VMS APIs, etc) implemented unchanged, or the same functionality
but implemented in a different way (DCL, RMS, etc).

It would have still been VMS, but implemented in a much more portable way.
There is nothing in the above list that would reduce portability to
a new architecture, which is the point I was making.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Stephen Hoffman
2021-05-19 19:07:50 UTC
Permalink
My comment refers back to the linked article where the regret was that
VAX was the architecture instead of VMS being the architecture that was
implemented on a C machine.
With a 2-mode architecture with C as an implementation language, you
could either have had everything that is currently VMS (clusters, the
DLM, VMS APIs, etc) implemented unchanged, or the same functionality
but implemented in a different way (DCL, RMS, etc).
It would have still been VMS, but implemented in a much more portable
way. There is nothing in the above list that would reduce portability
to a new architecture, which is the point I was making.
There are risks and trade-offs in any complex design.

I suspect the influence of Multics among the DEC designers of the VAX era.

Bell Labs took the ideas and designs of Multics in a different
direction with Unix.

As for porting OpenVMS, VSI followed the porting approach used twice
before, rather than the DEC R&D approach prototyped once.

Risks and trade-offs.
--
Pure Personal Opinion | HoffmanLabs LLC
Bill Gunshannon
2021-05-17 22:18:59 UTC
Permalink
Post by Simon Clubley
Post by k***@gmail.com
<http://gordonbell.azurewebsites.net/digital/Bell_Retrospective_PDP11_paper_
c1998.htm>
What Else Did We Need to Know That Could Have Been Useful in the Design of
the VAX-11 to Make Alpha Easier?
"VMS is the Architecture That Mattered. not PDP-11, VAX, or Alpha"
| Thus, our real oversight was not understanding that VMS should have been
| built on the C machine for portability across any architecture.
This. 5 zillion times this. VMS could have become like Unix in dominance
if this had been the case.
Want to move VMS to a new architecture in this setup ? It would have been
a comparable effort to what is involved in porting Linux to yet another
architecture, instead of the current effort that is involved.
VMS was designed at too low of an abstraction level.
Also, while he mentions BLISS, he skips over all the Macro-32 usage
and, based on discussions here, all the internal calling conventions
within the VMS kernel that requires those registers.
Simon.
But is the implementation language the only issue?  I'd think not.  As
John and minions have demonstrated, perhaps with some effort, they can
handle the multiple languages.
Rather, perhaps it is the concepts that are different enough that it's
apples and oranges, not two different types of apples?
For an example, FORK doesn't seem too easy to implement on VMS,
regardless of the language.  Though, I'll admit that this example has
little to do with your claim of ease of porting.
I think fork() could be implemented on VMS if there was a desire
to do it. But it has nothing to do with the language being used.
It's a system call and needs to be in the OS. Then it could be
called from any language. Maybe even DCL. :-)

bill
Loading...