On Sun, 31 Dec 2023 17:54:44 -0000 (UTC), Thomas Koenig wrote:

> ... but I've never even come close to one of these
> machines).

You could have one, or a software emulation of one, right in front of you,
just a SIMH install away.

Lawrence D'Oliveiro wrote:
> On Thu, 4 Jan 2024 01:36:35 +0000, MitchAlsup wrote:
>
>> Mark Horowitz stated (~1983) MIPS executes 1.5× as many instructions as
>> VAX and at 6× the frequency for a 4× improvement in performance.
>
> Mmm, maybe you got the last two multipliers the wrong way round?
>
No, that seems correct: It needed 1.5 times as many instructions, so the
6X frequency must be divided by 1.5 for a final speedup of 4X?

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Fri, 29 Dec 2023 19:04:56 GMT, Scott Lurndal wrote:
>
[no assembler shipped to customers]

>> The [Burroughs] system ran mostly COBOL code (with some BPL;
>> assemblers weren't generally provided to customers).
>
>For an interesting reason: privilege protection was enforced in software,
>not hardware.

Actually, that is not the case.

Burroughs had multiple lines of mainframes: small, medium and large.

Small systems (b1700/b1800/b1900) had a writeable control store and the instruction set
would be dynamically loaded when the application was scheduled.

Medium systems were BCD systems (B[234][5789]xx) (descended from the orignal line
of Electrodata Datatron systems when Burroughs bought electrodata
in the mid 1950s). Designed to efficiently run COBOL code. These
are the systems I was referring to above. They had hardware
enforced privilege protection.

Large systems (starting with the B5000/B5500) were stack systems
running ALGOL and algol deriviative (DCALGOL, NEWP, etc)
(they also supported COBOL, Fortran, Basic, etc).

The systems you are thinking about were the Large systems. And
there were issues with that (a famous paper in the mid 1970s
showed how to set the 'compiler' flag on any application allowing
it to bypass security protections - put the application on a
tape, load it on an IBM system, patch the executable header,
and restore it on the Burroughs system).

Lawrence D'Oliveiro wrote:

> On Thu, 4 Jan 2024 01:36:35 +0000, MitchAlsup wrote:

>> Mark Horowitz stated (~1983) MIPS executes 1.5× as many instructions as
>> VAX and at 6× the frequency for a 4× improvement in performance.

> Mmm, maybe you got the last two multipliers the wrong way round?

Performance is in millions of instructions per second.

If the instruction count was 1.0× a 6× frequency would yield 6× gain.

So, since there were 1.5× as many instructions and 6× as many instructions per
second, 6 / 1.5 = 4×

Lawrence D'Oliveiro wrote:
> On Thu, 4 Jan 2024 01:36:35 +0000, MitchAlsup wrote:
>
>> Mark Horowitz stated (~1983) MIPS executes 1.5× as many instructions as
>> VAX and at 6× the frequency for a 4× improvement in performance.
>
> Mmm, maybe you got the last two multipliers the wrong way round?

VAX-780 was 5 MHz, 200 ns clock and averaged 10 clocks per instruction
giving 0.5 MIPS. When it first came out they thought it was a 1 MIPS
machine and advertised it as such. But no one had actually measured it.
When they finally did and found it was 0.5 MIPS they just changed to
calling that "1 VUP" or "VAX-780 Units of Processing".

This also showed up in the Dhrystone benchmarks:

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

"Another common representation of the Dhrystone benchmark is the
DMIPS (Dhrystone MIPS) obtained when the Dhrystone score is divided
by 1757 (the number of Dhrystones per second obtained on the VAX 11/780,
nominally a 1 MIPS machine)."

I suppose they should have changed that to DVUPS.

Stanford MIPS (16 registers) in 1984 ran at 4 MHz with a 5 stage pipeline.
The paper I'm looking at compares it to a 8 MHz 68000 and has
Stanford MIPS averaging 5 times faster on their Pascal benchmark.

The MIPS R2000 with 32 registers launched in 1986 at 8.3, 12.5 and 15 MHz.
It supposedly could sustain 1 reg-reg ALU operation per clock.

It appears that EricP <ThatWouldBeTelling@thevillage.com> said:
>VAX-780 was 5 MHz, 200 ns clock and averaged 10 clocks per instruction
>giving 0.5 MIPS. When it first came out they thought it was a 1 MIPS
>machine and advertised it as such.

No, they knew how fast it was. It was about as fast as an IBM 370/158
which IBM rated at 1 MIPS. A Vax instruction could do a lot more than
a 370 instruction so it wasn't implausible that the performance was
similar even though the instruction rate was about half.

>When they finally did and found it was 0.5 MIPS they just changed to
>calling that "1 VUP" or "VAX-780 Units of Processing".

Yeah, they got grief for the MIPS stuff.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine wrote:
> It appears that EricP <ThatWouldBeTelling@thevillage.com> said:
>> VAX-780 was 5 MHz, 200 ns clock and averaged 10 clocks per instruction
>> giving 0.5 MIPS. When it first came out they thought it was a 1 MIPS
>> machine and advertised it as such.
>
> No, they knew how fast it was. It was about as fast as an IBM 370/158
> which IBM rated at 1 MIPS.

So those were TOUPS or Three-seventy One-fifty-eight Units of Performance.

> A Vax instruction could do a lot more than
> a 370 instruction so it wasn't implausible that the performance was
> similar even though the instruction rate was about half.

And they define 1 VUP = 1 TOUP

>> When they finally did and found it was 0.5 MIPS they just changed to
>> calling that "1 VUP" or "VAX-780 Units of Processing".
>
> Yeah, they got grief for the MIPS stuff.

One just has to be careful comparing clock MIPS and VUPS.

According to EricP <ThatWouldBeTelling@thevillage.com>:
>John Levine wrote:
>> It appears that EricP <ThatWouldBeTelling@thevillage.com> said:
>>> VAX-780 was 5 MHz, 200 ns clock and averaged 10 clocks per instruction
>>> giving 0.5 MIPS. When it first came out they thought it was a 1 MIPS
>>> machine and advertised it as such.
>>
>> No, they knew how fast it was. It was about as fast as an IBM 370/158
>> which IBM rated at 1 MIPS.
>
>So those were TOUPS or Three-seventy One-fifty-eight Units of Performance.

If you want. IBM mainframe MIPS was a well understood performance
measure at the time. In the mid 1970s, there were a few IBM clones
like Amdahl, but the other mainframe makers were already sinking into
obscurity. I can't think of anyone else making a 32 bit byte
addressable mainframe at the time that wasn't an IBM clone. I suppose
there were the Interdata machines but they were minis and sold mostly
for embedded realtime.

>> A Vax instruction could do a lot more than
>> a 370 instruction so it wasn't implausible that the performance was
>> similar even though the instruction rate was about half.
>
>And they define 1 VUP = 1 TOUP

Yes, but a TOUP really was an IBM MIPS.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine wrote:
> According to EricP <ThatWouldBeTelling@thevillage.com>:
>> John Levine wrote:
>>> It appears that EricP <ThatWouldBeTelling@thevillage.com> said:
>>>> VAX-780 was 5 MHz, 200 ns clock and averaged 10 clocks per instruction
>>>> giving 0.5 MIPS. When it first came out they thought it was a 1 MIPS
>>>> machine and advertised it as such.
>>> No, they knew how fast it was. It was about as fast as an IBM 370/158
>>> which IBM rated at 1 MIPS.
>> So those were TOUPS or Three-seventy One-fifty-eight Units of Performance.
>
> If you want. IBM mainframe MIPS was a well understood performance
> measure at the time. In the mid 1970s, there were a few IBM clones
> like Amdahl, but the other mainframe makers were already sinking into
> obscurity. I can't think of anyone else making a 32 bit byte
> addressable mainframe at the time that wasn't an IBM clone. I suppose
> there were the Interdata machines but they were minis and sold mostly
> for embedded realtime.
>
>>> A Vax instruction could do a lot more than
>>> a 370 instruction so it wasn't implausible that the performance was
>>> similar even though the instruction rate was about half.
>> And they define 1 VUP = 1 TOUP
>
> Yes, but a TOUP really was an IBM MIPS.

Ok, but VAX-780 really was measured by DEC at 0.5 MIPS.
So either the assumption that a VUP = TOUP was wrong
or the assumption that a TOUP = MIPS was.

See section 5 and table 8.

Characterization of Processor Performance in the VAX-11/780, 1984
http://www.eecg.utoronto.ca/~moshovos/ACA06/readings/emer-clark-VAX.pdf

According to EricP <ThatWouldBeTelling@thevillage.com>:
>>>> No, they knew how fast it was. It was about as fast as an IBM 370/158
>>>> which IBM rated at 1 MIPS.
>>> So those were TOUPS or Three-seventy One-fifty-eight Units of Performance.
>>
>> If you want. IBM mainframe MIPS was a well understood performance
>> measure at the time. In the mid 1970s, there were a few IBM clones
>> like Amdahl, but the other mainframe makers were already sinking into
>> obscurity. I can't think of anyone else making a 32 bit byte
>> addressable mainframe at the time that wasn't an IBM clone. I suppose
>> there were the Interdata machines but they were minis and sold mostly
>> for embedded realtime.
>>
>>>> A Vax instruction could do a lot more than
>>>> a 370 instruction so it wasn't implausible that the performance was
>>>> similar even though the instruction rate was about half.
>>> And they define 1 VUP = 1 TOUP
>>
>> Yes, but a TOUP really was an IBM MIPS.
>
>Ok, but VAX-780 really was measured by DEC at 0.5 MIPS.
>So either the assumption that a VUP = TOUP was wrong
>or the assumption that a TOUP = MIPS was.

As I think I said above. a million IBM instructions did about as much
work as half a million VAX instructions. In that era, MIPS meant
either a million IBM instructions, or as some wag put it, Meaningless
Indication of Processor Speed.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine <johnl@taugh.com> schrieb:

> As I think I said above. a million IBM instructions did about as much
> work as half a million VAX instructions.

Why the big difference? Were fancy addressing modes really used so
much? Or did the code for the VAX mostly run POLY instructions? :-)

