On Thu, 18 Jan 2024 19:08:47 -0000 (UTC), John Levine wrote:

> The 370 had sort of a split personality, a shotgun marriage of a
> register scientific machine and a memory-to-memory commercial machine.

That pins things down quite narrowly as to when it came into being,
doesn’t it? Up to about that point, “scientific” and “business” computing
were considered to be separate worlds, needing their own hardware and
software, and never the twain shall meet.

On Thu, 18 Jan 2024 16:24:13 GMT, Anton Ertl wrote:

> [MIPS] could do at most one instruction per clock, and it certainly
> needed to branch at some point, so no sustained 1/clock ALU
> instructions.

But it also had delayed branches, so perhaps it could sustain that rate
across a taken branch?

On Thu, 18 Jan 2024 09:19:44 -0500, EricP wrote:

> do i = 1, N
> A(i) = A(i) + B(i)
> end do
>
> ADDD (rB)+, (rA)+

... set up rA, rB, rI ...
BRB $9000
$1000:
ADDD (rB)+, (rA)+
$9000:
SOBGEQ rI, $1000

Why use SOBGEQ with the branch intead of SOBGTR? So that this way, if N =
0, the loop body never executes at all.

According to Lawrence D'Oliveiro <ldo@nz.invalid>:
>On Thu, 18 Jan 2024 19:08:47 -0000 (UTC), John Levine wrote:
>
>> The 370 had sort of a split personality, a shotgun marriage of a
>> register scientific machine and a memory-to-memory commercial machine.
>
>That pins things down quite narrowly as to when it came into being,
>doesn’t it? Up to about that point, “scientific” and “business” computing
>were considered to be separate worlds, needing their own hardware and
>software, and never the twain shall meet.

Yes, the whole point of S/360 was to produce a unified architecture that IBM
could sell to all of their customers.

It may have been a shotgun marriage, but it's been a very long lasting one.

You can still run most S/360 application code unmodified on the latest zSeries.

--
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

According to Lawrence D'Oliveiro <ldo@nz.invalid>:
>On Thu, 18 Jan 2024 09:19:44 -0500, EricP wrote:
>
>> do i = 1, N
>> A(i) = A(i) + B(i)
>> end do
>>
>> ADDD (rB)+, (rA)+
>
> ... set up rA, rB, rI ...
> BRB $9000
>$1000:
> ADDD (rB)+, (rA)+
>$9000:
> SOBGEQ rI, $1000
>
>Why use SOBGEQ with the branch intead of SOBGTR? So that this way, if N =
>0, the loop body never executes at all.

Ah, that must have been a Fortran 77 or later DO loop. In Fortran 66 the
loop usually ran once regardless.

--
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 1/18/24 3:56 PM, Lawrence D'Oliveiro wrote:
> On Thu, 18 Jan 2024 16:24:13 GMT, Anton Ertl wrote:
>
>> [MIPS] could do at most one instruction per clock, and it certainly
>> needed to branch at some point, so no sustained 1/clock ALU
>> instructions.
>
> But it also had delayed branches, so perhaps it could sustain that rate
> across a taken branch?
>
Anton Ertl's point was that 1 **ALU** instruction per clock was
not sustainable. Control flow and memory access instructions are
not ALU instructions. (EricP had written "It supposedly could
sustain 1 reg-reg ALU operation per clock.", but useful programs
tend to access memory and have control flow operations.)

Even without data memory accesses, TLB misses — handled in
software — would prevent perfect performance for a straight-line
program unless the TLB was pre-loaded. (I do not remember if the
PC wrapped, but I think there were multiple segments that had
different mapping features that would have either prevented
such looping or made it "very interesting".)

Lawrence D'Oliveiro wrote:
> On Thu, 18 Jan 2024 09:19:44 -0500, EricP wrote:
>
>> do i = 1, N
>> A(i) = A(i) + B(i)
>> end do
>>
>> ADDD (rB)+, (rA)+
>
> ... set up rA, rB, rI ...
> BRB $9000
> $1000:
> ADDD (rB)+, (rA)+
> $9000:
> SOBGEQ rI, $1000
>
> Why use SOBGEQ with the branch intead of SOBGTR? So that this way, if N =
> 0, the loop body never executes at all.

