On 2023-08-04 14:20, Simon Clubley wrote:
> On 2023-08-03, John Dallman <jgd@cix.co.uk> wrote:
>> In article <uagvj1$b7r$1@news.misty.com>, bqt@softjar.se (Johnny
>> Billquist) wrote:
>>
>>> On 2023-08-03 14:10, Simon Clubley wrote:
>>>> I still wish Prism had become a thing. That would have changed a
>>>> lot of things and (IMHO) for the better, both at hardware and
>>>> especially software level.
>>>
>>> Weren't bits of Prism reused in Alpha? Or am I mixing it up with
>>> something else now?
>>
>> Bits of the hardware design, yes. The OS design was abandoned by DEC; the
>> concept re-appeared in Windows NT's subsystem architecture, but over time,
>> only the Windows subsystem has survived.
>>
>
> Yes, the software (a new OS, a new safer alternative to C, etc) would
> have been the most important thing long-term. Oh, well.

Not so sure I would have been very happy or impressed by some Pascal
derivate. Those languages have their own issues, which in my opinion,
makes them worse, although in other ways.

But Mica also allowed C for implementation of stuff, so I would suspect
had it survived, it would have become just as C centric as everything else.

Johnny

On 7/24/2023 8:50 PM, Arne Vajhøj wrote:
> On 7/24/2023 1:12 PM, Simon Clubley wrote:
>> We are talking about structural and design issues within VMS that is
>> making this porting process a lot more involved than it should be.
>
> There are two very different questions:
>
> #1: Did DEC's decisions in 1977 make sense given 1977 knowledge?
>
> #2: Did DEC's decisions in 1977 make sense given 2023 knowledge?
>
> I believe the answer to #1 is YES. Their decisions was similar to how
> most OS was designed at the time.
>
> The answer to #2 is probably NO, because they should have gone
> with a HLL, they should have prepared for future migrations to other
> ISA, they should have prepared for 64 bit, they should have
> focused more on security etc.etc..
>
> But trying to evaluate decisions of the past using todays
> knowledge is a totally futile exercise.
>
> If you plan on inventing a time machine and travel back in
> time to tell them to do things differently, then maybe. But
> otherwise then accept that decisions was made based on
> available information at the time for the decisions. And
> complaining about such decisions does not change a thing.
>
> There is a term for it "Monday morning quarterback".

Since the "DEC did it wrong" line is coming up
again I did an attempt to verify my claim about
#1 above.

There is an obvious case: Data General was
in a relative similar situation to DEC.

DEC had a PDP-11 mini-computer with various 16 bit OS (RSX,
RSTS/E, RT-11, IAS etc.) and they came up with the VAX
and the 32 bit VMS.

Data General had an Eclipse mini-computer with 16 bit AOS
and they came up with the Eclipse MV with the 32 bit AOS/VS.

Same business problem. Same point in time.

So I tried to compare design.

(disclaimer: for Eclipse MV and AOS/VS entirely based
on various internet source - I have no experience with
them myself)

VAX + VMS Eclipse MV + AOS/VS
--------- -------------------

CISC CISC
32 bit virtual byte addresses 31 bit virtual word addresses
4 GB address space 4 GB address space
512 byte pages 2 KB pages
16 bit compatibility mode 16 bit compatibility mode
4 modes: 8 modes:
K (0) - VMS 0 - kernel
E (1) - RMS & Rdb 1 - virtual adress translation
S (2) - DCL 2 - unused
U (3) - application 3 - IO buffering & compatibility
4 - DG database
5 - Oracle database
6 - available for large
applications
7 - applications
memory organized: memory organized in 512 MB
segments one per mode
P0 - heap
P1 - stack
S0 - OS
S1 - unused (early VMS)
processes processes + threads (called tasks)
kernel in Macro-32 or Bliss kernel in assembler
utilities in Macro-32 or Bliss or HLL utilities in Algol dialect

Not similar enough to suspect industrial espionage but similar
enough to support my claim that DEC choices back then made
sense given what was known.

Arne

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:

[ snip ]

> There is an obvious case: Data General was in a relative similar situation to
> DEC.

> DEC had a PDP-11 mini-computer with various 16 bit OS (RSX, RSTS/E, RT-11,
> IAS etc.) and they came up with the VAX and the 32 bit VMS.

> Data General had an Eclipse mini-computer with 16 bit AOS and they came up
> with the Eclipse MV with the 32 bit AOS/VS.

The Eclipse was an extension of the 16 bit Nova family, with additional
instructions done by changing the meaning of certain NOPs.

> Same business problem. Same point in time.

> So I tried to compare design.

