jgd@cix.co.uk (John Dallman) writes:

> In article <1389dbdd-5e45-4688-a8ae-ff36de25ee78n@googlegroups.com>,
> gah4@u.washington.edu (gah4) wrote:

>> On Wednesday, July 26, 2023 at 5:05:41_PM UTC-7, bill wrote:

>>> But now I have to wonder why they didn't just continue
>>> development of the 10 and 20.

>> Partly, the world was moving to 8 bit byte addressable systems.
>> Or at least an 8 bit character set.

>> But yes, it seems that many wondered that at the time.

> It looks like a commercial decision. As of 1982-83, when the decision was
> being made, VAX was wildly successful, and DEC-10 and DEC-20 were not
> growing fast.

Yes and no.

The decision to discontinue the 36 bit line was partly technical and partly
company internal political.

First, the technical side.

The primary line of descent in the PDP-6/PDP-10 family went from the Model 166
processor to the KA-10 to the KI-10 to the KL-10. (The KS-10 was a cut down
limited version of the larger system family.) The KL-10 was based on a design
begun at Stanford Artificial Intelligence Laboratory because the KI-10 was not
a suitable replacement for the KA-10 with the BBN pager add-on; DEC bought the
design and hired the graduate student who maintained the CAD system developed
at SAIL (which became the standard design system at DEC for a number of years).
Unlike the previous systems, the KL-10 was a microcoded processor.

When the KL-10 was delivered in late 1974, it was already behind the curve in
terms of MIPS ratings and I/O throughput with regard to the leaders of the
industry, but its architecture was well liked by those who used it. The next
processor began design soon after, but was too ambitious in its goals, delayed
by technical problems, and eventually cancelled in 1983. Some of the features
were retrofitted to the KL-10 by updates to the microcode in conjunction with
additional hardware (larger address space--18 bits => 30 bits--was first around
1979, then the CI bus and clustering in 1986). The follow-on, codenamed
"Jupiter", was supposed to be 2.5x a KL-10, but never got to even 2x in prototype.

All of this was going on while the middle management in the VAX world was
promoting Bell's "one architecture for everything" dream, pulling personnel and
funding from the other product lines, contributing to the delays which were the
nominal reason for the cancellation of Jupiter.

There were clone manufacturers as well. Foonly was started by a SAIL alumnus,
and sold a few systems, but each one was essentially a prototype and boards
were not guaranteed to be interchangeable. Systems Concepts delivered the
first of their offerings to Stanford LOTS (the academic computing facility
where I happened to be the systems programmer) on Hallowe'en 1986; they sold
quite a few, then licensed the design to Compuserve who built them for their
internal network. XKL was founded by one of the cofounders of cisco Systems,
to build a desktop sized KL-10 clone he suggested to DEC management when he was
an engineer in Marlboro; XKL is still in business, selling very high end
optical networking gear whose control processors are dual FPGA clones of their
first product.

NB: The processors in XKL's Darkstar products can run either TOPS-20 or an XKL
OS called DXMOS. Anyone who would like to try out one of these systems can
check out the guest acccounts available at SDF.org .

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

In article <u9tmug$1sfk2$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2023-07-26, Arne Vajh�j <arne@vajhoej.dk> wrote:
>> On 7/26/2023 8:14 AM, Simon Clubley wrote:
>>> On 2023-07-25, Chris Townley <news@cct-net.co.uk> wrote:
>>>> Never used macro32 - I gave up any low level language after playing with
>>>> Zilog Z80 code in the early 80s
>>>
>>> Of all the assembly languages I have used (PDP-11, VAX, Alpha, x86, MIPS,
>>> ARM, Z80, 8-bit PIC, plus various historical others), I found traditional
>>> full ARM to be by far the nicest and 8-bit PIC was easily the most ugly.
>>
>> "nicest" in what way?
>>
>
>As Scott points out the traditional ARM architecture is very elegant.
>
>> Traditionally VAX and M68K has been considered the most high level
>> and requiring least lines of code per functionality.
>>
>
>M68K I can't talk about because I never used it. That's why I limited
>my comment above to the assembly languages I do know.

M68k was (is?) very nice, but the distinction between data and
address registers is mildly annoying. It would have been nicer
to just have 16 GP registers, but they saved a bit in the
instruction coding by splitting things into 8 each.