This is the kind of tiny loop body where I would have considered
replacing the initial BRB $9000 with a dummy instruction (like a compare
reg with immediate) where the immediate value contained the ADDD loop body.

This assumes of course that such a dummy opcode would (on average) be
faster than a taken forward branch!

Terje

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

John Levine <johnl@taugh.com> writes:
>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.

So this advantage of the VAX over S/360 was not a "fancy" addressing
mode, but the immediate addressing mode that S/360 does not have, but
that all RISCs have, even MIPS, Alpha and RISC-V (except that these
architectures define addi/addiu as separate instructions). VAX has
"short literal", as you explain (15.8% of the operands) as well as
"immediate" (2.4% of the operands). With 1.5 operands per
instruction, that alone is a factor 1.27 more instructions for S/360
than for 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.
>
>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.

That probably depends on the compiler. Table 2 of
<https://www.eecg.utoronto.ca/~moshovos/ACA06/readings/emer-clark-VAX.pdf>
lists 4.5% "subroutine call and return", and 2.4% "procedure call and
return"; I assume the latter is the all-singing all-dancing CALL and
RET instruction; the missing 0.82% to the 3.22% mentioned in Table 1
is probably the multi-register push and pop instructions.

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

On Thu, 18 Jan 2024 16:31:29 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:

> 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.
>

That's not totally fair.
S/360 permanently reinvents itself. VAX could have done the same, but
voluntarily refused.

On Thu, 18 Jan 2024 22:16:11 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:

> According to Lawrence D'Oliveiro <ldo@nz.invalid>:
> >On Thu, 18 Jan 2024 19:08:47 -0000 (UTC), John Levine wrote:
> >
> >> The 370 had sort of a split personality, a shotgun marriage of a
> >> register scientific machine and a memory-to-memory commercial
> >> machine.
> >
> >That pins things down quite narrowly as to when it came into being,
> >doesn’t it? Up to about that point, “scientificâ€_ and
> >“businessâ€_ computing were considered to be separate worlds,
> >needing their own hardware and software, and never the twain shall
> >meet.
>
> Yes, the whole point of S/360 was to produce a unified architecture
> that IBM could sell to all of their customers.
>
> It may have been a shotgun marriage, but it's been a very long
> lasting one.
>

Was it?
Being younger observer from the outside, my impression is that in the
1st World people stopped using S/360 descendents for "heavy" scientific
calculations around 1980. In other parts of the World it lasted few
years longer, but still no longer than 1990. Use of IBM manframes for
CAD continued well into 90s and may be even into this century, but CAD
is not what people called "scientific computing" back when S/360 was
conceived.

> You can still run most S/360 application code unmodified on the
> latest zSeries.
>

Michael S <already5chosen@yahoo.com> writes:
>Being younger observer from the outside, my impression is that in the
>1st World people stopped using S/360 descendents for "heavy" scientific
>calculations around 1980. In other parts of the World it lasted few
>years longer, but still no longer than 1990.

Meanwhile, in my part of the third world (Austria) politicians praised
themselves for buying a supercomputer from IBM. Searching for it, I
find <https://services.phaidra.univie.ac.at/api/object/o:573/get>, and
on page 2 it tells me that the inauguration of the supercomputer IBM
3090-400E VF (with two vector processors) happened on March 7, 1989.
That project was originally limited to two years, but a contract
signed on 1992-03-19 exteded the run-time and extended the hardware to
a 6-processor ES/9000 720VF; that extension also included 20
RS/6000-550, and they found out that the cumulated computing power
exceeded the one of the vector computer by far. The vector computer
was uninstalled in January 1995.

After the RS/6000 cluster they used an Alpha cluster from 1995 to
2001, and this was replaced in 2001 with a PC-based Linux cluster
(inaugurated on January 28, 2002) consisting of 160 nodes with an
Athlon XP 1700+ and 1GB RAM each.

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

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>So this advantage of the VAX over S/360 was not a "fancy" addressing
>mode, but the immediate addressing mode that S/360 does not have, but
>that all RISCs have, even MIPS, Alpha and RISC-V (except that these
>architectures define addi/addiu as separate instructions). VAX has
>"short literal", as you explain (15.8% of the operands) as well as
>"immediate" (2.4% of the operands). With 1.5 operands per
>instruction, that alone is a factor 1.27 more instructions for S/360
>than for VAX.