> (disclaimer: for Eclipse MV and AOS/VS entirely based on various internet
> source - I have no experience with them myself)

> VAX + VMS Eclipse MV + AOS/VS
> --------- -------------------

> CISC CISC
> 32 bit virtual byte addresses 31 bit virtual word addresses
> 4 GB address space 4 GB address space
> 512 byte pages 2 KB pages
> 16 bit compatibility mode 16 bit compatibility mode

Wrong! See below.

> 4 modes: 8 modes:
> K (0) - VMS 0 - kernel
> E (1) - RMS & Rdb 1 - virtual adress translation
> S (2) - DCL 2 - unused
> U (3) - application 3 - IO buffering & compatibility
> 4 - DG database
> 5 - Oracle database
> 6 - available for large applications
> 7 - applications
> memory organized: memory organized in 512 MB segments one per mode
> P0 - heap
> P1 - stack
> S0 - OS
> S1 - unused (early VMS)
> processes processes + threads (called tasks)
> kernel in Macro-32 or Bliss kernel in assembler
> utilities in Macro-32 or Bliss or HLL utilities in Algol dialect

> Not similar enough to suspect industrial espionage but similar enough to
> support my claim that DEC choices back then made sense given what was known.

Unlike the PDP-11 mode bit in the VAX, the MV/8000 used the same method as the
Eclipse to add 32 bit intructions to the mix: A previously unused set of NOPs
was turned into the prefixes for the 32 bit instruction set.

I refer you to a nontechnical description of the development of the MV/8000,
Tracy Kidder's _The Soul of a New Machine_, and to the historical pages
available from Wild Hare (wildhare.org), Bruce Ray's company which now holds
the rights to all of the Data General software.

Disclaimer: I have no dog in this fight. Bruce is a good friend, but I've never
worked on DG systems.

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

On 8/22/2023 9:36 PM, Rich Alderson wrote:
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>> VAX + VMS Eclipse MV + AOS/VS
....>> --------- -------------------

>> 16 bit compatibility mode 16 bit compatibility mode
>
> Wrong! See below.

> Unlike the PDP-11 mode bit in the VAX, the MV/8000 used the same method as the
> Eclipse to add 32 bit intructions to the mix: A previously unused set of NOPs
> was turned into the prefixes for the 32 bit instruction set.

So you say that the Eclipse MV was "Eclipse compatible" instead
of having "Eclipse compatibility mode"?

Arne

On Tuesday, August 22, 2023 at 10:16:51 PM UTC-4, Arne Vajhøj wrote:
> So you say that the Eclipse MV was "Eclipse compatible" instead
> of having "Eclipse compatibility mode"?

"NO mode bit!!!"

The hardware isn't as simple as Nova -> Eclipse -> Eclipse MV. The Nova 4 used an AMD 29xx bit-slice implementation very similar to the Eclipse S/140 hardware. Early Novas were hardwired logic. Later Novas and older Eclipsen were 181-based. The S/140 and later used a variety of implementations. Eclipse CPUs came in a variety of flavors. The original S-series, the C-series commercial machines, and the M-series with only one model (600) which was an attempt to market a maxed-out system dedicated to running AOS. There are a bunch of oddball internal differences that nobody but operating system programmers would care about between the S-series CPUs. I know about them because back in the day I created the "Frankenclipse" which was a S/230-class processor built out of a S/200. It passed all S/230 diagnostics (including EMORTL) if the hardware was slowed down, but would no longer pass the S/100 diagnostics. 64 interactive terminals on a 16-bit CPU.

DG wasn't quite as extravagant as DEC was when creating multiple operating systems and language implementations. But they had RTOS (magtape or core-resident), DOS (primitive), RDOS (very common), AOS (incompatible with RTOS/RDOS but gained in popularity) and AOS/VS (32-bit). They had an extended BASIC (XBASIC) and later on a commercial BASIC (CBASIC) which weren't really compatible. I think CBASIC was bought in from outside, but I never worked on it and didn't see the source code, so I can't say for sure.

In article <u9n69c$r61o$1@dont-email.me>, arne@vajhoej.dk (Arne Vajh�j)
wrote:

> There are two very different questions:
>
> #1: Did DEC's decisions in 1977 make sense given 1977 knowledge?
>
> I believe the answer to #1 is YES. Their decisions was similar to
> how most OS was designed at the time.

The decisions in 1977 were defensible, but not forward-looking. Operating
systems written in high-level languages already existed, and
microprocessor-based machines offered a possibility of computers becoming
much cheaper. VAX/VMS solved the problems of the recent past, quite well,
but did not anticipate the future.

John

