In another example, of synchronicity, this was posted today on ARS technica

https://arstechnica.com/gadgets/2023/10/long-gone-dec-is-still-powering-the-world-of-computing/

(gets some stuff wrong)
Neil Rieck
Waterloo, Ontario, Canada.
https://neilrieck.net
https://neilrieck.net/OpenVMS.html

On 10/4/2023 6:24 PM, bill wrote:
<snip>
> I always find it funny when I see this comment.
> Unisys (formerly UNIVAC) is doing just fine with their 2200 which
> is the follow on from and compatible with the old 1100.  As a
> matter of fact, two of the largest ISes in use today run on
> Unisys after running for more than a decade on the 1100.

Unisys was born from the merger of UNIVAC and Burroughs. Both the UNIVAC
2200 and the Burroughs Large Systems architectures survive as the
ClearPath OS 2200 and ClearPath MCP, respectively:

https://www.unisys.com/solutions/enterprise-computing/clearpath-forward/#systems

I worked at a university that transitioned from a Burroughs mainframe to
an 11/780, with a couple of 11/750s clustered in later. There was quite
a learning curve, but DEC's excellent documentation made it easier.

Louis

On Monday, October 2, 2023 at 10:33:03 PM UTC-7, jimc...@gmail.com wrote:
> On Sunday, September 24, 2023 at 7:10:45 AM UTC-7, John Dallman wrote:
>
> > The idea of running VMS on a terminal with a total of 64KB of RAM and ROM
> > in 1982 seems implausible now, but it seems to have been the reason for
> > 512-byte pages.
>
> By 1979, Bell already had very senior engineers like Cutler and Hustveldt working on what became VAXELN and MicroVMS with that bet in mind

Yep. Dave Cutler elaborates on the reasons for 512-byte pages in his oral history for the Computer History Museum. In addition to wanting VAX to work well in low-memory configurations, e.g. for VAXELN, they also had to deal with the complex addressing modes and CISC instructions that could touch up to 6 or 7 different nonconsecutive memory locations (I forget the max number he gave).

The concern the VAX designers had about using a larger page size is it meant having to page more data in/out from disk per page fault, and they were concerned about thrashing on low-RAM systems, especially when a single complex instruction (like POLY) could generate multiple page faults. Yet another argument for RISC's load-store design.

On 2023-10-03 07:33, jimc...@gmail.com wrote:
> On Sunday, September 24, 2023 at 7:10:45 AM UTC-7, John Dallman wrote:
>
>> The idea of running VMS on a terminal with a total of 64KB of RAM and ROM
>> in 1982 seems implausible now, but it seems to have been the reason for
>> 512-byte pages.
>
> By 1979, Bell already had very senior engineers like Cutler and Hustveldt working on what became VAXELN and MicroVMS with that bet in mind

I still have a very hard time believing the 64KB claim.

The MicroVAX II, for which MicroVMS was bascially created, had 1MB on
board memory, and could have up to 16M total.
And as observed, even PDP-11s back when the VAX was created usually ran
with more memory, and any OS with even more than a few features requied
that you had more than 64KB. I can't see any chance that anything would
ever have run on a VAX with 64K.

And the VAX-11/780 hardware guide from 1979 specifies that the minimum
required memory to be 256KB.
(https://bitsavers.org/pdf/dec/vax/780/EK-11780-UG-001_VAX-11_780_Hardware_Users_Guide_197902.pdf
page 1-10)

>> Bell praises the extremely compact VAX instruction set
>> and its elaborate function calls, without appreciating the ways they will
>> come to inhibit pipelining and out-of-order execution, and thus doom the
>> architecture to uncompetitive performance.
>
> At that stage I'm not sure anyone realized just how hard it would be for VAX to be micro-optimised.

Agreed. I would say the design was very reasonable based on what they
know, and what goals they had back then. I find it weird that people
claim now that the design was bad as viewed back then. Yes, it turns out
it was hard to get very high performance with it. Not impossible, but
hard. They certainly did a lot with the NVAX for example. It was for a
while the fastest CISC around.

Johnny