Thomas Koenig wrote:
> John Levine <johnl@taugh.com> schrieb:
>
>> As I think I said above. a million IBM instructions did about as much
>> work as half a million VAX instructions.
>
> Why the big difference? Were fancy addressing modes really used so
> much? Or did the code for the VAX mostly run POLY instructions? :-)

I was thinking the same thing. VAX address modes like auto-increment
would be equivalent to 2 instructions for each operand and likely used
in benchmarks.

VAX having 32-bit immediates and offsets and and 64-bit float immediates
per operand vs 370 having to build constants or load them.

And POLY for transcendentals is one instruction.

All of those would add clocks to the VAX instruction execute time
but not its instruction count and MIPS.

EricP <ThatWouldBeTelling@thevillage.com> writes:
>Thomas Koenig wrote:
>> John Levine <johnl@taugh.com> schrieb:
>>
>>> As I think I said above. a million IBM instructions did about as much
>>> work as half a million VAX instructions.
>>
>> Why the big difference? Were fancy addressing modes really used so
>> much? Or did the code for the VAX mostly run POLY instructions? :-)
>
>I was thinking the same thing. VAX address modes like auto-increment
>would be equivalent to 2 instructions for each operand and likely used
>in benchmarks.

MOVC3 and MOVC5, perhaps?