On 2023-08-22, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> VAX + VMS Eclipse MV + AOS/VS
> --------- -------------------
>
> CISC CISC
> 32 bit virtual byte addresses 31 bit virtual word addresses
> 4 GB address space 4 GB address space
> 512 byte pages 2 KB pages
> 16 bit compatibility mode 16 bit compatibility mode
> 4 modes: 8 modes:
> K (0) - VMS 0 - kernel
> E (1) - RMS & Rdb 1 - virtual adress translation
> S (2) - DCL 2 - unused
> U (3) - application 3 - IO buffering & compatibility
> 4 - DG database
> 5 - Oracle database
> 6 - available for large
> applications
> 7 - applications
> memory organized: memory organized in 512 MB
> segments one per mode
> P0 - heap
> P1 - stack
> S0 - OS
> S1 - unused (early VMS)
> processes processes + threads (called tasks)
> kernel in Macro-32 or Bliss kernel in assembler
> utilities in Macro-32 or Bliss or HLL utilities in Algol dialect
>

Based purely on what you write above, the use of an Algol dialect for
writing their userland code is a _massive_ win over the DEC approach
and _far_ superior to the way DEC did things.

Wish DEC had done the same.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 8/23/2023 2:44 AM, John Dallman wrote:
> In article <u9n69c$r61o$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
> wrote:
>> There are two very different questions:
>>
>> #1: Did DEC's decisions in 1977 make sense given 1977 knowledge?
>>
>> I believe the answer to #1 is YES. Their decisions was similar to
>> how most OS was designed at the time.
>
> The decisions in 1977 were defensible, but not forward-looking. Operating
> systems written in high-level languages already existed, and
> microprocessor-based machines offered a possibility of computers becoming
> much cheaper. VAX/VMS solved the problems of the recent past, quite well,
> but did not anticipate the future.

It is difficult to anticipate the future.

They made some choices that looked OK at the time.

I suspect that it reflect the leadership.

the engineering approach: let us choose something
that we are 99.9% sure to work fine

the visionary approach: let us choose something
where there is 50% chance of huge success and
50% chance of total failure

Engineers are trained to build stuff that is guaranteed
to work.

The Steve Jobs and Elon Musk types takes a chance - sometimes
it works - sometimes it doesn't work.

Arne

On 8/23/2023 4:40 PM, Arne Vajhøj wrote:
> On 8/23/2023 2:44 AM, John Dallman wrote:
>> In article <u9n69c$r61o$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
>> wrote:
>>> There are two very different questions:
>>>
>>> #1: Did DEC's decisions in 1977 make sense given 1977 knowledge?
>>>
>>> I believe the answer to #1 is YES. Their decisions was similar to
>>> how most OS was designed at the time.
>>
>> The decisions in 1977 were defensible, but not forward-looking. Operating
>> systems written in high-level languages already existed, and
>> microprocessor-based machines offered a possibility of computers becoming
>> much cheaper. VAX/VMS solved the problems of the recent past, quite well,
>> but did not anticipate the future.
>
> It is difficult to anticipate the future.
>
> They made some choices that looked OK at the time.
>
> I suspect that it reflect the leadership.
>
> the engineering approach: let us choose something
> that we are 99.9% sure to work fine
>
> the visionary approach: let us choose something
> where there is 50% chance of huge success and
> 50% chance of total failure
>

The marketing approach: Just tell the customer that it will
do everything, even make coffee. Then over-price it and move
on.

And there you have the Digital timeline. :-)

> Engineers are trained to build stuff that is guaranteed
> to work.
>
> The Steve Jobs and Elon Musk types takes a chance - sometimes
> it works - sometimes it doesn't work.

bill

On 8/23/2023 4:40 PM, Arne Vajhøj wrote:
> On 8/23/2023 2:44 AM, John Dallman wrote:
>> In article <u9n69c$r61o$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
>> wrote:
>>> There are two very different questions:
>>>
>>> #1: Did DEC's decisions in 1977 make sense given 1977 knowledge?
>>>
>>> I believe the answer to #1 is YES. Their decisions was similar to
>>> how most OS was designed at the time.
>>
>> The decisions in 1977 were defensible, but not forward-looking. Operating
>> systems written in high-level languages already existed, and
>> microprocessor-based machines offered a possibility of computers becoming
>> much cheaper. VAX/VMS solved the problems of the recent past, quite well,
>> but did not anticipate the future.
>
> It is difficult to anticipate the future.
>
> They made some choices that looked OK at the time.

Back in the day we had a saying.

Buy the computer you need now. If you wait for the next greatest thing, you'll
never get a new computer.

Still good advice.