- Dan C.

On 7/27/2023 1:08 PM, bill wrote:
> On 7/27/2023 8:46 AM, Johnny Billquist wrote:
>> On 2023-07-27 02:05, bill wrote:
>>> But now I have to wonder why they didn't just continue development of
>>> the 10 and 20.
>>
>> Do you really want to open up that wound again? :-D
>
> I would love to see what the performance would be for any of these
> processors made with today's tech.  I think even without growing
> memory size they would be more than adequate and probably a lot
> better than some of the Windows Servers running applications today.

The CPU business has become a very skewed market due to the
cost structure.

Gigantic fixed cost (billions of dollars for research and fabs)
and relative small variable cost (silicium, labor, sale etc.)
make low volume CPU's non-competitive.

VAX, Alpha and Itanium was all killed. It seems rather likely
that the 10 would have gone the same way.

Arne

On 7/27/2023 1:08 PM, bill wrote:
> On 7/27/2023 8:46 AM, Johnny Billquist wrote:
>> On 2023-07-27 02:05, bill wrote:
>>> But now I have to wonder why they didn't just continue development of
>>> the 10 and 20.
>>
>> Do you really want to open up that wound again? :-D
>
> I would love to see what the performance would be for any of these
> processors made with today's tech.  I think even without growing
> memory size they would be more than adequate and probably a lot
> better than some of the Windows Servers running applications today.

Joke question: when the 10 would need to go to the next level
would it have moved from 36 bit to 72 bit?

:-)

Arne

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>As Scott points out the traditional ARM architecture is very elegant.
>
>> Traditionally VAX and M68K has been considered the most high level
>> and requiring least lines of code per functionality.
>>
>
>M68K I can't talk about because I never used it. That's why I limited
>my comment above to the assembly languages I do know.

It's very PDP-11-like. It is a joy to program. I wish it had more
registers, though.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On Thursday, July 27, 2023 at 1:20:25 PM UTC-7, Rich Alderson wrote:

(snip)

> When the KL-10 was delivered in late 1974, it was already behind the curve in
> terms of MIPS ratings and I/O throughput with regard to the leaders of the
> industry, but its architecture was well liked by those who used it. The next
> processor began design soon after, but was too ambitious in its goals, delayed
> by technical problems, and eventually cancelled in 1983.

Whole books could be written about processors that didn't live up to their
design goals. The IBM Stretch, named for the stretch of technology to
build it, one of the more famous cases.

Next should be the books on operating systems that didn't live
up to their design goals.

On 2023-07-28 01:13, Arne Vajhøj wrote:
> On 7/27/2023 1:08 PM, bill wrote:
>> On 7/27/2023 8:46 AM, Johnny Billquist wrote:
>>> On 2023-07-27 02:05, bill wrote:
>>>> But now I have to wonder why they didn't just continue development of
>>>> the 10 and 20.
>>>
>>> Do you really want to open up that wound again? :-D
>>
>> I would love to see what the performance would be for any of these
>> processors made with today's tech.  I think even without growing
>> memory size they would be more than adequate and probably a lot
>> better than some of the Windows Servers running applications today.
>
> Joke question: when the 10 would need to go to the next level
> would it have moved from 36 bit to 72 bit?
>
> :-)

Most probably yes. I seem to remember that FP was already using 72 bits.
Would have been a natural step.

Johnny

On 2023-07-28 01:12, Arne Vajhøj wrote:
> On 7/27/2023 1:08 PM, bill wrote:
>> On 7/27/2023 8:46 AM, Johnny Billquist wrote:
>>> On 2023-07-27 02:05, bill wrote:
>>>> But now I have to wonder why they didn't just continue development of
>>>> the 10 and 20.
>>>
>>> Do you really want to open up that wound again? :-D
>>
>> I would love to see what the performance would be for any of these
>> processors made with today's tech.  I think even without growing
>> memory size they would be more than adequate and probably a lot
>> better than some of the Windows Servers running applications today.
>
> The CPU business has become a very skewed market due to the
> cost structure.
>
> Gigantic fixed cost (billions of dollars for research and fabs)
> and relative small variable cost (silicium, labor, sale etc.)
> make low volume CPU's non-competitive.
>
> VAX, Alpha and Itanium was all killed. It seems rather likely
> that the 10 would have gone the same way.