Looks that way. IBM apparently noticed it too since S/390 added 16 bit
immediate load, compare, add, subtract, and multiply, and zSeries
added immediate everything, such as add immediate to memory.

>That probably depends on the compiler. Table 2 of
><https://www.eecg.utoronto.ca/~moshovos/ACA06/readings/emer-clark-VAX.pdf>
>lists 4.5% "subroutine call and return", and 2.4% "procedure call and
>return"; I assume the latter is the all-singing all-dancing CALL and
>RET instruction; the missing 0.82% to the 3.22% mentioned in Table 1
>is probably the multi-register push and pop instructions.

Sounds right. I'm surprised the procedure call numbers were so high.

--
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

Michael S <already5chosen@yahoo.com> writes:
>S/360 permanently reinvents itself. VAX could have done the same, but
>voluntarily refused.

Voluntarily? The VAX 9000 project cost DEC billions. Ok, one can
imagine an alternative history where DEC has decided to avoid
switching to MIPS and Alpha, and where they would have followed up the
NVAX (which seems to be pipelined, but not superscalar, i.e., like the
486) with eventually an OoO implementation, and from then on might
have had an easier time competing with RISCs.

The question is how many customers would have defected to RISC-based
systems in the meantime, and if DEC could have survived competition
from ever more capable PCs that eliminated the RISC workstation
market and the RISC server market.

IBM z and i survives because of a legacy of system-specific software
(written in assembly or using other system-specific features), because
the additional hardware cost is an acceptable price for being able to
continue to use this software.

Many VAX customers were flexible enough to switch to something else
when VAX was no longer competetive (that's why DEC did the MIPS-based
DECstations), so I doubt that DEC would have survived in the
alternative history I outlined, at least as a significant manufacturer
rather than a niche manufacturer like Unisys.

One interesting aspect is that NVAX was only released in 1991, while
the 486 was released in 1989, and the MIPS R2000 in 1986, so the VAX
instruction set did have a cost.

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

According to Michael S <already5chosen@yahoo.com>:
>> It may have been a shotgun marriage, but it's been a very long
>> lasting one.
>
>Was it?
>Being younger observer from the outside, my impression is that in the
>1st World people stopped using S/360 descendents for "heavy" scientific
>calculations around 1980. ...

It was earlier than that. The 370/195 was IBM's last attempt to build
a supercomputer, introduced in 1970 and never sold very well. They
added vector options on later machines which someone must use, since
they're still on zSeries, but they've never been competitive for
pure computing.

The point of a mainframe is that it has a balance between CPU and I/O.
A PDP-8 had a much faster CPU than a 360/30, but the 360 had an I/O
channel that connected card readers and printers and tapes and disks
so it could do data processing work that nobody did on a PDP-8. A
PDP-8 could also conect to those but each needed an expensive I/O
interface to attach to the 8's simple I/O bus, so hardly anyone did.

Mainframes are also designed to be very reliable and maintainable. A
modern mainframe has dozens of CPUs some of which are only doing
maintenance oversight and others of which are hot spares that can
substitute for a failed processor in the middle of an instruction
stream. They're also designed so the vendor can do maintenance and
replace subystems while the system is running. People expect them to
remain up and running constantly for years at a time.

Apropos another comment that the 360 has evolved but the Vax didn't,
that is certainly true, since zSeries is about 70% new stuff and
30% 360 stuff, but the 360 was a much better place to build from.
It is much easier to build a fast 360 than a fast Vax because
the instruction set, even with all the zSeries additions, is
more regular and amenable to pipelining.

The worst mistake they made from a performance point of view is
that the architecture says an instruction can modify the next
instruction and it is supposed to work. (Back in the 1960s
on machines with 8K of RAM that was not totally silly.) But
even that hardly matters since the vast majority of code
runs out of read-only pages where you can't do that.

--
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