As for anticipating the future, should all auto manufacturers plan now for
counter-grav? That's about the same as some of the comments I've read here.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2023-08-23 04:16, Arne Vajhøj wrote:
> On 8/22/2023 9:36 PM, Rich Alderson wrote:
>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>>> VAX + VMS                               Eclipse MV + AOS/VS
> ...>> ---------                               -------------------
>
>>> 16 bit compatibility mode               16 bit compatibility mode
>>
>> Wrong!  See below.
>
>> Unlike the PDP-11 mode bit in the VAX, the MV/8000 used the same
>> method as the
>> Eclipse to add 32 bit intructions to the mix:  A previously unused set
>> of NOPs
>> was turned into the prefixes for the 32 bit instruction set.
>
> So you say that the Eclipse MV was "Eclipse compatible" instead
> of having "Eclipse compatibility mode"?

I think there was a famous quote about this:
"We will *not* have a compatibility mode bit like the VAX did!".

Johnny

On 2023-08-23 14:35, Simon Clubley wrote:
> On 2023-08-22, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> VAX + VMS Eclipse MV + AOS/VS
>> --------- -------------------
>>
>> CISC CISC
>> 32 bit virtual byte addresses 31 bit virtual word addresses
>> 4 GB address space 4 GB address space
>> 512 byte pages 2 KB pages
>> 16 bit compatibility mode 16 bit compatibility mode
>> 4 modes: 8 modes:
>> K (0) - VMS 0 - kernel
>> E (1) - RMS & Rdb 1 - virtual adress translation
>> S (2) - DCL 2 - unused
>> U (3) - application 3 - IO buffering & compatibility
>> 4 - DG database
>> 5 - Oracle database
>> 6 - available for large
>> applications
>> 7 - applications
>> memory organized: memory organized in 512 MB
>> segments one per mode
>> P0 - heap
>> P1 - stack
>> S0 - OS
>> S1 - unused (early VMS)
>> processes processes + threads (called tasks)
>> kernel in Macro-32 or Bliss kernel in assembler
>> utilities in Macro-32 or Bliss or HLL utilities in Algol dialect
>>
>
> Based purely on what you write above, the use of an Algol dialect for
> writing their userland code is a _massive_ win over the DEC approach
> and _far_ superior to the way DEC did things.
>
> Wish DEC had done the same.

I think when it came to utilities, very little was in Macro-32, and most
were in Bliss or some other HLL. Can't say that I'd consider everything
written in some Algol dialect to be a massive win over that.

Johnny

On 2023-08-23 08:44, John Dallman wrote:
> In article <u9n69c$r61o$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
> wrote:
>
>> There are two very different questions:
>>
>> #1: Did DEC's decisions in 1977 make sense given 1977 knowledge?
>>
>> I believe the answer to #1 is YES. Their decisions was similar to
>> how most OS was designed at the time.
>
> The decisions in 1977 were defensible, but not forward-looking. Operating
> systems written in high-level languages already existed, and
> microprocessor-based machines offered a possibility of computers becoming
> much cheaper. VAX/VMS solved the problems of the recent past, quite well,
> but did not anticipate the future.

I think it was way more about meeting the existing demands of their
existing customers. You had this large customer base running PDP-11s
with RSX and RSTE/E (primarily), who wanted something bigger, and was
willing to pay for it.
So that is what DEC built. Both hardware and software wise.
And it makes *total* sense. You build what your customers as for, and
you try to also plan a little bit for the future. But you don't build
something that is contrary to what the customers ask for.

Johnny

Op 24.aug..2023 om 12:08 schreef Johnny Billquist:
> On 2023-08-23 14:35, Simon Clubley wrote:
>> On 2023-08-22, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>
>>> VAX + VMS                               Eclipse MV + AOS/VS
>>> ---------                               -------------------
>>>
>>> CISC                                    CISC
>>> 32 bit virtual byte addresses           31 bit virtual word addresses
>>> 4 GB address space                      4 GB address space
>>> 512 byte pages                          2 KB pages
>>> 16 bit compatibility mode               16 bit compatibility mode
>>> 4 modes:                                8 modes:
>>>     K (0) - VMS                             0 - kernel
>>>     E (1) - RMS & Rdb                       1 - virtual adress
>>> translation
>>>     S (2) - DCL                             2 - unused
>>>     U (3) - application                     3 - IO buffering &
>>> compatibility
>>>                                             4 - DG database
>>>                                             5 - Oracle database
>>>                                             6 - available for large
>>> applications
>>>                                             7 - applications
>>> memory organized:                      memory organized in 512 MB
>>> segments one per mode
>>>     P0 - heap
>>>     P1 - stack
>>>     S0 - OS
>>>     S1 - unused (early VMS)
>>> processes                               processes + threads (called
>>> tasks)
>>> kernel in Macro-32 or Bliss             kernel in assembler
>>> utilities in Macro-32 or Bliss or HLL   utilities in Algol dialect
>>>
>>
>> Based purely on what you write above, the use of an Algol dialect for
>> writing their userland code is a _massive_ win over the DEC approach
>> and _far_ superior to the way DEC did things.
>>
>> Wish DEC had done the same.
>
> I think when it came to utilities, very little was in Macro-32, and most
> were in Bliss or some other HLL. Can't say that I'd consider everything
> written in some Algol dialect to be a massive win over that.
>
>   Johnny
>