Thomas Koenig wrote:

> John Levine <johnl@taugh.com> schrieb:

>> As I think I said above. a million IBM instructions did about as much
>> work as half a million VAX instructions.

> Why the big difference? Were fancy addressing modes really used so
> much? Or did the code for the VAX mostly run POLY instructions? :-)

Fancy addressing modes {indirection, pre decrement, post increment,
Constants, Displacements, index, ADD-CMP-
Branch, CRC, Bit manipulation, ...)
You could say these contribute to most of the gain

On Wed, 17 Jan 2024 23:56:24 GMT, Scott Lurndal wrote:

> MOVC3 and MOVC5, perhaps?

Interruptible instructions ... wot fun ...

It appears that Thomas Koenig <tkoenig@netcologne.de> said:
>John Levine <johnl@taugh.com> schrieb:
>
>> As I think I said above. a million IBM instructions did about as much
>> work as half a million VAX instructions.
>
>Why the big difference? Were fancy addressing modes really used so
>much? Or did the code for the VAX mostly run POLY instructions? :-)

I don't think anyone used the fancy addressing modes or complex
instructions much. But here's an example. Let's say A, B, and C are
floats in addressable memory and you want to do A = B + C

370 code

LE R0,B
AE R0,C
STE R0,A

VAX code

ADDF3 B,C,A