jgd@cix.co.uk (John Dallman) writes:
>In article <20240119164019.0000374e@yahoo.com>, already5chosen@yahoo.com
>(Michael S) wrote:
>
>> Being younger observer from the outside, my impression is that in
>> the 1st world people stopped using S/360 descendents for "heavy"
>> scientific calculations around 1980.
>
>Yup. VAXes and other superminis got you a lot more CPU per dollar.
>
>> Use of IBM manframes for CAD continued well into 90s and may be
>> even into this century, but CAD is not what people called
>> "scientific computing" back when S/360 was conceived.
>
>Some aspects of it are, but many are not. CAD has very uneven processor
>usage: vast demands for brief periods when regenerating views or models,
>then very little while the designer thinks and adds to the model. Running
>this on a time-shared machine is frustrating, because when a few
>designers need a lot of CPU at the same time, it gets very slow.
>Individual machines keep the designers happier.

Modern chip development (RTL/Verilog) environments offload the
compute- and io-bound- jobs to a compute grid with thousands of nodes;
even the visualization jobs using X11 tunnelling to get back to
the workstation display when examining waves, for example.

When you're dealing with billions of gates on a single chip.....

John Levine wrote:
> According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>> So this advantage of the VAX over S/360 was not a "fancy" addressing
>> mode, but the immediate addressing mode that S/360 does not have, but
>> that all RISCs have, even MIPS, Alpha and RISC-V (except that these
>> architectures define addi/addiu as separate instructions). VAX has
>> "short literal", as you explain (15.8% of the operands) as well as
>> "immediate" (2.4% of the operands). With 1.5 operands per
>> instruction, that alone is a factor 1.27 more instructions for S/360
>> than for VAX.
>
> Looks that way. IBM apparently noticed it too since S/390 added 16 bit
> immediate load, compare, add, subtract, and multiply, and zSeries
> added immediate everything, such as add immediate to memory.
>
>> That probably depends on the compiler. Table 2 of
>> <https://www.eecg.utoronto.ca/~moshovos/ACA06/readings/emer-clark-VAX.pdf>
>> lists 4.5% "subroutine call and return", and 2.4% "procedure call and
>> return"; I assume the latter is the all-singing all-dancing CALL and
>> RET instruction; the missing 0.82% to the 3.22% mentioned in Table 1
>> is probably the multi-register push and pop instructions.
>
> Sounds right. I'm surprised the procedure call numbers were so high.

I found a set of LINPACK performance results for many different cpus
from 1983 by Argonne National Laboratory, including 370/158 (they don't
say which model) and 780. The results show both the execute time and
MFLOPS so that removes the variability due to definition of "instruction".

Dongarra has many versions of this paper over the years.
This is just the one from 1983.

Performance of Various Computers Using Standard Linear Equations Software
in a Fortran Environment, Dongarra, 1983
https://dl.acm.org/doi/pdf/10.1145/859551.859555

For double precision the 158 running compiled code is about 50%
faster than 780 running "coded BLAS" (hand coded assembler)
and about 2 times faster than a 780 for compiled code.

For single precision the 780 is slightly faster for "coded BLAS"
and the 158 is about 50% faster for compiled code.

On Thu, 18 Jan 2024 16:31:29 -0000 (UTC), John Levine wrote:

> 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.

The 360/370/xx/3090/yy/zSeries line only survives because of business
“legacy” deployments. It was never a performance-oriented architecture
(witness the trouncing by CDC). It is long obsolete, and those deployments
are dwindling, if not circling the plughole.

VAX was the next step forward in the “supermini” and later “workstation”
categories, and these were definitely about price-performance. So when
other better technologies came along, they rendered it obsolete, fairly
quickly.

On Fri, 19 Jan 2024 18:28:18 -0000 (UTC), John Levine wrote:

> The point of a mainframe is that it has a balance between CPU and I/O.

The point of a mainframe was that the CPU was expensive. So a lot of
effort went into complex I/O controllers that could perform chains of
multiple transfers before having to come back to the CPU to ask for more
work.

Such an architecture tends to prioritize high throughput over low latency.
Which made it unsuitable for this newfangled “interactive timesharing”
that began to be popular with the new hardware and software coming from
companies like DEC, DG etc.