I remember that in very early VMS versions (1.5 or slightly later) the
'directory' command sometimes displayed FORTRAN errors. :)

On 2023-08-23, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> It is difficult to anticipate the future.
>
> They made some choices that looked OK at the time.
>
> I suspect that it reflect the leadership.
>
> the engineering approach: let us choose something
> that we are 99.9% sure to work fine
>
> the visionary approach: let us choose something
> where there is 50% chance of huge success and
> 50% chance of total failure
>
> Engineers are trained to build stuff that is guaranteed
> to work.
>

And DEC had a very frustrating mix of being both not visionary and
then doing something that was very visionary.

First, they did the VMS design, which is most certainly not visionary,
but then a few years later they gave us a cluster design that was
literally a generation ahead of everyone else.

They also gave us the aborted Mica/Prism architecture, which would have
also been unique at the time. Oh, well.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Wednesday, 23 August 2023 at 10:35:40 pm UTC+10, Simon Clubley wrote:
> On 2023-08-22, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >
> > VAX + VMS Eclipse MV + AOS/VS
> > --------- -------------------
> >
> > CISC CISC
> > 32 bit virtual byte addresses 31 bit virtual word addresses
> > 4 GB address space 4 GB address space
> > 512 byte pages 2 KB pages
> > 16 bit compatibility mode 16 bit compatibility mode
> > 4 modes: 8 modes:
> > K (0) - VMS 0 - kernel
> > E (1) - RMS & Rdb 1 - virtual adress translation
> > S (2) - DCL 2 - unused
> > U (3) - application 3 - IO buffering & compatibility
> > 4 - DG database
> > 5 - Oracle database
> > 6 - available for large
> > applications
> > 7 - applications
> > memory organized: memory organized in 512 MB
> > segments one per mode
> > P0 - heap
> > P1 - stack
> > S0 - OS
> > S1 - unused (early VMS)
> > processes processes + threads (called tasks)
> > kernel in Macro-32 or Bliss kernel in assembler
> > utilities in Macro-32 or Bliss or HLL utilities in Algol dialect
> >
> Based purely on what you write above, the use of an Algol dialect for
> writing their userland code is a _massive_ win over the DEC approach
> and _far_ superior to the way DEC did things.
>
> Wish DEC had done the same.
> Simon.

Off topic a bit, but we had already left the original topic.
I used to work for NCR in the 1970s on their I-series machines,
these were minis that would compete with the VAX when it came out (1977)
as well as with Burroughs Univac and IBM and some others (DG HP)
All the OS and utilities were written in a block structured ALGOL-like language,
When a machine was installed at a customer site, one of the first things to do
was to run a sysgen, which compiled and linked all this to build a system image to run,
this was then saved to disk for subsequent use.
This in-house language was strictly for use only by systems programmers in
head office, and not released (AFAIK), but the resultant systems proved very reliable.
But then DEC in the 1980s was way more successful than NCR or DG anyway...

Phil

On 8/24/2023 8:14 AM, Simon Clubley wrote:
> On 2023-08-23, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> It is difficult to anticipate the future.
>>
>> They made some choices that looked OK at the time.
>>
>> I suspect that it reflect the leadership.
>>
>> the engineering approach: let us choose something
>> that we are 99.9% sure to work fine
>>
>> the visionary approach: let us choose something
>> where there is 50% chance of huge success and
>> 50% chance of total failure
>>
>> Engineers are trained to build stuff that is guaranteed
>> to work.
>>
>
> And DEC had a very frustrating mix of being both not visionary and
> then doing something that was very visionary.
>
> First, they did the VMS design, which is most certainly not visionary,
> but then a few years later they gave us a cluster design that was
> literally a generation ahead of everyone else.
>
> They also gave us the aborted Mica/Prism architecture, which would have
> also been unique at the time. Oh, well.
>
> Simon.
>