On 10/9/2023 6:08 AM, Johnny Billquist wrote:
> On 2023-10-03 07:33, jimc...@gmail.com wrote:
>> On Sunday, September 24, 2023 at 7:10:45 AM UTC-7, John Dallman wrote:
>>
>>> The idea of running VMS on a terminal with a total of 64KB of RAM and
>>> ROM
>>> in 1982 seems implausible now, but it seems to have been the reason for
>>> 512-byte pages.
>>
>> By 1979, Bell already had very senior engineers like Cutler and
>> Hustveldt working on what became VAXELN and MicroVMS with that bet in
>> mind
>
> I still have a very hard time believing the 64KB claim.
>
> The MicroVAX II, for which MicroVMS was bascially created, had 1MB on
> board memory, and could have up to 16M total.
> And as observed, even PDP-11s back when the VAX was created usually ran
> with more memory, and any OS with even more than a few features requied
> that you had more than 64KB. I can't see any chance that anything would
> ever have run on a VAX with 64K.

CP/M? :-)

bill

On Monday, October 9, 2023 at 1:57:58 AM UTC-7, Jake Hamby (Solid State Jake) wrote:

(snip)

> Yep. Dave Cutler elaborates on the reasons for 512-byte pages in his oral history
> for the Computer History Museum. In addition to wanting VAX to work well in
> low-memory configurations, e.g. for VAXELN, they also had to deal with the complex
> addressing modes and CISC instructions that could touch up to 6 or 7 different
> nonconsecutive memory locations (I forget the max number he gave).
It sets the size of the TLB, which has to be able to translate all the addresses
for one instruction.

There is the instruction and up to (if I remember) six operands.

Each one could cross a page boundary, so 14 pages.

To allow page tables to be paged, they are indirectly addressed
using the different parts of address space. So now 28.

I think that there is one additional complication, but I forget
now what that one is.

Page thrashing just slows things down. If the TLB can't translate
all the addresses for one instruction, you can't execute it.

In article <ug0jeb$70d$4@news.misty.com>, bqt@softjar.se (Johnny
Billquist) wrote:

> I still have a very hard time believing the 64KB claim.
>
> The MicroVAX II, for which MicroVMS was bascially created, had 1MB
> on board memory, and could have up to 16M total.

There may have been a mismatch between plans made in 1975 and the
implementations, of both the OS and the hardware for it, that evolved
over the next few years. I feel confident in the claim that VMS came out
larger than the initial estimates.

In 1975, 16Kbit DRAMs were new; in 1977 the first 64Kbit ones appeared
and in 1979-80 they were becoming routine and 256Kbit ones were starting
to appear. The exponential growth probably took some getting used to.

<https://en.wikipedia.org/wiki/Random-access_memory#DRAM>

John

On Monday, October 9, 2023 at 6:08:14 AM UTC-4, Johnny Billquist wrote:

>
> And the VAX-11/780 hardware guide from 1979 specifies that the minimum
> required memory to be 256KB.
> (https://bitsavers.org/pdf/dec/vax/780/EK-11780-UG-001_VAX-11_780_Hardware_Users_Guide_197902.pdf
> page 1-10)
>
My understanding is that a 128K configuration was tested in field test but VMS engineering decided against it for some reason (before my time but told to me by Andy G - I'll ask him the next time I see him - I had lunch with him last week)

On 10/9/2023 8:38 PM, John Reagan wrote:
> On Monday, October 9, 2023 at 6:08:14 AM UTC-4, Johnny Billquist
> wrote:
>> And the VAX-11/780 hardware guide from 1979 specifies that the
>> minimum required memory to be 256KB.
>> (https://bitsavers.org/pdf/dec/vax/780/EK-11780-UG-001_VAX-11_780_Hardware_Users_Guide_197902.pdf page 1-10) >>
> My understanding is that a 128K configuration was tested in field
> test but VMS engineering decided against it for some reason (before
> my time but told to me by Andy G - I'll ask him the next time I see
> him - I had lunch with him last week)

So let us say that VMS 1.0 runs somewhat OK on 256 KB, runs crappy
at 128 KB and don't run at all on 64 KB.

What would VAXELN run on?

I know that VAXELN came 6 years later, but if it hypothetical had
arrived in 1978 based on 1978 way of doing things not 1984 way of
doing things.

Arne

(snip, I wrote)

> It sets the size of the TLB, which has to be able to translate all the addresses
> for one instruction.
>
> There is the instruction and up to (if I remember) six operands.

OK, I think I have it right now:

In autoincrement deferred mode, the register contains the address
of the address of the operand. Both the address in memory and
operand can cross a page boundary. The instruction itself can also
cross a page boundary. One instruction can use 26 pages.

Those pages are indirectly addressed through pageable page tables.
So, if one is very unlucky, all the page tables are in different pages,
and a total of 52 pages are referenced.

Those translations must be in the TLB, so the TLB must be
able to translate 52 different addresses.

Note also, that no memory locations can be changed until it
is known that all pages are in memory. The autoincrement
modes have to update addresses in memory.

gah4 wrote:
> (snip, I wrote)
>
>> It sets the size of the TLB, which has to be able to translate all the addresses
>> for one instruction.
>>
>> There is the instruction and up to (if I remember) six operands.
>
> OK, I think I have it right now:
>
> In autoincrement deferred mode, the register contains the address
> of the address of the operand. Both the address in memory and
> operand can cross a page boundary. The instruction itself can also
> cross a page boundary. One instruction can use 26 pages.
>
> Those pages are indirectly addressed through pageable page tables.
> So, if one is very unlucky, all the page tables are in different pages,
> and a total of 52 pages are referenced.
>
> Those translations must be in the TLB, so the TLB must be
> able to translate 52 different addresses.
>
> Note also, that no memory locations can be changed until it
> is known that all pages are in memory. The autoincrement
> modes have to update addresses in memory.

Needing to have all the pages for the instruction available at once is
only an issue if your only option on a fault is to restart the instruction.

On a microcoded machine, it is possible to have a mid-instruction fault.
After page fault resolution, the instruction can resume at the
micro-step where it previously failed.

It is ugly (or elegant depending on your point of view), but it does
allow an instruction to progress when the working set is very small.

I do not whether or not 11/780 microcode was written this way.

I do know that the DG MV/8000 microcode does work this way and programs
can execute (although very slowly) in a working set of only a few pages.

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

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

On Monday, October 9, 2023 at 7:36:33 PM UTC-7, Chris Scheers wrote:

(snip, I wrote)

> > Note also, that no memory locations can be changed until it
> > is known that all pages are in memory. The autoincrement
> > modes have to update addresses in memory.

> Needing to have all the pages for the instruction available at once is
> only an issue if your only option on a fault is to restart the instruction.

> On a microcoded machine, it is possible to have a mid-instruction fault.
> After page fault resolution, the instruction can resume at the
> micro-step where it previously failed.
For VAX, string instructions have a length of up to 65535, and yes
those are interruptible. Those instructions save state in
registers, with the addresses and lengths to continue after
an interrupt.

Some instructions are emulated in software on subset processors.
The emulation can then be interrupted.

As far as I can tell, the packed decimal instructions like
ADDP, SUBP, MULP, DIVP, allow for lengths up to 31,
and are not interruptible. These have six operands,
three lengths and three addresses. Each operand can
only be one or two pages. I believe those can use the
autoincrement deferred addressing mode as I note
above.

> It is ugly (or elegant depending on your point of view), but it does
> allow an instruction to progress when the working set is very small.

> I do not whether or not 11/780 microcode was written this way.

Only for some instructions.
> I do know that the DG MV/8000 microcode does work this way and programs
> can execute (although very slowly) in a working set of only a few pages.

On 2023-10-10 02:44, Arne Vajhøj wrote:
> On 10/9/2023 8:38 PM, John Reagan wrote:
>> On Monday, October 9, 2023 at 6:08:14 AM UTC-4, Johnny Billquist
>> wrote:
>>> And the VAX-11/780 hardware guide from 1979 specifies that the
>>> minimum required memory to be 256KB.
>>> (https://bitsavers.org/pdf/dec/vax/780/EK-11780-UG-001_VAX-11_780_Hardware_Users_Guide_197902.pdf page 1-10) >>
>> My understanding is that a 128K configuration was tested in field
>> test but VMS engineering decided against it for some reason (before
>> my time but told to me by Andy G - I'll ask him the next time I see
>> him - I had lunch with him last week)
>
> So let us say that VMS 1.0 runs somewhat OK on 256 KB, runs crappy
> at 128 KB and don't run at all on 64 KB.
>
> What would VAXELN run on?
>
> I know that VAXELN came 6 years later, but if it hypothetical had
> arrived in 1978 based on 1978 way of doing things not 1984 way of
> doing things.

Never used, or even touched VAXELN myself, but my understanding is that
it wasn't that small. Even RSX is rather ugly with just 64K, and gives
your lots of heacaches. Wouldn't expect anything on the VAX being able
to get by with even less. VAXELN, to my understanding, would deliver
somewhat similar functionality to RSX, but is more fancy.

Johnny

On Sunday, September 24, 2023 at 3:48:56 PM UTC-7, Arne Vajhøj wrote:
> On 9/24/2023 10:29 AM, Johnny Billquist wrote:
> > On 2023-09-24 16:10, John Dallman wrote:
> >> The idea of running VMS on a terminal with a total of 64KB of RAM and ROM
> >> in 1982 seems implausible now, but it seems to have been the reason for
> >> 512-byte pages.
> > VMS was never expected to run on something with 64K. You couldn't even
> > run a reasonable PDP-11 on that little memory at that point. (I said
> > responable, for anyone dragging out a minimal RT-11 system.)
> What was the smallest VAX memory wise?
>
> I think I have heard about 256 KB VAX 780's. Can anyone confirm?
>
> Arne

The initial design target for VAX/VMS V1.0 was 128K, but was raised to 256K before FCS.

Derrell (piper@star.enet.dec.com)

In article <memo.20230925192935.16292W@jgd.cix.co.uk>, jgd@cix.co.uk
(John Dallman) wrote:
> In article <cb83004a-46f6-424f-8b3d-6879af803e86n@googlegroups.com>,
> gah4@u.washington.edu (gah4) wrote:
> > The book by Blaauw and Brooks, "Computer Architecture" describes
> > many architectures, but includes some details that actually went
> > into S/360, because they designed it.
>
> Ordered a used volume 1.

That is a remarkably good book. Recommended to anyone interested in the
history of computer architecture.

John

On 10/10/2023 3:23 AM, gah4 wrote:
> On Monday, October 9, 2023 at 7:36:33 PM UTC-7, Chris Scheers wrote:
>> On a microcoded machine, it is possible to have a mid-instruction fault.
>> After page fault resolution, the instruction can resume at the
>> micro-step where it previously failed.
>
> For VAX, string instructions have a length of up to 65535, and yes
> those are interruptible. Those instructions save state in
> registers, with the addresses and lengths to continue after
> an interrupt.

Just to be clear - the 65535 is the max length of the string
processed by the instruction not the max length of the instruction
itself.

And some of the instructions like MOVC3 and MOVC5 has two
such operands.

Arne

On Tuesday, October 10, 2023 at 4:01:17 PM UTC-7, Arne Vajhøj wrote:
> On 10/10/2023 3:23 AM, gah4 wrote:
> > On Monday, October 9, 2023 at 7:36:33 PM UTC-7, Chris Scheers wrote:
> >> On a microcoded machine, it is possible to have a mid-instruction fault.
> >> After page fault resolution, the instruction can resume at the
> >> micro-step where it previously failed.
> >
> > For VAX, string instructions have a length of up to 65535, and yes
> > those are interruptible. Those instructions save state in
> > registers, with the addresses and lengths to continue after
> > an interrupt.
> Just to be clear - the 65535 is the max length of the string
> processed by the instruction not the max length of the instruction
> itself.
>
> And some of the instructions like MOVC3 and MOVC5 has two
> such operands.

Those VAX instructions remind me of some of the newer IBM Z opcodes. IBM added a zip/gzip accelerator (originally an extra-cost PCIe card, moved to the CPU die for z15), and an in-memory sort for z15.

https://www.ibm.com/support/z-content-solutions/compression/

https://blog.share.org/Article/peeking-under-the-hood-of-sort-acceleration-on-z15

IBM's POWER9 RISC CPU also includes a zip/gzip accelerator:

https://community.ibm.com/community/user/power/blogs/brian-veale1/2020/11/09/power9-gzip-data-acceleration-with-ibm-aix

All interruptible IBM Z instructions return completion status in a flag, so they're always called in a two-instruction sequence, with the second a conditional loop back to the first if it was interrupted. One feature of IBM mainframes ever since they moved to CMOS in the 1990s was that IBM realized they couldn't implement all of the many CISC instructions in microcode efficiently, so they implement the more complex ones with what they call "millicode", which is Z assembly code with a few extra capabilities. So they don't use an implemented opcode exception, like, say, MicroVAX, or the removed FPU instructions on the 68040 FPU, but it's all handled transparently to the user.

Unlike, say, Alpha PALcode, because IBM controls the entire stack, they can decide for each new CPU design which instructions to implement in hardware vs. millicode (those details are invisible and not a part of the architected system). The hardware-accelerated zip/gzip and in-memory sort accelerators are implemented as a combination of millicode and dedicated hardware. Today's IBM Z CPUs, like modern x86 CPUs, break the CISC instruction stream into micro-ops which can then be executed in parallel and out-of-order, with millicode sequences executed the same as other code.

One similarity between VAX and IBM Z is they both have packed decimal instructions to accelerate COBOL code, as well as string manipulation. Because COBOL is so crucial to IBM's customers, they've extended the architecture to include decimal SIMD instructions, and they sell an object code translator to modify existing COBOL binaries that customers can't, or don't want to, recompile with a newer version of the compiler, called the Automatic Binary Optimizer (ABO).

https://www.ibm.com/docs/en/cobol-zos/6.4?topic=appendixes-using-automatic-binary-optimizer-zos-abo-improve-cobol-application-performance

As a side note, the reason ARM has an instruction to save/restore a set of registers, which wasn't considered a RISC feature, is the designers wanted to take maximum advantage of page mode DRAM and a multiple load or store might cause a page fault, but it didn't require alternating between reading an individual load/store instruction and then executing it, which would otherwise have been the case for the ARM2, which didn't have any on-board cache.. The ARM3 rectified the lack of cache, but it came later.

Much of the performance benefit of the Acorn Archimedes (which I never saw in the USA, but I came to appreciate via the Raspberry Pi port of RISC OS) compared to 68000-based or x86 systems circa 1990 came down to being able to execute ~1 instruction per clock cycle (RISC vs. microcoded CISC), with a fast 32-bit page mode RAM subsystem (68000/010 have a 16-bit data bus) to avoid stalling. That's why they felt confident enough to design ARM2 with no on-die cache, since performance didn't suffer much.

Regards,
Jake Hamby

On Tuesday, October 10, 2023 at 4:01:17 PM UTC-7, Arne Vajhøj wrote:

(snip, I wrote)

> > For VAX, string instructions have a length of up to 65535, and yes
> > those are interruptible. Those instructions save state in
> > registers, with the addresses and lengths to continue after
> > an interrupt.

> Just to be clear - the 65535 is the max length of the string
> processed by the instruction not the max length of the instruction
> itself.

Yes, that is what it was supposed to mean.

Reminds me of an interesting case for IBM S/370.

There is a translate (TR) instruction, similar to the VAX MOVTC instruction,
except that the length can only be up to 256. (And is not interruptible.)

For S/360, it was defined such that bytes in the translation table that
are not used for translation don't have to exist in memory. That is, they
can be past the end of allocated storage, possibly in someone else's program.

For that reason, the S/370 version isn't allowed to request pages that are
not needed for the translation being done. The processor, then, does a
"trial execution" where it verifies that the needed pages are in memory
before storing any translated characters.

Looking at the description for MOVTC, it doesn't seem to indicate this
either way. It might be noted somewhere else, that programs can't
depend on such access not occurring.

On Tuesday, October 10, 2023 at 5:02:44 PM UTC-7, Jake Hamby (Solid State Jake) wrote:

(snip)

> Those VAX instructions remind me of some of the newer IBM Z opcodes.
> IBM added a zip/gzip accelerator (originally an extra-cost PCIe card, moved to the CPU die for z15), and an in-memory sort for z15.

I have one of the earlier paper versions of the z/ Principles of Operations..
Also, the PDF version. But not this recent.

> https://www.ibm.com/support/z-content-solutions/compression/

Pretty neat. Reminds me of the story about some instructions from maybe
back to S/370 days, to make sorting faster. They were competing with other
companies for fast sort programs.

> https://blog.share.org/Article/peeking-under-the-hood-of-sort-acceleration-on-z15
>
> IBM's POWER9 RISC CPU also includes a zip/gzip accelerator:
>
> https://community.ibm.com/community/user/power/blogs/brian-veale1/2020/11/09/power9-gzip-data-acceleration-with-ibm-aix

> All interruptible IBM Z instructions return completion status in a flag,
> so they're always called in a two-instruction sequence, with the second
> a conditional loop back to the first if it was interrupted.

MVCL and CLCL, from the S/370 days. (I believe from before virtual storage
was announced) automatically loop. That is, the stored address for an
interrupt is the instruction itself.

But yes, the newer MVCLE and CLCLE, and probably more that I don't know
about, return condition code 3, and normally a branch immediately follows.
Interrupt address is the following instruction.

But you can also go do other things before branching back.

I believe MVCLE and CLCLE came along with 31 bit addressing, and
so allow for 31 bit lengths. MVCL and CLCL only allow 24 bit lengths.

In any case MVCL, MVCLE, CLCL, and CLCLE, continue on when executed
again. The starting addresses and lengths are specified in registers.
There is no FPD (first part done) like on VAX.

(It looks like VAX loads the operands into registers, and then uses them
to save the current state.)

gah4 wrote:
> On Monday, October 9, 2023 at 7:36:33 PM UTC-7, Chris Scheers wrote:
>
>
> (snip, I wrote)
>
>>> Note also, that no memory locations can be changed until it
>>> is known that all pages are in memory. The autoincrement
>>> modes have to update addresses in memory.
>
>> Needing to have all the pages for the instruction available at once is
>> only an issue if your only option on a fault is to restart the instruction.
>
>> On a microcoded machine, it is possible to have a mid-instruction fault.
>> After page fault resolution, the instruction can resume at the
>> micro-step where it previously failed.
>
> For VAX, string instructions have a length of up to 65535, and yes
> those are interruptible. Those instructions save state in
> registers, with the addresses and lengths to continue after
> an interrupt.
>
> Some instructions are emulated in software on subset processors.
> The emulation can then be interrupted.
>
> As far as I can tell, the packed decimal instructions like
> ADDP, SUBP, MULP, DIVP, allow for lengths up to 31,
> and are not interruptible. These have six operands,
> three lengths and three addresses. Each operand can
> only be one or two pages. I believe those can use the
> autoincrement deferred addressing mode as I note
> above.

It can be tricky, but it is important to keep in mind that even if an
instruction is not interruptable, it may be susceptible to a page fault.

There are four (that I know of) responses to page faults (after
correcting the cause of the fault condition):

Reexecutable: Either no machine state has been changed by the
instruction yet or the fault mechanism restored any changed state. These
faults can be retried by reexecuting the instruction from the beginning.
Non-interruptable instructions generally fall into this class. If
necessary, the execution mechanism may need to probe all instruction
arguments before beginning execution to ensure that no page faults will
occur during execution of the instruction.

Restartable: Any changed state can be saved (generally in registers)
such that reexecuting the instruction results in the instruction
continuing execution from where the page fault occurred as if it had not
faulted.

Resumable: Any changed state is saved (either visibly, such as in
registers or the stack, or in hidden structures that may be internal to
the CPU). Part of the saved status is a flag that marks "instruction
partially done" so that when the instruction is reexecuted, the
"instruction partially done" flag is detected and the saved state is
restored. The instruction then resumes execution "in the middle" where
it was when the fault occurred. A microcoded processor generally saves
the microstep as part of the saved state.

Fatal: There is no recovery from the fault.

Not all processors support all of these options, but I have seen
different models within the same processor family handle faults for the
same conditions differently.

>> It is ugly (or elegant depending on your point of view), but it does
>> allow an instruction to progress when the working set is very small.
>
>> I do not whether or not 11/780 microcode was written this way.
>
> Only for some instructions.
>
>> I do know that the DG MV/8000 microcode does work this way and programs
>> can execute (although very slowly) in a working set of only a few pages.

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

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