Even more so, since in addition to it also being a niche CPU compared to
the mass market CPUs, it would be more efforts to port a lot of pretty
standard software because of the "odd" word size and addressing.

Johnny

On 2023-07-27 21:45, John Dallman wrote:
> In article <kifmjpF4bvU2@mid.individual.net>, bill.gunshannon@gmail.com
> (bill) wrote:
>
>> I would love to see what the performance would be for any of these
>> processors [DEC-10, DEC-20] made with today's tech. I think even
>> without growing memory size they would be more than adequate and
>> probably a lot better than some of the Windows Servers running
>> applications today.
>
> What sort of thing would you want to use them for? I don't know the
> architecture well, but they seem to be limited to 30-bit addressing of
> their 36-bit words. That's more or less 4GB, which will do for many
> things, but there doesn't seem to be any obvious advantage of the
> architecture that would make doing an commercial implementation
> worthwhile.
>
> If you were keen, you could do an FPGA version: some Amiga fans have done
> that for the Motorola 68000 family. http://www.apollo-core.com/
>
> The painful part is the character size: 6-bit characters aren't adequate
> for lots of modern work. Using 8-bit characters is probably best. That
> wastes four bits per word, but allows you to use UTF-8 and communicate
> with other kinds of machine.

Well. That last part could be expanded more. Since a byte on a PDP-10
could be anything from 1 bit to 36 bits, you can do a lot. The KCC C
compiler uses 9-bit words. And there is even a UTF-9 defined. :-D

Johnny

On 2023-07-27 19:08, bill wrote:
> On 7/27/2023 8:46 AM, Johnny Billquist wrote:
>> On 2023-07-27 02:05, bill wrote:
>>> On 7/26/2023 2:33 PM, Rich Alderson wrote:
>>
>>>> Ha!  I still make a living programming in Macro-{10,20}, because
>>>> certain tools
>>>> are written in it and nothing else will do.
>>>>
>>>
>>> Wait a minute.  Are you saying you still make a living supporting
>>> SYSTEM-10 and SYSTEM-20 computers and not just hobbyist machines?
>>>
>>> Brings up  yet another question, I guess.
>>>
>>> I have always wondered why they created the VAX instead of continuing
>>> development of the PDP-11. I mean, look what INTEL did taking the 8080
>>> (or maybe even the 8008) all the way to x86-64.
>>
>> You could argue that this is what DEC did. Except they eventually
>> dropped PDP-11 support in hardware and moved it to software emulation,
>
> Sorry, I certainly don't see it that way.  I see nothing in the VAX that
> reminds me of the PDP-11.

I am surprised by that statement. The VAX feels so much like a mutated
PDP-11 it's ridiculous, in my opinion.
The compatibility mode is fairly straight forward because of this.