Not sure what other people's definition of "visionary" might be. For me, the
DLM was very visionary. Often copied. That and IBM's Sysplex sort of led the
way in this direction.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Arne Vajhøj wrote:
> On 8/22/2023 9:36 PM, Rich Alderson wrote:
>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>>> VAX + VMS Eclipse MV + AOS/VS
> ...>> --------- -------------------
>
>>> 16 bit compatibility mode 16 bit compatibility mode
>>
>> Wrong! See below.
>
>> Unlike the PDP-11 mode bit in the VAX, the MV/8000 used the same
>> method as the
>> Eclipse to add 32 bit intructions to the mix: A previously unused set
>> of NOPs
>> was turned into the prefixes for the 32 bit instruction set.
>
> So you say that the Eclipse MV was "Eclipse compatible" instead
> of having "Eclipse compatibility mode"?

Yes, NOVA, Eclipse, and MV instructions could all be (and were) mixed in
the same program. They would generally be mixed in the same subroutine.

Except for a few hardware functions (e.g., auto increment and auto
decrement locations), Eclipse or Nova software could run directly on the MV.

Another correction: The MV had two only modes, privileged and
non-privileged.

The "modes" referred to in the original post were memory "rings".

The MV used a segmented/paged memory model. The upper most bit of an
address was (usually) the indirection bit and the next three bits were
the segment number.

A single program would exist entirely within a single segment. A program
could reference memory in its own segment or outer (higher segment
number) segments, but could not access inner memory. This is similar to
the VAX KESU memory protections, but instead of doing it on a page by
page basis, this was done on a segment by segment basis and was implicit
in the address.

Within a segment, there would be a page table to support virtual memory.

For privileged system calls, a program would make an inner ring call
using a gateway. That is, the call address would include a function
number instead of an inner mode address. This ring to ring transition
was handled by the firmware. (Similar to the VAX CHMx instructions.)
The gateway function is similar to what Intel is doing now with the SGX
extension.

AOS/VS laid out the rings as:

0: Kernel
1: PMGR
7: user programs

Kernel only supported block mode devices. PMGR handled non-block (e.g.,
terminals) devices and mapped to the appropriate Kernel calls.

Other rings could have various programs loaded into them depending on
what the system needed. Databases and filesystems quite often went into
rings. Debuggers could live in a ring.

Also be aware that Data General could be considered to be a spin off
from DEC. Read up on its rather interesting history.

--
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: chris@applied-synergy.com
Fax: 817-237-3074

On 8/24/2023 6:08 AM, Johnny Billquist wrote:
> On 2023-08-23 14:35, Simon Clubley wrote:
>> On 2023-08-22, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> VAX + VMS                               Eclipse MV + AOS/VS
>>> ---------                               -------------------
....
>>> kernel in Macro-32 or Bliss             kernel in assembler
>>> utilities in Macro-32 or Bliss or HLL   utilities in Algol dialect
>>
>> Based purely on what you write above, the use of an Algol dialect for
>> writing their userland code is a _massive_ win over the DEC approach
>> and _far_ superior to the way DEC did things.
>>
>> Wish DEC had done the same.
>
> I think when it came to utilities, very little was in Macro-32, and most
> were in Bliss or some other HLL. Can't say that I'd consider everything
> written in some Algol dialect to be a massive win over that.

Isn't DCL or at least large parts of in Macro-32?

Arne

On 8/24/2023 6:05 AM, Johnny Billquist wrote:
> On 2023-08-23 04:16, Arne Vajhøj wrote:
>> On 8/22/2023 9:36 PM, Rich Alderson wrote:
>>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>>>> VAX + VMS                               Eclipse MV + AOS/VS
>> ...>> ---------                               -------------------
>>
>>>> 16 bit compatibility mode               16 bit compatibility mode
>>>
>>> Wrong!  See below.
>>
>>> Unlike the PDP-11 mode bit in the VAX, the MV/8000 used the same
>>> method as the
>>> Eclipse to add 32 bit intructions to the mix:  A previously unused
>>> set of NOPs
>>> was turned into the prefixes for the 32 bit instruction set.
>>
>> So you say that the Eclipse MV was "Eclipse compatible" instead
>> of having "Eclipse compatibility mode"?
>
> I think there was a famous quote about this:
> "We will *not* have a compatibility mode bit like the VAX did!".

But if we look at this from the high level.

Both DEC and DG considered it important to be able to
run old 16 bit applications on their new 32 bit system.

Both DEC and DG was willing to add support for the
16 bit instructions in the hardware (as opposed to
DEC a little over a decade later when the 64 bit support
for 32 bit applications was software based: VEST).