> Mainframes are also designed to be very reliable and maintainable.

They did it in a very expensive way, though. Think how Google manages
reliability and maintainability today: by having a cluster of half a
million servers (maybe more by now), each built from the cheapest parts in
all ways but one--the power supply.

EricP <ThatWouldBeTelling@thevillage.com> writes:
> For single precision the 780 is slightly faster for "coded BLAS"
> and the 158 is about 50% faster for compiled code.

trivia: jan1979, I was asked to run cdc6600 rain benchmark on
(engineering) 4341 (before shipping to customers, the engineering 4341
was clocked about 10% slower than what shipped to customers) for
national lab that was looking at getting 70 for a compute farm (sort of
the leading edge of the coming cluster supercomputing tsunami). I also
ran it on 158-3 and 3031. A 370/158 ran both the 370 microcode and the
integrated channel microcode; a 3031 was two 158 engines, one with just
the 370 microcode and a 2nd with just the integrated channel microcode.

cdc6600: 35.77secs
158: 45.64secs
3031: 37.03secs
4341: 36.21secs

.... 158 integrated channel microcode was using lots of processing
cycles, even when no i/o was going on.

--
virtualization experience starting Jan1968, online at home since Mar1970

According to Lawrence D'Oliveiro <ldo@nz.invalid>:
>On Fri, 19 Jan 2024 18:28:18 -0000 (UTC), John Levine wrote:
>
>> The point of a mainframe is that it has a balance between CPU and I/O.
>
>The point of a mainframe was that the CPU was expensive. So a lot of
>effort went into complex I/O controllers that could perform chains of
>multiple transfers before having to come back to the CPU to ask for more
>work.

On hign end machines, not so much small ones. On the 360/30, the same
microcode engine ran the CPU and the channel. When the channel was
working hard, the CPU pretty much stopped.

>Such an architecture tends to prioritize high throughput over low latency.

Yup.

>Which made it unsuitable for this newfangled “interactive timesharing”
>that began to be popular with the new hardware and software coming from
>companies like DEC, DG etc.

Depended on what model of interaction you wanted. If you wanted the computer
to respond to each character, DEC machines were good at that since they were
designed to do realtime stuff. If you wanted to do line at a time or screen
at a time interaction, mainframes did that just fine. In 1964 SABRE ran on
two IBM 7090s and provided snappy responses to 1500 terminals across the U.S.

I used CP/67 in the early 1970s and it also worked quite well, fast response
in line at a time mode.
--
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

jgd@cix.co.uk (John Dallman) writes:
>In article <2024Jan19.174330@mips.complang.tuwien.ac.at>,
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> Voluntarily? The VAX 9000 project cost DEC billions. Ok, one can
>> imagine an alternative history where DEC has decided to avoid
>> switching to MIPS and Alpha, and where they would have followed up
>> the NVAX (which seems to be pipelined, but not superscalar, i.e., like
>> the 486) with eventually an OoO implementation, and from then on might
>> have had an easier time competing with RISCs.
>
>The timeline doesn't work. DEC decided to adopt MIPS in 1989, because
>they were loosing market share worryingly quickly. NVAX was released in
>1991, and they'd have had real trouble developing it without the cash
>from MIPS-based systems.

I forgot that in this alternative reality DEC would have killed the
VAX 9000 project early, leaving them lots of cash for developping
NVAX. Still, it could easily have been that they would have lost
customers to the RISC competition until they finally managed to do the
OoO-VAX.

Would they have gotten those customers back, or would they have lost
to IA-32/AMD64 anyway? Probably the latter, unless they found a
business model that allowed them to milk the customer base that was
tied to VAX while at the same time being cheap enough to compete with
Intel. They tried to go for that on the Alpha: they used firmware for
market segmentation between VMS/Digital OSF/1 on the one hand and
Linux/Windows on the other; and they also offered some relatively
cheap boards, e.g. with the 21164PC, but those were probably too
limited to be successful.

>That is less
>obvious now, but that's because of the huge amounts of money that have
>gone into x86 development over the last thirty years. DEC's market for
>VAX systems was much smaller than the market for x86 in 1995-2010.