The VAX may not be faster, but that's one instruction rather than 3.

Or that old Fortran favorite I = I + 1

370 code

L R1,I
LA R2,1
AR R1,R2
ST R1,I

VAX code

INCL I

or if you have a lousy optimizer

ADDL2 #1,I

or if you have a really lousy optimizer

ADDL3 #1,I,I

It's still one instruction rather than four.

In 370 code you often also needed extra instructions to make data
addressable since it had no direct addressing and address offsets in
instructions were only 12 bits.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Thu, 18 Jan 2024 02:05:30 -0000 (UTC), John Levine wrote:

> ADDF3 B,C,A
>
> The VAX may not be faster, but that's one instruction rather than 3.

If those were register operands, that instruction would be 4 bytes.

I think worst case, each operand could have an index register and a 4-byte
offset (in addition to the operand specifier byte), for a maximum
instruction length of 19 bytes.

So, saying “just one instruction” may not sound as good as you think.

Here’s an old example, from the VMS kernel itself. This instruction

PUSHR #^M<R0,R1,R2,R3,R4,R5>

pushes the first 6 registers onto the stack, and occupies just 2 bytes.
Whereas this sequence

PUSHL R5
PUSHL R4
PUSHL R3
PUSHL R2
PUSHL R1
PUSHL R0

does the equivalent thing, but takes up 2 × 6 = 12 bytes.

Guess which is faster?

Lawrence D'Oliveiro wrote:
> On Wed, 17 Jan 2024 23:56:24 GMT, Scott Lurndal wrote:
>
>> MOVC3 and MOVC5, perhaps?
>
> Interruptible instructions ... wot fun ...
>
REP MOVS is the classic x86 example: Since all register usage is fixed
(r)si,(r)di,(r)cx the cpu can always accept an interrupt at any point,
it just needs to update those three registers and take the interrupt.

When the instruction resumes, any remaining moves are performed.

This was actually an early 8086/8088 bug: If you had multiple prefix
bytes, like you would need if you were moving data to the Stack segment
instead of the Extra, and the encoding was REP SEGSS MOVS, then only hte
last prefix byte was remembered in the saved IP/PC value.

I used to check for this bug by moving a block which was large enough
that it took over 55ms, so that a timer interrupt was guaranteed:

If the CX value wasn't zero after the instruction, then the bug had
happened.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

John Levine wrote:
> It appears that Thomas Koenig <tkoenig@netcologne.de> said:
>> John Levine <johnl@taugh.com> schrieb:
>>
>>> As I think I said above. a million IBM instructions did about as much
>>> work as half a million VAX instructions.
>> Why the big difference? Were fancy addressing modes really used so
>> much? Or did the code for the VAX mostly run POLY instructions? :-)
>
> I don't think anyone used the fancy addressing modes or complex
> instructions much. But here's an example. Let's say A, B, and C are
> floats in addressable memory and you want to do A = B + C
>
> 370 code
>
> LE R0,B
> AE R0,C
> STE R0,A
>
> VAX code
>
> ADDF3 B,C,A
>
> The VAX may not be faster, but that's one instruction rather than 3.
>
> Or that old Fortran favorite I = I + 1
>
> 370 code
>
> L R1,I
> LA R2,1
> AR R1,R2
> ST R1,I
>
> VAX code
>
> INCL I
>
> or if you have a lousy optimizer
>
> ADDL2 #1,I
>
> or if you have a really lousy optimizer
>
> ADDL3 #1,I,I
>
> It's still one instruction rather than four.
>
> In 370 code you often also needed extra instructions to make data
> addressable since it had no direct addressing and address offsets in
> instructions were only 12 bits.

VAX Fortran77 could optimize a DO loop array index to an autoincrement,
I think they called it strength reduction of loop induction variables.

do i = 1, N
A(i) = A(i) + B(i)
end do

ADDD (rB)+, (rA)+

VAX usage stats for compilers Basic, Bliss, Cobol, Fortran, Pascal, PL1,
show usage frequency per operand specifier of autoincrement ~4%, index ~7%
except Basic has 17% for autoincrement.
There is almost no usage of deferred addressing (address of address of data).