DEC chose to have the VAX switch mode between 32 and
16 bit instructions (similar to what AMD did a couple
of decades later).

DG chose to support both instruction sets at the
same time.

Both DEC and DG achieved the business goal of being
able to run both old 16 bit applications and new
32 bit applications.

DG approach seems more elegant as it must have
allowed new 32 bit code to call old 16 bit code
within the same program. If someone knew how to
ensure that everything got set up properly (somewhat
similar to VMS code today using 64 bit pointers needing
to call code using 32 bit pointers - you better have
the data in P0 and not P2).

Arne

On Friday, August 25, 2023 at 8:33:10 PM UTC-4, Arne Vajhøj wrote:
> On 8/24/2023 6:05 AM, Johnny Billquist wrote:
> > On 2023-08-23 04:16, Arne Vajhøj wrote:
> >> On 8/22/2023 9:36 PM, Rich Alderson wrote:
> >>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> writes:
> >>>> VAX + VMS Eclipse MV + AOS/VS
> >> ...>> --------- -------------------
> >>
> >>>> 16 bit compatibility mode 16 bit compatibility mode
> >>>
> >>> Wrong! See below.
> >>
> >>> Unlike the PDP-11 mode bit in the VAX, the MV/8000 used the same
> >>> method as the
> >>> Eclipse to add 32 bit intructions to the mix: A previously unused
> >>> set of NOPs
> >>> was turned into the prefixes for the 32 bit instruction set.
> >>
> >> So you say that the Eclipse MV was "Eclipse compatible" instead
> >> of having "Eclipse compatibility mode"?
> >
> > I think there was a famous quote about this:
> > "We will *not* have a compatibility mode bit like the VAX did!".
> But if we look at this from the high level.
>
> Both DEC and DG considered it important to be able to
> run old 16 bit applications on their new 32 bit system.
>
> Both DEC and DG was willing to add support for the
> 16 bit instructions in the hardware (as opposed to
> DEC a little over a decade later when the 64 bit support
> for 32 bit applications was software based: VEST).
>
> DEC chose to have the VAX switch mode between 32 and
> 16 bit instructions (similar to what AMD did a couple
> of decades later).
>
> DG chose to support both instruction sets at the
> same time.
>
> Both DEC and DG achieved the business goal of being
> able to run both old 16 bit applications and new
> 32 bit applications.
>
> DG approach seems more elegant as it must have
> allowed new 32 bit code to call old 16 bit code
> within the same program. If someone knew how to
> ensure that everything got set up properly (somewhat
> similar to VMS code today using 64 bit pointers needing
> to call code using 32 bit pointers - you better have
> the data in P0 and not P2).
>
> Arne
VEST was not intended to be a vehicle for 32 programs to be transformed into 64 bit. It was intended for VAX programs to run under Alpha without the need for having source code access. Many customers were happy that this worked as well as it did because of their lack of original source. VESTed programs still had access only to 3 bit space. There are sites today still running VESTed images on Alpha systems.

Dan

On 8/25/2023 10:36 PM, abrsvc wrote:
> On Friday, August 25, 2023 at 8:33:10 PM UTC-4, Arne Vajhøj wrote:
>> Both DEC and DG considered it important to be able to
>> run old 16 bit applications on their new 32 bit system.
>>
>> Both DEC and DG was willing to add support for the
>> 16 bit instructions in the hardware (as opposed to
>> DEC a little over a decade later when the 64 bit support
>> for 32 bit applications was software based: VEST).
>
> VEST was not intended to be a vehicle for 32 programs to be transformed into 64 bit.

No it was a software solution to the problem of running
application from old architecture on new architecture
solved via sofware instead of via hardware.

> It was intended for VAX programs to run under Alpha without the need for
> having source code access. Many customers were happy that this worked as
> well as it did because of their lack of original source. VESTed
> programs still had access only to 3 bit space. There are sites today
> still running VESTed images on Alpha systems.

I am sure a lot of early VMS customers were also happy with
compatibility mode. It solved a problem.

The solution back then was just different.

Arne

In article <ucbh82$8kpo$2@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>[snip]
>DEC chose to have the VAX switch mode between 32 and
>16 bit instructions (similar to what AMD did a couple
>of decades later).

One presumes you are referring to amd64 here. If so, then nope,
amd64 is an extension to 32-bit x86, not a replacement in the
sense that the VAX ISA replaced the PDP-11 ISA when the mode bit
was set.

Even in 64-bit mode, many (most?) programs will continue to
operate as expected with 32- and even many 16- bit instructions.
The same was not true of the VAX.

>DG chose to support both instruction sets at the
>same time.