For developing an OoO-VAX the relevant time is 1985-1995 (HPS wrote
their papers on OoO (with VAX as example) starting in 1985, the
Pentium Pro appeared in 1995). Of course, for OoO-VAXes to succeed in
the market, the relevant timespan was 1995-2005. Intel dropped the
64-bit IA-32 successor ball and AMD picked it up with the 2003
releases of Opteron and Athlon64.

VAX would have been extended to 64 bits some times in the early 1990s
in the alternative timeline, and DEC would have been tempted to use
the 64-bit extension for market segmentation, which again could have
resulted into DEC painting itself into a niche.

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

jgd@cix.co.uk (John Dallman) writes:
>In article <2024Jan20.101000@mips.complang.tuwien.ac.at>,
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>> For developing an OoO-VAX the relevant time is 1985-1995 (HPS wrote
>> their papers on OoO (with VAX as example) starting in 1985, the
>> Pentium Pro appeared in 1995). Of course, for OoO-VAXes to succeed
>> in the market, the relevant timespan was 1995-2005. Intel dropped
>> the 64-bit IA-32 successor ball and AMD picked it up with the 2003
>> releases of Opteron and Athlon64.
>
>This requires DEC to take notice of those papers and start developing OoO
>quite quickly.
....
>If DEC go OoO and build an OoO Micro-VAX CPU by about 1988, they can get
>somewhere. The MicroVAX 78032 of 1985 was 125K transistors; the 80386 was
>275K transistors the same year, the 40486 was 1.2M transistors in 1989,
>so the transistor budget could be there.

Not in a single chip. The CPU die of the Pentium Pro has 5.5M
transistors and was available in 1995. Nobody else was much earlier
on OoO, even with the RISC advantage. If DEC had picked up the HPS
ideas and invented what's missing from there, they might have had the
OoO VAX as a multi-chip thing in the early 1990s, and maybe gotten it
on a single chip by 1995. But its performance in the early 1990s
would have been great, so it could have won back customers.

>Yup. Really, you have to get the traditional DEC management to all retire
>before 1990, and the new management need to be brave /and/ lucky.

Yes, you would basically need to have a whole bunch of managers and
tech team leaders take a time machine from, say, today, so they know
where to go, and they still would need to make and enforce good
decisions to make the company succeed in the long term rather than
painting itself into a corner by maximizing short-term revenue.

You story about your experiences with DEC remind me of one statement I
once read: DEC buy X, and the result is DEC. Compaq buys DEC, and the
result is DEC (as in, the DEC attitude won over the Compaq attitude).

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

According to John Dallman <jgd@cix.co.uk>:
>Yup. Really, you have to get the traditional DEC management to all retire
>before 1990, and the new management need to be brave /and/ lucky.

DEC never really understood what business they were in. They had a pretty good
run selling hardware that was cheap and reliable, with software that was adequate.
But more often than not it was used with other software, Compuserve's system
and Tenex on the -10, and Unix on the -11 and Vax.

That worked fine while minicomputers were the cheapest way to do small scale
computing. Once micros came in, they weren't able to produce chips that
competed on their own (as opposed to being slightly cheaper versions of
their minis) and they deluded themselves that they could lock people in
with VMS the way IBM did with DOS and OS and AS/400.

--
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 Sat, 20 Jan 2024 18:15:43 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> You story about your experiences with DEC remind me of one statement I
> once read: DEC buy X, and the result is DEC. Compaq buys DEC, and the
> result is DEC (as in, the DEC attitude won over the Compaq attitude).
>
> - anton

But later on HP bought Compaq and eventually the computing side of the
business became indistinguishable from Compaq. Both DEC and HP parts
already dissolved. Ex-SGI side still hanging, but likely not for long.

On Sat, 20 Jan 2024 16:25 +0000 (GMT Standard Time), John Dallman wrote:

> In article <2024Jan20.101000@mips.complang.tuwien.ac.at>,
> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
> ... Dave Cutler probably doesn't move to Microsoft, and then Windows NT
> doesn't happen, at least not in the same way.

Imagine if it hadn’t been created by a Unix-hater. But then, Microsoft had
already divested themselves of Xenix by then, hadn’t they? So they
probably didn’t have anyone left who understood the value of Unix.