>> and then dropped it altogether. Which just suggest they didn't think
>> there was enough value to keep it around.
>> And doing explicitly as a compatibility mode allowed for a cleaner
>> design than what Intel did with the 8080.
>> I assume you haven't missed all the cursing of that architecture.
>
> I worked with 8080's and Z80's (yes, I know that's not Intel).  They
> were just fine.  Unlike the 6502 which I thought was a piece of crap.

The Z80 is definitely better than the 8080. But the cursing wasn't that
much about the original CPU, but all the expansions and extensions,
while still being backward compatible, leading to a CPU today that is a
bit of a nightmare. Both for programmers and developers of silicon.

There is a reason very few wants to work in assembler on it...

>>> But now I have to wonder why they didn't just continue development of
>>> the 10 and 20.
>>
>> Do you really want to open up that wound again? :-D
>
> I would love to see what the performance would be for any of these
> processors made with today's tech.  I think even without growing
> memory size they would be more than adequate and probably a lot
> better than some of the Windows Servers running applications today.

It's not a design that easily lends itself to performance. It's a nice
architecture to write in assembly on.

Windows Servers is actually about software, and not hardware. And yes,
TOPS-20 is way nicer than Windows...

Memory wasn't particularly a problem on the PDP-10, for sure. But
portability of software was a bit more of a headache.
And performance...

Johnny

On 2023-07-27 15:03, Jan-Erik Söderholm wrote:
> Den 2023-07-27 kl. 14:46, skrev Johnny Billquist:
>> On 2023-07-27 02:05, bill wrote:
>>> On 7/26/2023 2:33 PM, Rich Alderson wrote:
>>
>>>> Ha!  I still make a living programming in Macro-{10,20}, because
>>>> certain tools
>>>> are written in it and nothing else will do.
>>>>
>>>
>>> Wait a minute.  Are you saying you still make a living supporting
>>> SYSTEM-10 and SYSTEM-20 computers and not just hobbyist machines?
>>>
>>> Brings up  yet another question, I guess.
>>>
>>> I have always wondered why they created the VAX instead of continuing
>>> development of the PDP-11. I mean, look what INTEL did taking the 8080
>>> (or maybe even the 8008) all the way to x86-64.
>>
>> You could argue that this is what DEC did. Except they eventually
>> dropped PDP-11 support in hardware and moved it to software emulation,
>> and then dropped it altogether. Which just suggest they didn't think
>> there was enough value to keep it around.
>
> PDP-11 software that was run within the VAX hardware environment was
> probably just moved to the VAX/VMS platform.

Over time for sure. Original VMS was running almost everything in
compatibility mode. But much VMS software started out as ported PDP-11
software, and then expanded and improved uppon.

> Software that needed the PDP-11 platform (maybe due to special
> interfaces and I/O cards) probably stayed on real PDP-11 hardware.
> I'm sure there was many real PDP-11 systems alive well after that
> the PDP-11 emulation in VAX was removed.

Sure. You could even argue that the PDP-11 outlived the VAX.

But I think DEC's approach was nicer and better than Intel's. It's just
that Intel just managed to grab the whole market. Technological merit
had nothing to do with it.

Johnny

jgd@cix.co.uk (John Dallman) writes:

> In article <kifmjpF4bvU2@mid.individual.net>, bill.gunshannon@gmail.com
> (bill) wrote:

>> I would love to see what the performance would be for any of these
>> processors [DEC-10, DEC-20] made with today's tech. I think even
>> without growing memory size they would be more than adequate and
>> probably a lot better than some of the Windows Servers running
>> applications today.

> What sort of thing would you want to use them for? I don't know the
> architecture well, but they seem to be limited to 30-bit addressing of
> their 36-bit words. That's more or less 4GB, which will do for many
> things, but there doesn't seem to be any obvious advantage of the
> architecture that would make doing an commercial implementation
> worthwhile.

An embedded processor which can run a fully capable operating system is
extremely useful. Len Bosack, cofounder of cisco systems, was never happy that
they were limited to the capabilities of the M68K processor family.

> If you were keen, you could do an FPGA version: some Amiga fans have done
> that for the Motorola 68000 family. http://www.apollo-core.com/

The original product from XKL was the Toad-1 system.[1] The CPU was based on an
Altera part programmed in PALASM to provide a microcode engine. The TOAD-2
processor in their Darkstar optical routers is built around a Xilinx part using
VHDL.

There are also a couple of hobbyist FPGA implementations of the KA-10
processor, using Verilog.

> The painful part is the character size: 6-bit characters aren't adequate
> for lots of modern work. Using 8-bit characters is probably best. That
> wastes four bits per word, but allows you to use UTF-8 and communicate
> with other kinds of machine.

The byte size on a PDP-10 is defined in the byte pointer (so not equivalent to
an integer). The standard character set in DEC's systems, all the way back to
the PDP-6 in 1964, is 7-bit ASCII, with 5 characters per word. The extra bit
was even used by the editor to mark line numbers in test files; the assembler
and various compilers ignored words so marked.

As noted elsewhere, the C compiler uses 9 bit bytes.

The UTF-9 and UTF-18 encodings were proposed by our late friend Mark Crispin,
and rejected by the Unicode editors because he was the proposer.

[1] "ToaD" was the codename Bosack gave to his proposal for a -10 on a desk
when he was an engineer in DEC's Large Systems group. The original
business plan for cisco Systems was to build the ToaD; they built
networking gear, beginning with the Massbus-Ethernet Interface Subsystem
(MEIS)[2] and continuing on to terminal interface processors (TIPs) and
routers.

[2] The Stanford developed Ethernet interface for the KL-10, available years
before the NIA-20 which came out of the cancelled Jupiter project. The
MEIS was more featureful than the eventual Digital product.

--
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 Friday, July 28, 2023 at 1:03:20 PM UTC-7, Rich Alderson wrote:

(snip)

> The byte size on a PDP-10 is defined in the byte pointer (so not equivalent to
> an integer). The standard character set in DEC's systems, all the way back to
> the PDP-6 in 1964, is 7-bit ASCII, with 5 characters per word. The extra bit
> was even used by the editor to mark line numbers in test files; the assembler
> and various compilers ignored words so marked.
SOS would generate and use those numbers.

At least the Fortran compiler would use them in messages,
if they were there. I don't remember if Macro-10 does that.

> As noted elsewhere, the C compiler uses 9 bit bytes.
Choices would be 9, 18, or 36 for char.

With the H.. instructions, I once thought 18 might be easier.

(snip)
> [2] The Stanford developed Ethernet interface for the KL-10, available years
> before the NIA-20 which came out of the cancelled Jupiter project. The
> MEIS was more featureful than the eventual Digital product.
3MB/s or 10MB/s? I only recently learned that Stanford built the 3MB/s
Ethernet for the Sun-1. That way they could use the Sun-1 as a gateway.

gah4 <gah4@u.washington.edu> writes:

> On Friday, July 28, 2023 at 1:03:20=E2=80=AFPM UTC-7, Rich Alderson wrote:

>> [2] The Stanford developed Ethernet interface for the KL-10, available years
>> before the NIA-20 which came out of the cancelled Jupiter project. The
>> MEIS was more featureful than the eventual Digital product.

> 3MB/s or 10MB/s? I only recently learned that Stanford built the 3MB/s
> Ethernet for the Sun-1. That way they could use the Sun-1 as a gateway.

The original MEIS was 3Mbit. I installed one of the first 10Mbit MEISes on a
DEC-20 at LOTS.

You have the order backwards, by the way. The 3Mbit PUP network was created to
connect the dozen TOPS-20 and TENEX sites around campus, and PUP routing was
inserted into the monitors.

The SUN ("Stanford University Network") processor board was built for a
different project, a 3M desktop system ("1 MIPS, 1MB memory, 1M pixel
display"). Only after the Ethernet went in did it become a 4M processor ("and
1MB/sec networking").

It became the "Sun-1" only after the engineering grad student who did the
detail design based on the high level design from a well known TOPS-20
personality took his B-school friend's advice and started a company.

--
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 Saturday, July 29, 2023 at 7:15:02 PM UTC-7, Rich Alderson wrote:

(snip)

> You have the order backwards, by the way. The 3Mbit PUP network was created to
> connect the dozen TOPS-20 and TENEX sites around campus, and PUP routing was
> inserted into the monitors.
Yes, I wasn't trying to order them.

> The SUN ("Stanford University Network") processor board was built for a
> different project, a 3M desktop system ("1 MIPS, 1MB memory, 1M pixel
> display"). Only after the Ethernet went in did it become a 4M processor ("and
> 1MB/sec networking").
> It became the "Sun-1" only after the engineering grad student who did the
> detail design based on the high level design from a well known TOPS-20
> personality took his B-school friend's advice and started a company.
So it went from SUN to Sun-1 when they started the company?

I did know some time ago that it was named for Stanford University Network,
though the company didn't advertize that so much.

On Thursday, July 27, 2023 at 4:20:25 PM UTC-4, Rich Alderson wrote:
> The follow-on, codenamed
> "Jupiter", was supposed to be 2.5x a KL-10, but never got to even 2x in prototype.
>
> All of this was going on while the middle management in the VAX world was
> promoting Bell's "one architecture for everything" dream, pulling personnel and
> funding from the other product lines, contributing to the delays which were the
> nominal reason for the cancellation of Jupiter.

The Dolphin (KM-10 or KXF10 at various times) had hopes of being both a
KL-10 and a VAX: "Dolphin is an advanced computer system based on a new
generation CPU incorporating Macro Cell Array technology. It is the logical
successor to the KL-10 based PDP-10/20 system, and may well become the
high-end VAX system." That seems like an odd idea - the additional 4 bits in
registers, data paths and main memory would seem to be an unnecessary
expense in VAX mode.

Later, LCG had 2 irons in the fire - Jupiter and Venus. Venus was closer to
getting out the door even though it didn't meet its design goals WRT perfor-
mance. It was released as the VAX 8600 (although somewhere around here
I have a "VAX-11/790" masthead). The design got quite close to being able
to meet its original performance goal - the 8600 -> 8650 upgrade only
changed 2 boards and the console disk pack. The planned "mid-life kicker"
(which would likely have been the VAX 8670) never happened. In fact, none
of the 8x70 systems saw daylight, although someone supposedly had a field
test 8370.

LCG kept steaming on, full speed ahead, until it ran into an iceberg with the VAX
9000. Rumor had it that by then, the number of people in LCG who had been
there long enough to get a first-pass product out the door had dwindled to a
very small percentage of the people in the group.

I remember being at a DECUS symposium where LCG had a mostly-empty
exhibit. I asked "So, what are you people up to, anyway?" and got a behind-
the-curtain view of a Multi-Chip Unit from an unspecified forthcoming
product. The packaging was truly bizarre and nothing at all like previous
DEC designs. It actually looked like something IBM would do.

On Sunday, July 30, 2023 at 11:28:32 PM UTC-7, terry-...@glaver.org wrote:

(snip)

> The Dolphin (KM-10 or KXF10 at various times) had hopes of being both a
> KL-10 and a VAX: "Dolphin is an advanced computer system based on a new
> generation CPU incorporating Macro Cell Array technology. It is the logical
> successor to the KL-10 based PDP-10/20 system, and may well become the
> high-end VAX system." That seems like an odd idea - the additional 4 bits in
> registers, data paths and main memory would seem to be an unnecessary
> expense in VAX mode.
Having all instructions the same length, like most RISC systems, makes
it very easy to design pipelined parallel processors.

VAX seems to be designed very well to be hard to pipeline.

IBM S/360 and successors have three instruction lengths, all known
from the first byte. Slightly harder, but not all that hard.

VAX, with addressing mode bytes, is well designed for serial processing,
going one byte at a time and decoding it. Each addressing mode byte
indicates how many operand bytes it needs, and so where to find the
next addressing mode byte.

It would have been a very easy change to VAX to put all the address
mode bytes immediately after the opcode. It is still slightly more
complicated due to indexed mode, but not all that hard.
You get all the address mode bytes in parallel, then process any
index mode bytes, and you know where the next instruction is.

But no, for VAX you process each address mode byte, which tells
you were the next one is, which then tells where the next one is ...
Nice for serial microprograms, not for pipelining.

Well, VAX might also be designed to make it easier for assembly
programming, and especially debugging from core dumps.
I don't believe that moving the bytes around would have changed
that much, though.

Seems like the extra bits in the word are not the worst problem.

On 7/31/2023 2:33 PM, gah4 wrote:
> On Sunday, July 30, 2023 at 11:28:32 PM UTC-7, terry-...@glaver.org wrote:
>> The Dolphin (KM-10 or KXF10 at various times) had hopes of being both a
>> KL-10 and a VAX: "Dolphin is an advanced computer system based on a new
>> generation CPU incorporating Macro Cell Array technology. It is the logical
>> successor to the KL-10 based PDP-10/20 system, and may well become the
>> high-end VAX system." That seems like an odd idea - the additional 4 bits in
>> registers, data paths and main memory would seem to be an unnecessary
>> expense in VAX mode.
>
> Having all instructions the same length, like most RISC systems, makes
> it very easy to design pipelined parallel processors.
>
> VAX seems to be designed very well to be hard to pipeline.
>
> IBM S/360 and successors have three instruction lengths, all known
> from the first byte. Slightly harder, but not all that hard.
>
> VAX, with addressing mode bytes, is well designed for serial processing,
> going one byte at a time and decoding it. Each addressing mode byte
> indicates how many operand bytes it needs, and so where to find the
> next addressing mode byte.
>
> It would have been a very easy change to VAX to put all the address
> mode bytes immediately after the opcode. It is still slightly more
> complicated due to indexed mode, but not all that hard.
> You get all the address mode bytes in parallel, then process any
> index mode bytes, and you know where the next instruction is.
>
> But no, for VAX you process each address mode byte, which tells
> you were the next one is, which then tells where the next one is ...
> Nice for serial microprograms, not for pipelining.
>
> Well, VAX might also be designed to make it easier for assembly
> programming, and especially debugging from core dumps.
> I don't believe that moving the bytes around would have changed
> that much, though.
>
> Seems like the extra bits in the word are not the worst problem.

Maybe the extra silicium in a hypothetical modern VAX CPU
should have been used on cores instead of pipelining.

A VAX 7000 model 800 CPU with 64 cores????

Arne

On 2023-07-31 08:28, terry-...@glaver.org wrote:
> On Thursday, July 27, 2023 at 4:20:25 PM UTC-4, Rich Alderson wrote:
>> The follow-on, codenamed
>> "Jupiter", was supposed to be 2.5x a KL-10, but never got to even 2x in prototype.
>>
>> All of this was going on while the middle management in the VAX world was
>> promoting Bell's "one architecture for everything" dream, pulling personnel and
>> funding from the other product lines, contributing to the delays which were the
>> nominal reason for the cancellation of Jupiter.
>
> The Dolphin (KM-10 or KXF10 at various times) had hopes of being both a
> KL-10 and a VAX: "Dolphin is an advanced computer system based on a new
> generation CPU incorporating Macro Cell Array technology. It is the logical
> successor to the KL-10 based PDP-10/20 system, and may well become the
> high-end VAX system." That seems like an odd idea - the additional 4 bits in
> registers, data paths and main memory would seem to be an unnecessary
> expense in VAX mode.

Well, it floundered anyway.
I suspect for either system, there would have been lots of unneeded bits
required for the other one.

> LCG kept steaming on, full speed ahead, until it ran into an iceberg with the VAX
> 9000. Rumor had it that by then, the number of people in LCG who had been
> there long enough to get a first-pass product out the door had dwindled to a
> very small percentage of the people in the group.
>
> I remember being at a DECUS symposium where LCG had a mostly-empty
> exhibit. I asked "So, what are you people up to, anyway?" and got a behind-
> the-curtain view of a Multi-Chip Unit from an unspecified forthcoming
> product. The packaging was truly bizarre and nothing at all like previous
> DEC designs. It actually looked like something IBM would do.

That's how I would describe the modules in the 9000...

Johnny

On 2023-08-03, Johnny Billquist <bqt@softjar.se> wrote:
> On 2023-07-31 08:28, terry-...@glaver.org wrote:
>>
>> I remember being at a DECUS symposium where LCG had a mostly-empty
>> exhibit. I asked "So, what are you people up to, anyway?" and got a behind-
>> the-curtain view of a Multi-Chip Unit from an unspecified forthcoming
>> product. The packaging was truly bizarre and nothing at all like previous
>> DEC designs. It actually looked like something IBM would do.
>
> That's how I would describe the modules in the 9000...
>

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.

Simon.

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

On 2023-08-03 14:10, Simon Clubley wrote:
> On 2023-08-03, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2023-07-31 08:28, terry-...@glaver.org wrote:
>>>
>>> I remember being at a DECUS symposium where LCG had a mostly-empty
>>> exhibit. I asked "So, what are you people up to, anyway?" and got a behind-
>>> the-curtain view of a Multi-Chip Unit from an unspecified forthcoming
>>> product. The packaging was truly bizarre and nothing at all like previous
>>> DEC designs. It actually looked like something IBM would do.
>>
>> That's how I would describe the modules in the 9000...
>>
>
> 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.

Wan't bits of Prism reused in Alpha? Or am I mixing it up with something
else now?

Anyway, I actually have a block from a 9000 lying around, which is why I
found Terry's description so matching. It's very much how I would
describe the modules in the 9000. Not like anything else I've seen from
DEC, and definitely more in the style of some IBM hardware I've seen.

Sadly, I never got a chance to play with a working 9000. And I don't
expect any still exist today.

Johnny

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.

John

On 8/3/2023 4:13 PM, John Dallman 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.

The POSIX sub system / SFU / WSL 1 is no more.

The OS/2 subsystem is long gone.

But what about the security subsystem?

Arne

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.

Simon.

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

On 2023-08-03 22:13, John Dallman 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.

Well, clearly the "Prism reused in Alpha" is hardware. Alpha is just
hardware, and so was Prism.

The software was called Mica. Which, by the way, sortof reminds me a bit
of Domain/OS from Apollo.

Johnny