Perhaps you should read, "Soul of a New Machine."

- Dan C.

On 8/26/2023 9:34 AM, Dan Cross wrote:
> In article <ucbh82$8kpo$2@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> [snip]
>> DEC chose to have the VAX switch mode between 32 and
>> 16 bit instructions (similar to what AMD did a couple
>> of decades later).
>
> One presumes you are referring to amd64 here. If so, then nope,
> amd64 is an extension to 32-bit x86, not a replacement in the
> sense that the VAX ISA replaced the PDP-11 ISA when the mode bit
> was set.
>
> Even in 64-bit mode, many (most?) programs will continue to
> operate as expected with 32- and even many 16- bit instructions.
> The same was not true of the VAX.

x86-64 in long mode has an emulation mode set via
an emulation bit that allows it to execute 32 bit
programs.

That is the same as what VAX did for PDP-11
compatibility.

The rule is that one cannot mix 64 bit and 32 bit
code in the same process.

Most 32 bit instructions actually work identical
in 64 bit mode, but some produce different results
and some causes a crash.

So executing 32 bit code not in compatibility mode
is a big no no.

Arne

In article <ucdapd$ljc8$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 8/26/2023 9:34 AM, Dan Cross wrote:
>> In article <ucbh82$8kpo$2@dont-email.me>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> [snip]
>>> DEC chose to have the VAX switch mode between 32 and
>>> 16 bit instructions (similar to what AMD did a couple
>>> of decades later).
>>
>> One presumes you are referring to amd64 here. If so, then nope,
>> amd64 is an extension to 32-bit x86, not a replacement in the
>> sense that the VAX ISA replaced the PDP-11 ISA when the mode bit
>> was set.
>>
>> Even in 64-bit mode, many (most?) programs will continue to
>> operate as expected with 32- and even many 16- bit instructions.
>> The same was not true of the VAX.
>
>x86-64 in long mode has an emulation mode set via
>an emulation bit that allows it to execute 32 bit
>programs.
>
>That is the same as what VAX did for PDP-11
>compatibility.

Not even close. PDP-11 compatibility mode on the VAX uses an
entirely different instruction encoding (PDP-11 encoding for
PDP-11 instructions) compared to VAX-native instructions.
http://bitsavers.trailing-edge.com/pdf/dec/vax/archSpec/EY-3459E-DP_VAX_Architecture_Reference_Manual_1987.pdf

By contrast, AMD64 mode shares most of the instruction space
with 32-bit x86. `xorl %eax, %eax` works just fine in either
32-bit or 64-bit mode, with the exact same encoding. AMD used
a prefix byte to indicate 64-bit operands to instructions.
For example, see Chapter 2 of
https://cdrdv2.intel.com/v1/dl/getContent/671110

Of course, the semantics of a few instructions do change (the
size of words on the stack changes, for example, so the `PUSH`
instruction behaves differently in 64-bit mode), but in this
regard, the mechanism is closer to what DG did than what DEC
did.

>The rule is that one cannot mix 64 bit and 32 bit
>code in the same process.

You should define what you mean here. What do you mean by
"64-bit" and "32-bit" code? And what do you mean when you say
that you "cannot mix" them "in the same process"? As I
mentioned above, the instruction encoding is _mostly_ the same.

>Most 32 bit instructions actually work identical
>in 64 bit mode, but some produce different results
>and some causes a crash.

Correct.

>So executing 32 bit code not in compatibility mode
>is a big no no.

Incorrect. Indeed, the optimization manual encourages using
32-bit instructions (ie, without a REX prefix) in some common
code sequences, even in 64-bit mode, for efficiency reasons.
For example, the quickest way to clear, e.g., `%rax` is
`xorl %eax, %eax`, as this is defined to sign-extend the upper
half of the register, and this has a more compact encoding.
https://cdrdv2.intel.com/v1/dl/getContent/671488. See section
13.2.1 in particular, which directly contradicts your assertion
about 32-bit code in 64-bit mode:

|Assembly/Compiler Coding Rule 56. (H impact, M generality)
|Use the 32-bit versions of instructions in 64-bit mode to
|reduce code size unless the 64-bit version is necessary to
|access 64-bit data or additional registers.

Regardless, the salient point is that what x86 did is not a
universe switch into a totally foreign (non-native) ISA. You
seem to be comflating this with difficulties stemming from
running totally unmodified 32-bit programs that assume a 32-bit
execution mode while in 64-bit mode. But that is qualitatively
different than how instructions are encoded and used on x86 with
respect to the processor "mode", which is almost nothing like
how the VAX treated PDP-11 compatibility mode.

- Dan C.