Lawrence D'Oliveiro wrote:
> On Thu, 18 Jan 2024 02:05:30 -0000 (UTC), John Levine wrote:
>
>> ADDF3 B,C,A
>>
>> The VAX may not be faster, but that's one instruction rather than 3.
>
> If those were register operands, that instruction would be 4 bytes.
>
> I think worst case, each operand could have an index register and a 4-byte
> offset (in addition to the operand specifier byte), for a maximum
> instruction length of 19 bytes.

The longest instruction I think might be an ADD3H with two H format
16-byte float immediates with an indexed destination with 4 byte offset.

That should be something like 2 opcode, 1 opspec, 16 imm,
1 opspec, 16 imm, 1 opspec, 4 imm, 1 index = 42 bytes.

(Yes its a silly instruction but legal.)

>
> So, saying “just one instruction” may not sound as good as you think.
>
> Here’s an old example, from the VMS kernel itself. This instruction
>
> PUSHR #^M<R0,R1,R2,R3,R4,R5>
>
> pushes the first 6 registers onto the stack, and occupies just 2 bytes.
> Whereas this sequence
>
> PUSHL R5
> PUSHL R4
> PUSHL R3
> PUSHL R2
> PUSHL R1
> PUSHL R0
>
> does the equivalent thing, but takes up 2 × 6 = 12 bytes.
>
> Guess which is faster?

EricP <ThatWouldBeTelling@thevillage.com> writes:
>The MIPS R2000 with 32 registers launched in 1986 at 8.3, 12.5 and 15 MHz.
>It supposedly could sustain 1 reg-reg ALU operation per clock.

It could do at most one instruction per clock, and it certainly needed
to branch at some point, so no sustained 1/clock ALU instructions.
Also, a useful program would want to load or store at some point, so
even less ALU instructions. And with cache misses, also fewer than 1
IPC.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

According to Lawrence D'Oliveiro <ldo@nz.invalid>:
>On Thu, 18 Jan 2024 02:05:30 -0000 (UTC), John Levine wrote:
>
>> ADDF3 B,C,A
>>
>> The VAX may not be faster, but that's one instruction rather than 3.
>
>If those were register operands, that instruction would be 4 bytes.
>
>I think worst case, each operand could have an index register and a 4-byte
>offset (in addition to the operand specifier byte), for a maximum
>instruction length of 19 bytes.
>
>So, saying “just one instruction” may not sound as good as you think.

I wasn't saying they were always better, just pointing out that there
were straightforward reasons that 500K VAX instructions could do the
same work as 1M 370 instructions.

Considering that the 370 is still alive and the VAX died decades ago,
it should be evident that instruction count isn't a very useful
metric across architectures.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Thomas Koenig <tkoenig@netcologne.de> writes:
>John Levine <johnl@taugh.com> schrieb:
>
>> As I think I said above. a million IBM instructions did about as much
>> work as half a million VAX instructions.
>
>Why the big difference? Were fancy addressing modes really used so
>much? Or did the code for the VAX mostly run POLY instructions? :-)

It's interesting that these are the features you are thinking of,
especially because the IBM 801 research and the RISC research showed
that fancy addressing modes are rarely used. Table 4 of
<https://www.eecg.utoronto.ca/~moshovos/ACA06/readings/emer-clark-VAX.pdf>
shows that addressing modes that the S/360 or even MIPS does not
support are quite rare:

%
Auto-inc. (R)+ 2.1
Disp. Deferred @D(R) 2.7
Absolute @(PC) 0.6
Auto-inc.def. @(R)+ 0.3
Auto-dec. -(R) 0.9

for a total of 6.6% of the operand specifiers; there are about 1.5
operand specifiers per instruction (Table 3), so that's ~0.1 operand
specifier with a fancy addressing mode per instruction.

Back to why S/360 has more instructions than VAX, John Levine gave a
good answer.

One aspect (partially addressed by John Levine, but not discussed
explicitly) is that the VAX is a three-address machine, while S/360 is
a two-address machine, so the S/360 occasionally needs reg-reg moves
where VAX does not. Plus, S/360 usually requires one of its two
operands to be a register, so in some cases an additional load is
necessary on the S/360 that is not needed on the VAX.

Among the complex VAX instructions CALL/RET and multi-register push
and pop constiture 3.22% of the instructions according to Table 1 of
<https://www.eecg.utoronto.ca/~moshovos/ACA06/readings/emer-clark-VAX.pdf>
I expect that these correspond to multiple instructions on the S/360.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Anton Ertl wrote:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>> John Levine <johnl@taugh.com> schrieb:
>>
>>> As I think I said above. a million IBM instructions did about as much
>>> work as half a million VAX instructions.
>> Why the big difference? Were fancy addressing modes really used so
>> much? Or did the code for the VAX mostly run POLY instructions? :-)
>
> It's interesting that these are the features you are thinking of,
> especially because the IBM 801 research and the RISC research showed
> that fancy addressing modes are rarely used. Table 4 of
> <https://www.eecg.utoronto.ca/~moshovos/ACA06/readings/emer-clark-VAX.pdf>
> shows that addressing modes that the S/360 or even MIPS does not
> support are quite rare:
>
> %
> Auto-inc. (R)+ 2.1
> Disp. Deferred @D(R) 2.7
> Absolute @(PC) 0.6
> Auto-inc.def. @(R)+ 0.3
> Auto-dec. -(R) 0.9
>
> for a total of 6.6% of the operand specifiers; there are about 1.5
> operand specifiers per instruction (Table 3), so that's ~0.1 operand
> specifier with a fancy addressing mode per instruction.
>
> Back to why S/360 has more instructions than VAX, John Levine gave a
> good answer.
>
> One aspect (partially addressed by John Levine, but not discussed
> explicitly) is that the VAX is a three-address machine, while S/360 is
> a two-address machine, so the S/360 occasionally needs reg-reg moves
> where VAX does not. Plus, S/360 usually requires one of its two
> operands to be a register, so in some cases an additional load is
> necessary on the S/360 that is not needed on the VAX.
>
> Among the complex VAX instructions CALL/RET and multi-register push
> and pop constiture 3.22% of the instructions according to Table 1 of
> <https://www.eecg.utoronto.ca/~moshovos/ACA06/readings/emer-clark-VAX.pdf>
> I expect that these correspond to multiple instructions on the S/360.
>
> - anton

There is also a different paper with slightly different stats that,
amonst other things, shows address mode usage by compiled language.

A Case Study of VAX-11 Instruction Set Usage For Compiler Execution
Wiecek, 1982
https://dl.acm.org/doi/pdf/10.1145/960120.801841

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
><https://www.eecg.utoronto.ca/~moshovos/ACA06/readings/emer-clark-VAX.pdf>
>shows that addressing modes that the S/360 or even MIPS does not
>support are quite rare:
>
> %
>Auto-inc. (R)+ 2.1
>Disp. Deferred @D(R) 2.7
>Absolute @(PC) 0.6
>Auto-inc.def. @(R)+ 0.3
>Auto-dec. -(R) 0.9

That's not entirely fair. The VAX has an immediate address mode that
could encode constant values from 0 to 63. Both papers said it was
about 15% so it was definitely a success. The 370 had sort of a split
personality, a shotgun marriage of a register scientific machine
and a memory-to-memory commercial machine. There were a bunch of
instructions with immediate operands but they all were a one byte
immediate and a memory location. Hence the extra LA instructions to
get immediates into registers.

Both papers said the index mode, which added a scaled register to an
address computed any other way, was about 6% which was higher than I
would have expected. The 370 has a similar base+displacement+index
which I hear is almost never used.

>Among the complex VAX instructions CALL/RET and multi-register push
>and pop constiture 3.22% of the instructions according to Table 1 of
><https://www.eecg.utoronto.ca/~moshovos/ACA06/readings/emer-clark-VAX.pdf>
>I expect that these correspond to multiple instructions on the S/360.

The VAX had an all singing and dancing CALLS/RET that saved registers
and set up a stack frame. and a simple JSB/RSB that just pushed the
return address and jumped. CALLS was extremely slow and did far
more than was usually needed so for the most part it was only used
for inter-module calls that had to use the official calling sequence,
and JSB for everything else.

The VAX instruction set was overoptimized for code size and a
simplistic idea of easy programming which meant among other things
that a fancy instruction was often slower than the equivalent sequence
of simple instructions, and a lot of the fancy instructions weren't
used very much.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly