6 Aug
2025
6 Aug
'25
2:45 p.m.
40 years ago this year Intel came out with the 80386 – 386 – or i386.
Either seems to be correct. What this meant was a memory address of 4GB,
far beyond what an average computer user would need or want, but was so
much more than previously(8086, 80286); ‘true’ multi-tasking which for the
average computer user didn’t mean all that much; and paging, which made
virtualization possible- experimenters were over-joyed! What all this
contributed to was the end of the classical/vintage-computing era. Whether
this began the time of open-source OS development is debatable!
Happy computing?
Murray 🙂
6 Aug
6 Aug
3:29 p.m.
On Wed, 6 Aug 2025, Murray McCullough via cctalk wrote:
40 years ago this year Intel came out with the 80386 –
386 – or i386.
Either seems to be correct. What this meant was a memory address of 4GB,
far beyond what an average computer user would need or want, but was so
much more than previously(8086, 80286); ‘true’ multi-tasking which for the
average computer user didn’t mean all that much; and paging, which made
virtualization possible- experimenters were over-joyed! What all this
contributed to was the end of the classical/vintage-computing era. Whether
this began the time of open-source OS development is debatable!
Well, the very same year MIPS Computer Systems came up with the R2000, a
classic RISC design, featuring a(n almost) non-interlocked pipeline design
and with the same 4GiB paged virtual addressing capability and memory
protection also giving true multitasking. A processor architecture the
descendants of which live in millions of devices around the world, and
which inspired other architectures such as DEC Alpha or more recently
RISC-V.
Maciej
7 Aug
7 Aug
11:10 a.m.
On Aug 6, 2025, at 6:29 PM, Maciej W. Rozycki via
cctalk <cctalk(a)classiccmp.org> wrote:
I believe the ancestry of Alpha is a bit different, given that it was DEC's third
generation RISC design, after the R&D one-off Titan (1982, see
https://bitsavers.org/pdf/dec/tech_reports/WRL-86-1.pdf) and the canceled PRISM (spring
1985, https://bitsavers.org/pdf/dec/prism/memos/850528_NONVAX.pdf which mentions Titan and
Berkeley but not MIPS as inspiration).
paul
...
Well, the very same year MIPS Computer Systems came up with the R2000, a
classic RISC design, featuring a(n almost) non-interlocked pipeline design
and with the same 4GiB paged virtual addressing capability and memory
protection also giving true multitasking. A processor architecture the
descendants of which live in millions of devices around the world, and
which inspired other architectures such as DEC Alpha or more recently
RISC-V.
3:18 p.m.
On Thu, 7 Aug 2025, Paul Koning wrote:
Well, the similarity of the ISA is striking, unlike with say the ARM or
POWER ISAs, and the timeline and the use of MIPS processors in DEC systems
makes it hard to believe there was no influence. That does not preclude
other inspirations and it's worth noting that a key architectural mistake
was avoided (learnt from?), that is the lack of pipeline interlocking.
Maciej
Well, the very
same year MIPS Computer Systems came up with the R2000, a
classic RISC design, featuring a(n almost) non-interlocked pipeline design
and with the same 4GiB paged virtual addressing capability and memory
protection also giving true multitasking. A processor architecture the
descendants of which live in millions of devices around the world, and
which inspired other architectures such as DEC Alpha or more recently
RISC-V.
I believe the ancestry of Alpha is a bit different, given that it was
DEC's third generation RISC design, after the R&D one-off Titan (1982,
see https://bitsavers.org/pdf/dec/tech_reports/WRL-86-1.pdf) and the
canceled PRISM (spring 1985,
https://bitsavers.org/pdf/dec/prism/memos/850528_NONVAX.pdf which
mentions Titan and Berkeley but not MIPS as inspiration). 
3:52 p.m.
On Thu, 7 Aug 2025 at 23:26, Maciej W. Rozycki via cctalk
<cctalk(a)classiccmp.org> wrote:
On Thu, 7 Aug 2025, Paul Koning wrote:
Well, the similarity of the ISA is striking, unlike with say the ARM or
POWER ISAs, and the timeline and the use of MIPS processors in DEC systems
makes it hard to believe there was no influence. That does not preclude
other inspirations and it's worth noting that a key architectural mistake
was avoided (learnt from?), that is the lack of pipeline interlocking.
Given that DEC shipped their first MIPS based DECstations in 1989, and
PRISM was (I believe) still morphing between 32 bit and 64 bit in that
timescale, it seems very likely that the engineers working on Alpha
were not only aware of MIPS but had direct experience of DEC hardware
and software running on MIPS...
Ancestry... arguable, influence... more than likely :)
David
Well, the
very same year MIPS Computer Systems came up with the R2000, a
classic RISC design, featuring a(n almost) non-interlocked pipeline design
and with the same 4GiB paged virtual addressing capability and memory
protection also giving true multitasking. A processor architecture the
descendants of which live in millions of devices around the world, and
which inspired other architectures such as DEC Alpha or more recently
RISC-V.
I believe the ancestry of Alpha is a bit different, given that it was
DEC's third generation RISC design, after the R&D one-off Titan (1982,
see https://bitsavers.org/pdf/dec/tech_reports/WRL-86-1.pdf) and the
canceled PRISM (spring 1985,
https://bitsavers.org/pdf/dec/prism/memos/850528_NONVAX.pdf which
mentions Titan and Berkeley but not MIPS as inspiration). 
4:41 p.m.
Didn’t Dec buy the MIPS company? So did not develop MIPS internally at all?
Sent from my iPhone
On Aug 7, 2025, at 16:01, David Brownlee via cctalk
<cctalk(a)classiccmp.org> wrote:
On Thu, 7 Aug 2025 at 23:26, Maciej W. Rozycki via cctalk
<cctalk(a)classiccmp.org> wrote:
On Thu, 7 Aug 2025, Paul Koning wrote:
Well, the similarity of the ISA is striking, unlike with say the ARM or
POWER ISAs, and the timeline and the use of MIPS processors in DEC systems
makes it hard to believe there was no influence. That does not preclude
other inspirations and it's worth noting that a key architectural mistake
was avoided (learnt from?), that is the lack of pipeline interlocking.
Given that DEC shipped their first MIPS based DECstations in 1989, and
PRISM was (I believe) still morphing between 32 bit and 64 bit in that
timescale, it seems very likely that the engineers working on Alpha
were not only aware of MIPS but had direct experience of DEC hardware
and software running on MIPS...
Ancestry... arguable, influence... more than likely :)
David
Well, the
very same year MIPS Computer Systems came up with the R2000, a
classic RISC design, featuring a(n almost) non-interlocked pipeline design
and with the same 4GiB paged virtual addressing capability and memory
protection also giving true multitasking. A processor architecture the
descendants of which live in millions of devices around the world, and
which inspired other architectures such as DEC Alpha or more recently
RISC-V.
I believe the ancestry of Alpha is a bit different, given that it was
DEC's third generation RISC design, after the R&D one-off Titan (1982,
see https://bitsavers.org/pdf/dec/tech_reports/WRL-86-1.pdf) and the
canceled PRISM (spring 1985,
https://bitsavers.org/pdf/dec/prism/memos/850528_NONVAX.pdf which
mentions Titan and Berkeley but not MIPS as inspiration).
5:33 p.m.
Didn’t Dec buy the MIPS company?
No, SGI did, since they were the major user at the time.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.com
-- If they give you ruled paper, write the other way. -- Juan Ramon Jimenez ---
5:41 p.m.
On Aug 7, 2025, at 7:41 PM, Wayne S via cctalk
<cctalk(a)classiccmp.org> wrote:
Didn’t Dec buy the MIPS company? So did not develop MIPS internally at all?
No, DEC did not buy MIPS. It bought MIPS chips. And it did develop an very odd in-house
MIPS architecture chip as an R&D exercise, called BIPS, a 1 GHz MIPS chip as a single
ECL VLSI chip. I don't remember if it actually happened; ECL fabs were disappearing
at the time. The CAD machinery for it was fascinating because it allowed for a
full-custom design that would adjust to different fab rules. And a bunch of interesting
work was done for the physical design, such as a chip package with a heat pipe, and
research into the current carrying capacity of gold bond wires (which is amazingly high).
I have a few of the internal reports still saved away; I've never seen a public
document that discusses it. Some memory says that it needed over 100 watts of power,
which at the time was way beyond what anyone else had done. I'd have to dig to find
when this was done; perhaps 1992 or so, definitely at least a year before I left DEC in
1994. I made a suggestion for an unusual die attach scheme when I saw one talk about
this, and about a year later saw the report saying what they had done with the idea. I
think it might have worked but then the project was canceled so the patent was never
filed, too bad -- for a software guy to be named on a die attach patent would have been
fun.
paul
5:45 p.m.
On Aug 7, 2025, at 4:41 PM, Wayne S via cctalk <cctalk(a)classiccmp.org> wrote:
Didn’t Dec buy the MIPS company?
No, DEC didn’t buy MIPS Computer Systems, that was SGI.
So did not develop MIPS internally at all?
That’s correct, MIPS was developed by MIPS Computer Systems.
-- Chris
5:35 p.m.
On Aug 7, 2025, at 6:52 PM, David Brownlee
<abs(a)absd.org> wrote:
On Thu, 7 Aug 2025 at 23:26, Maciej W. Rozycki via cctalk
<cctalk(a)classiccmp.org> wrote:
>
> On Thu, 7 Aug 2025, Paul Koning wrote:
>
>>> Well, the very same year MIPS Computer Systems came up with the R2000, a
>>> classic RISC design, featuring a(n almost) non-interlocked pipeline design
>>> and with the same 4GiB paged virtual addressing capability and memory
>>> protection also giving true multitasking. A processor architecture the
>>> descendants of which live in millions of devices around the world, and
>>> which inspired other architectures such as DEC Alpha or more recently
>>> RISC-V.
>>
>> I believe the ancestry of Alpha is a bit different, given that it was
>> DEC's third generation RISC design, after the R&D one-off Titan (1982,
>> see https://bitsavers.org/pdf/dec/tech_reports/WRL-86-1.pdf) and the
>> canceled PRISM (spring 1985,
>> https://bitsavers.org/pdf/dec/prism/memos/850528_NONVAX.pdf which
>> mentions Titan and Berkeley but not MIPS as inspiration).
>
> Well, the similarity of the ISA is striking, unlike with say the ARM or
> POWER ISAs, and the timeline and the use of MIPS processors in DEC systems
> makes it hard to believe there was no influence. That does not preclude
> other inspirations and it's worth noting that a key architectural mistake
> was avoided (learnt from?), that is the lack of pipeline interlocking.
I don't think of them as all that similar, apart from the inherent similarity of RISC
architectures generally. For example, it avoided the horrors of the delay slot. And it
had some odd decisions, like the initial lack of unaligned load/store and the omission of
the divide instruction.
Given that DEC shipped their first MIPS based
DECstations in 1989, and
PRISM was (I believe) still morphing between 32 bit and 64 bit in that
timescale, it seems very likely that the engineers working on Alpha
were not only aware of MIPS but had direct experience of DEC hardware
and software running on MIPS...
PRISM was cancelled in June 1988, see
https://bitsavers.org/pdf/dec/prism/memos/880617_PRISM_killed.pdf. MIPS was the
replacement at that time. BTW, the PRISM systems overview (1986) lists various
competitors, MIPS is not mentioned.
I'm not sure when Alpha was started. It seems that the may have been a gap where DEC
thought MIPS was enough, but they must have realized it wasn't, or wanted to control
their own destiny, I don't really know. I was never close to that project. FWIW, on
Bitsavers there is the Rev 2 Alpha Calling Standard document, and the revision history
shows the original rev 0.1 draft was from June 1989, i.e., 3 years after PRISM was
cancelled. So while undoubtedly a lot of the Alpha people knew PRISM, there doesn't
appear to be a direct line from one project to the next.
paul
5:47 p.m.
So while undoubtedly a lot of the Alpha people knew
PRISM, there doesn't
appear to be a direct line from one project to the next.
Though I do remember the old joke that AXP stood for "Almost eXactly PRISM."
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.com
-- Friends help you move. Real friends help you move bodies. ------------------
8 Aug
8 Aug
9:54 a.m.
On Thu, 7 Aug 2025, Paul Koning wrote:
Pipeline interlocks removed delay slots; by that time the MIPS ISA got
rid of some of them already as well, as people quickly realised they were
not the best idea (the most recent MIPS ISA revision is I believe fully
interlocked). Then MIPS unaligned memory access instructions (LWL/LWR,
SWL/SWR, etc.) were covered by a patent, so naturally DEC wanted to avoid
them and came up with a different approach. There was also the notable
lack of byte and word memory access instructions in the initial ISA. I
find all these minor ISA design decisions though.
The key concepts clearly borrowed from the MIPS ISA were: a hardwired
zero register and the dependency on that for the completeness of the ALU
operations provided, the lack of condition codes and the use of general
registers instead for conditional branches, and the overall feel of the
instruction set, including but not limited to the 6-bit major opcode
encoded in bits 31:26 of the instruction word and the placement of the
5-bit register operand fields.
Maciej
>> I
believe the ancestry of Alpha is a bit different, given that it was
>> DEC's third generation RISC design, after the R&D one-off Titan (1982,
>> see https://bitsavers.org/pdf/dec/tech_reports/WRL-86-1.pdf) and the
>> canceled PRISM (spring 1985,
>> https://bitsavers.org/pdf/dec/prism/memos/850528_NONVAX.pdf which
>> mentions Titan and Berkeley but not MIPS as inspiration).
>
> Well, the similarity of the ISA is striking, unlike with say the ARM or
> POWER ISAs, and the timeline and the use of MIPS processors in DEC systems
> makes it hard to believe there was no influence. That does not preclude
> other inspirations and it's worth noting that a key architectural mistake
> was avoided (learnt from?), that is the lack of pipeline interlocking.
I don't think of them as all that similar, apart from the inherent
similarity of RISC architectures generally. For example, it avoided the
horrors of the delay slot. And it had some odd decisions, like the
initial lack of unaligned load/store and the omission of the divide
instruction.
10:21 a.m.
On Aug 8, 2025, at 12:54 PM, Maciej W. Rozycki
<macro(a)orcam.me.uk> wrote:
On Thu, 7 Aug 2025, Paul Koning wrote:
All of those (except for the precise opcode field widths) go back to the CDC 6600, which
though not often called that clearly deserves to be seen as an early, probably the first,
RISC architecture.
paul
>>> ...
The key concepts clearly borrowed from the MIPS ISA were: a hardwired
zero register and the dependency on that for the completeness of the ALU
operations provided, the lack of condition codes and the use of general
registers instead for conditional branches, and the overall feel of the
instruction set, including but not limited to the 6-bit major opcode
encoded in bits 31:26 of the instruction word and the placement of the
5-bit register operand fields. 
10:30 a.m.
On 2025-08-08 10:54 a.m., Maciej W. Rozycki via cctalk wrote:
On Thu, 7 Aug 2025, Paul Koning wrote:
The key concepts clearly borrowed from the MIPS ISA
were: a hardwired
zero register and the dependency on that for the completeness of the ALU
operations provided, the lack of condition codes and the use of general
registers instead for conditional branches..
Funny how most classic computers, did the same thing.
It was called skip on condition.
With out the advance of large fast paged DRAM's RISC would
never got out the Door.
Maciej
Why does it seem we have new RISC
version every other monthand the INTEL
X86 err PDP8 keeps going and going. :)
10:52 a.m.
On Aug 8, 2025, at 1:30 PM, ben via cctalk
<cctalk(a)classiccmp.org> wrote:
On 2025-08-08 10:54 a.m., Maciej W. Rozycki via cctalk wrote:
The same thing as branch on register? Nope, "skip on condition" is a flavor of
condition code branch. The RISC argument against condition codes, and why Cray didn't
use them in the 6600, is that they are an instruction side effect that has to be
interlocked along with the "real" result. And it's a global state, so it
introduces unwanted serialization.
For example, in a 6600 (or a MIPS or an Alpha), you can have an add into R3 executing
concurrently with a multiply into R4, with no output conflicts. If you add condition
codes to the architecture, those are a second output and the two operations now conflict.
Another advantage is that you can conditionally branch on a result from some number of
instructions ago, while instructions in between are still finishing up. No need to drain
the pipeline. Of course there are other ways to do the "some instructions ago"
thing, by having condition codes that are set only if an instruction option says to do so.
The Electrologica machines (X1, from 1958, and the successor X8) have that feature, making
them similar to ARM but more flexible.
On Thu, 7 Aug 2025, Paul Koning wrote:
The key concepts clearly borrowed from the MIPS
ISA were: a hardwired
zero register and the dependency on that for the completeness of the ALU
operations provided, the lack of condition codes and the use of general
registers instead for conditional branches..
Funny how most classic computers, did the same thing.
It was called skip on condition. With out the advance of large fast paged DRAM's
RISC would
never got out the Door.
The 6600 max memory was 128k 60-bit words, which for those days was admittedly quite
large. No VM, though it did support relocation (base address and field length, similar to
the DEC KA10). Large RAM is nice but I don't see what it has to do with RISC.
paul
11:14 a.m.
On 2025-08-08 11:52 a.m., Paul Koning wrote:
The 6600 max memory was 128k 60-bit words, which for
those days was admittedly quite large. No VM, though it did support relocation (base
address and field length, similar to the DEC KA10). Large RAM is nice but I don't see
what it has to do with RISC.
It was DRAM in SIMM packaging, that let you have a fast
memory bus off
the cpu chip set.
paul
1:23 p.m.
On Aug 8, 2025, at 2:14 PM, ben
<bfranchuk(a)jetnet.ab.ca> wrote:
On 2025-08-08 11:52 a.m., Paul Koning wrote:
You should spend some time looking at old machine architectures, because what you say is
very 21st century centric. An excellent intro is "Design of a computer - the
Control Data 6600" by J. E. Thornton. Available on Bitsavers
https://bitsavers.org/pdf/cdc/cyber/books/DesignOfAComputer_CDC6600.pdf or you can get the
hardcover printed book.
It's a great machine to study because it does an amazing job of matching up parts of
the design to wring the most performance out of the available components. To pick one
example: the primary clock period is 100 ns, and most operations take only a few cycles.
A new instruction can start every 100 ns, best case. The memory system is designed so it
can push data around at that speed. Process context switch requires 16 word read/write
operations, and that process is skillfully pipelined so it normally runs in 16 consecutive
cycles, spread over the memory banks (16 banks in the minimal system, 32 in the full
memory config). And so on.
It doesn't require SIMMs or a "cpu chip set" to go fast.
paul
The 6600 max memory was 128k 60-bit words, which
for those days was admittedly quite large. No VM, though it did support relocation (base
address and field length, similar to the DEC KA10). Large RAM is nice but I don't see
what it has to do with RISC.
It was DRAM in SIMM packaging, that let you have a
fast memory bus off the cpu chip set.
2:26 p.m.
On 2025-08-08 2:23 p.m., Paul Koning wrote:
I need to read that.
I like IBM's book, on the 7030,
and Bell's Books,on the PDP computers.
Three totaly different views, on computing.
On Aug 8, 2025, at 2:14 PM, ben
<bfranchuk(a)jetnet.ab.ca> wrote:
On 2025-08-08 11:52 a.m., Paul Koning wrote:
You should spend some time looking at old machine architectures, because what you say is
very 21st century centric. An excellent intro is "Design of a computer - the
Control Data 6600" by J. E. Thornton. Available on Bitsavers
https://bitsavers.org/pdf/cdc/cyber/books/DesignOfAComputer_CDC6600.pdf or you can get the
hardcover printed book.
The 6600 max memory was 128k 60-bit words, which
for those days was admittedly quite large. No VM, though it did support relocation (base
address and field length, similar to the DEC KA10). Large RAM is nice but I don't see
what it has to do with RISC.
It was DRAM in SIMM packaging, that let you have a
fast memory bus off the cpu chip set. It's a great machine to study because it does an
amazing job of matching up parts of the design to wring the most performance out of the
available components. To pick one example: the primary clock period is 100 ns, and most
operations take only a few cycles. A new instruction can start every 100 ns, best case.
The memory system is designed so it can push data around at that speed. Process context
switch requires 16 word read/write operations, and that process is skillfully pipelined so
it normally runs in 16 consecutive cycles, spread over the memory banks (16 banks in the
minimal system, 32 in the full memory config). And so on.
It doesn't require SIMMs or a "cpu chip set" to go fast.
paul
All I can say is both RISC and SIMMs came about all at the same
time.That was when you had a mess of 86's, 286's,386, 16 and 32 bit
buses and optional math co-processors.
At my end of the world I was lucky to have a AT clone at that time,
since I spent my money on a COCO III.( OS/9 level II).
Gone in to TTL/PAL/CPLD home brewing for 18 bits of pure
fun/joy/headbanging. Now I am spending all my money on PCB's that don't
work, after the first few minutes.Heat? Noise? Bus? Bad CPLD routing? 5V
wall wart?Poor bypassing. Are there any tricks to using ATF1508's.
Ben.
9 Aug
9 Aug
1:14 p.m.
On Aug 8, 2025, at 5:26 PM, ben
<bfranchuk(a)jetnet.ab.ca> wrote:
On 2025-08-08 2:23 p.m., Paul Koning wrote:
I need to read that.
I like IBM's book, on the 7030,
and Bell's Books,on the PDP computers.
Three totaly different views, on computing.
I'm not sure which Bell book you mean, but there's Bell and Newell which is a
broad survey of computer architectures. One of the few square books I have ever seen.
paul
On Aug 8,
2025, at 2:14 PM, ben <bfranchuk(a)jetnet.ab.ca> wrote:
On 2025-08-08 11:52 a.m., Paul Koning wrote:
You should spend some time looking at old
machine architectures, because what you say is very 21st century centric. An excellent
intro is "Design of a computer - the Control Data 6600" by J. E. Thornton.
Available on Bitsavers
https://bitsavers.org/pdf/cdc/cyber/books/DesignOfAComputer_CDC6600.pdf or you can get the
hardcover printed book. The 6600 max memory was 128k 60-bit words, which
for those days was admittedly quite large. No VM, though it did support relocation (base
address and field length, similar to the DEC KA10). Large RAM is nice but I don't see
what it has to do with RISC.
It was DRAM in SIMM packaging, that let you have a
fast memory bus off the cpu chip set. 
4:23 p.m.
On 8/9/2025 4:14 PM, Paul Koning via cctalk wrote:
I suspect this might be what he means: "Computer Engineering: A DEC
View of Hardware Systems Design" by Gordon Bell
I still have it on my bookshelf.
bill
On Aug 8, 2025, at 5:26 PM, ben
<bfranchuk(a)jetnet.ab.ca> wrote:
On 2025-08-08 2:23 p.m., Paul Koning wrote:
I need to read that.
I like IBM's book, on the 7030,
and Bell's Books,on the PDP computers.
Three totaly different views, on computing.
I'm not sure which Bell book you mean, but there's Bell and Newell which is a
broad survey of computer architectures. One of the few square books I have ever seen.
On Aug 8,
2025, at 2:14 PM, ben <bfranchuk(a)jetnet.ab.ca> wrote:
On 2025-08-08 11:52 a.m., Paul Koning wrote:
> The 6600 max memory was 128k 60-bit words, which for those days was admittedly quite
large. No VM, though it did support relocation (base address and field length, similar to
the DEC KA10). Large RAM is nice but I don't see what it has to do with RISC.
It was DRAM in SIMM packaging, that let you have a fast memory bus off the cpu chip set.
You should spend some time looking at old machine architectures, because what you
say is very 21st century centric. An excellent intro is "Design of a computer - the
Control Data 6600" by J. E. Thornton. Available on Bitsavers
https://bitsavers.org/pdf/cdc/cyber/books/DesignOfAComputer_CDC6600.pdf or you can get the
hardcover printed book. 
8 Aug
8 Aug
11:20 a.m.
SIMD micro architectures use conditional execution at the mill (or pair of mills for
complex operands) level. This removes the program sequencer and global condition codes
from consideration, only the mill's "local condition" controls arithmetic
operation. The technique appeared in ~2nd generation DSP chips in the late 80's and
became common when they embraced multi core / multi mill architectures, I presume it has
the merit of not "breaking" the pipelining. It can now be found in R and A
series Arm cores. I imagine there are anteceedents prior to its use in the DSP 56300 and
Sharc processors. The ordinal instruction is IFcc, where the specific operation and cc
are also specified in the instruction encoding and conditional execution is local to each
mill (or pair).
Martin
-----Original Message-----
From: Paul Koning via cctalk [mailto:cctalk@classiccmp.org]
Sent: 08 August 2025 17:52
To: cctalk(a)classiccmp.org
Cc: Paul Koning <paulkoning(a)comcast.net>
Subject: [cctalk] Re: 80386 - 1985
On Aug 8, 2025, at 1:30 PM, ben via cctalk
<cctalk(a)classiccmp.org> wrote:
On 2025-08-08 10:54 a.m., Maciej W. Rozycki via cctalk wrote:
The same thing as branch on register? Nope, "skip on condition" is a flavor of
condition code branch. The RISC argument against condition codes, and why Cray didn't
use them in the 6600, is that they are an instruction side effect that has to be
interlocked along with the "real" result. And it's a global state, so it
introduces unwanted serialization.
For example, in a 6600 (or a MIPS or an Alpha), you can have an add into R3 executing
concurrently with a multiply into R4, with no output conflicts. If you add condition
codes to the architecture, those are a second output and the two operations now conflict.
Another advantage is that you can conditionally branch on a result from some number of
instructions ago, while instructions in between are still finishing up. No need to drain
the pipeline. Of course there are other ways to do the "some instructions ago"
thing, by having condition codes that are set only if an instruction option says to do so.
The Electrologica machines (X1, from 1958, and the successor X8) have that feature, making
them similar to ARM but more flexible.
On Thu, 7 Aug 2025, Paul Koning wrote:
The key concepts clearly borrowed from the MIPS
ISA were: a
hardwired zero register and the dependency on that for the
completeness of the ALU operations provided, the lack of condition
codes and the use of general registers instead for conditional branches..
Funny how most classic computers, did the same thing.
It was called skip on condition.
With out the advance of large fast paged DRAM's
RISC would never got
out the Door.
The 6600 max memory was 128k 60-bit words, which for those days was admittedly quite
large. No VM, though it did support relocation (base address and field length, similar to
the DEC KA10). Large RAM is nice but I don't see what it has to do with RISC.
paul
1:48 p.m.
Of course there are other ways to do the "some
instructions ago" thing,
by having condition codes that are set only if an instruction option
says to do so. The Electrologica machines (X1, from 1958, and the
successor X8) have that feature, making them similar to ARM but more
flexible.
And then there's Power ISA, which has multiple condition fields that can be
separately predicated against, and you only need set them when you want to with
the record bit (for those instructions that allow it), plus more typical global
ones (XER, FPSCR, etc.).
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.com
-- May the forces of evil become confused on the way to your house. - G. Carlin
6 Aug
6 Aug
5:36 p.m.
On Wed, Aug 06, 2025 at 05:45:12PM -0400, Murray McCullough via cctalk wrote:
40 years ago this year Intel came out with the 80386 –
386 – or i386.
Also iAPX 386, a name that nobody but Intel's marketing department paid any
attention to.
Either seems to be correct. What this meant was a
memory address of 4GB,
far beyond what an average computer user would need or want, but was so
much more than previously(8086, 80286); ‘true’ multi-tasking which for the
average computer user didn’t mean all that much; and paging, which made
virtualization possible- experimenters were over-joyed!
The 80286 introduced protected mode, which is sufficient to implement a
proper operating system, since protected mode enables sandboxing user
processes in a virtual memory environment. We know this because Andrew
Tanenbaum did just that: MINIX 2 will run on your old 286 and give you
something broadly resembling mid-1980s Unix.
Unfortunately, putting the 286 into protected mode cratered performance as
it would then need to reload the base-and-bounds from memory every time a
segment register was reloaded. Since the 286 basically only had two
general-purpose segment registers, these reloads were extremely common.
Also, real-mode code cannot be reliably made to run in 286 protected mode.
so not only is multitasking noticably slower even when running just one
program, but if that one program you want to run is for MS-DOS, it's not
going to run at all.
6:26 p.m.
On Thu, 7 Aug 2025, Peter Corlett via cctalk wrote:
The 80286 introduced protected mode, which is
sufficient to implement a
proper operating system, since protected mode enables sandboxing user
processes in a virtual memory environment. We know this because Andrew
Tanenbaum did just that: MINIX 2 will run on your old 286 and give you
something broadly resembling mid-1980s Unix.
Bill Gates called the 80286 "brain dead".
But, who was it who said that switching back to real mode "is like having
to shut off the engine to change gears"?
--
Grumpy Ol' Fred
9 Aug
9 Aug
4:42 a.m.
On Wed, Aug 06, 2025 at 06:26:44PM -0700, Fred Cisin via cctalk wrote:
On Thu, 7 Aug 2025, Peter Corlett via cctalk wrote:
> The 80286 introduced protected mode, which is sufficient to implement a
> proper operating system, since protected mode enables sandboxing user
> processes in a virtual memory environment. We know this because Andrew
> Tanenbaum did just that: MINIX 2 will run on your old 286 and give you
> something broadly resembling mid-1980s Unix.
Bill Gates called the 80286 "brain dead".
I have no love for the x86 architecture, but note that the 80286 did succeed
at what we can safely assume was the design brief: improve on the 8086, and
add a protected mode. That it's not a very efficient protected mode is an
rather unfortunate design mis-step which still dogs x86 to this day, but if
you pretend that feature doesn't exist and leave the CPU in real mode than
you get a very welcome performance boost.
I would perhaps go further and note that it delivered a technically useful
protected mode in 1982, before my personal favourite architecture of that
era, m68k. The MC68451 external MMU *added* base-and-bounds segmentation to
m68k which seems to date from 1983 (in as much as the oldest datasheet is
from April 1983) and of course ideally also needed to be paired with at
least the 68010 rather than the 68000 which couldn't restart instructions.
That we forget the MC68451 exists shows what a dead-end base-and-bounds was
even back then.
Wikipedia claims the following, which explains Gates' attitude: 'Bill Gates
referred to the 80286 as a "brain-damaged" chip, because it cannot use
virtual machines to multitask multiple MS-DOS applications[22] with an
operating system like Microsoft Windows.' In other words, he didn't like it
because it didn't provide a feature that he wanted for Microsoft. Well,
tough, you should have been working with Intel instead of just freeloading.
I mean, look at the complexity with base-and-bounds, rings, and all that
other arcane stuff which looks like mainframes rather than microprocessors.
Protected mode was clearly designed with IBM rather than Microsoft in mind.
But, who was it who said that switching back to real
mode "is like having
to shut off the engine to change gears"?
That was partly a mis-step, but again it was understandable when you
consider who the actual customer was. Look at PC operating systems today,
and you'll see that they switch into long mode in early startup and stay
there until reboot.
6:43 a.m.
On 2025-08-09 5:42 a.m., Peter Corlett via cctalk wrote:
I have no love for the x86 architecture, but note that the 80286 did succeed
at what we can safely assume was the design brief: improve on the 8086, and
add a protected mode. That it's not a very efficient protected mode is an
rather unfortunate design mis-step which still dogs x86 to this day, but if
you pretend that feature doesn't exist and leave the CPU in real mode than
you get a very welcome performance boost.
I would perhaps go further and note that it delivered a technically useful
protected mode in 1982, before my personal favourite architecture of that
era, m68k. The MC68451 external MMU *added* base-and-bounds segmentation to
m68k which seems to date from 1983 (in as much as the oldest datasheet is
from April 1983) and of course ideally also needed to be paired with at
least the 68010 rather than the 68000 which couldn't restart instructions.
That we forget the MC68451 exists shows what a dead-end base-and-bounds was
even back then.
Wikipedia claims the following, which explains Gates' attitude: 'Bill Gates
referred to the 80286 as a "brain-damaged" chip, because it cannot use
virtual machines to multitask multiple MS-DOS applications[22] with an
operating system like Microsoft Windows.' In other words, he didn't like it
because it didn't provide a feature that he wanted for Microsoft. Well,
tough, you should have been working with Intel instead of just freeloading.
I mean, look at the complexity with base-and-bounds, rings, and all that
other arcane stuff which looks like mainframes rather than microprocessors.
Protected mode was clearly designed with IBM rather than Microsoft in mind.
The 8086 and 8088 was stopgap measure, while Intel worked on the BIG
cpu, iAPX 432. I suspect that chip design had major impact on how
segments and segment registers where thought of in computer architecture
up to the 286.
Ben.
2:31 p.m.
On 8/9/25 06:43, ben via cctalk wrote:
On 2025-08-09 5:42 a.m., Peter Corlett via cctalk
wrote:
>
> I have no love for the x86 architecture, but note that the 80286 did
> succeed
> at what we can safely assume was the design brief: improve on the
> 8086, and
> add a protected mode. That it's not a very efficient protected mode
> is an
> rather unfortunate design mis-step which still dogs x86 to this day,
> but if
> you pretend that feature doesn't exist and leave the CPU in real mode
> than
> you get a very welcome performance boost.
>
> I would perhaps go further and note that it delivered a technically
> useful
> protected mode in 1982, before my personal favourite architecture of
> that
> era, m68k. The MC68451 external MMU *added* base-and-bounds
> segmentation to
> m68k which seems to date from 1983 (in as much as the oldest
> datasheet is
> from April 1983) and of course ideally also needed to be paired with at
> least the 68010 rather than the 68000 which couldn't restart
> instructions.
> That we forget the MC68451 exists shows what a dead-end
> base-and-bounds was
> even back then.
>
> Wikipedia claims the following, which explains Gates' attitude: 'Bill
> Gates
> referred to the 80286 as a "brain-damaged" chip, because it cannot use
> virtual machines to multitask multiple MS-DOS applications[22] with an
> operating system like Microsoft Windows.' In other words, he didn't
> like it
> because it didn't provide a feature that he wanted for Microsoft. Well,
> tough, you should have been working with Intel instead of just
> freeloading.
>
> I mean, look at the complexity with base-and-bounds, rings, and all that
> other arcane stuff which looks like mainframes rather than
> microprocessors.
> Protected mode was clearly designed with IBM rather than Microsoft in
> mind.
I believe most folks disliked the segmentation scheme because they
wanted stuff to look like a VAX. I have used segments in a number of
OS's and they provided distinct advantages in speed (doing cross address
space copies can be incredibly fast if you set up a segment each for
source and destination...no need for bounds checking during the
copy...if the copy exceeds the bounds you'll get a fault...so you're in
a error path anyway...this is opposed to checking bounds during the copy
in software) and security. A lot of the security exploits in today's
OS's can be mitigated if not out right eliminated by using call gates
and related features. But of course, AMD when designing the x86-64
instruction set architecture eliminated segments. I find it ironic that
to eliminate various security exploits, mechanisms are being
re-introduced piecemeal that would have been implemented in a much
better way (and more general) if they had just retained segments. :-/
The 8086 and 8088 was stopgap measure, while Intel worked on the BIG
cpu, iAPX 432. I suspect that chip design had major impact on how
segments and segment registers where thought of in computer
architecture up to the 286.
Absolutely it did. The '286 was a way for Intel to recoup some of the
work on the 432. Intel's mistake on the '286 was that they expected
everyone to switch to protected mode and only use real mode as a means
to boot up (which x86 still requires...gack).
--
TTFN - Guy
6 Aug
6 Aug
7:04 p.m.
And the Motorola 68020 was introduced a year earlier, providing an implementation of the
32-bit 68000 architecture with full 32-bit address and data busses and a 32-bit ALU.
The original 68000 from 1979 and its follow-on, the 68010, were architecturally 32-bit but
used a 16-bit external data bus and 24-bit external address bus and 16-bit ALU to
implement the architecture—while the 68008 provided a 68000 with an 8-bit external data
bus and 20-bit external address bus in a smaller package, and the 68012 provided a 68010
with a 31-bit external address bus in a larger PGA package that was pin-compatible with
the 68010. (That is, a PGA socket could accommodate either a 68010 or a 68012, with the
latter supporting a larger physical address space.)
-- Chris
7 Aug
7 Aug
2:44 p.m.
AFAIK the 68000 and 68010 were also available in a pin-compatible package,
as in the Cromemco XPU.
On Wed, Aug 6, 2025 at 10:26 PM Chris Hanson via cctalk <
cctalk(a)classiccmp.org> wrote:
And the Motorola 68020 was introduced a year earlier,
providing an
implementation of the 32-bit 68000 architecture with full 32-bit address
and data busses and a 32-bit ALU.
The original 68000 from 1979 and its follow-on, the 68010, were
architecturally 32-bit but used a 16-bit external data bus and 24-bit
external address bus and 16-bit ALU to implement the architecture—while the
68008 provided a 68000 with an 8-bit external data bus and 20-bit external
address bus in a smaller package, and the 68012 provided a 68010 with a
31-bit external address bus in a larger PGA package that was pin-compatible
with the 68010. (That is, a PGA socket could accommodate either a 68010 or
a 68012, with the latter supporting a larger physical address space.)
-- Chris
2:59 p.m.
On Aug 7, 2025, at 2:44 PM, Mike Stein <mhs.stein(a)gmail.com> wrote:
AFAIK the 68000 and 68010 were also available in a pin-compatible package, as in the
Cromemco XPU.
Yeah, the 68010 was essentially a "minor" revision of the 68000, and shared the
same pinout in all packages.
It was really a "more than minor, less than major" revison: The 68010 did change
exception stack frame layout and added a register and a couple supervisor-only
instructions to meet Popek & Goldberg virtualization requirements, added the
two-instruction loop cache, and added a signal that indicates a read-modify-write cycle is
taking plce for multi-processor support (which was only actually brought out to a pin on
the 68012, like the additional 7 address lines).
Virtually everything else like instruction timings were unchanged from the 68000, so it
could be used as a drop-in replacement with only minimal changes to supervisor-mode code.
-- Chris
5:43 p.m.
On Aug 7, 2025, at 5:59 PM, Chris Hanson via cctalk
<cctalk(a)classiccmp.org> wrote:
On Aug 7, 2025, at 2:44 PM, Mike Stein <mhs.stein(a)gmail.com> wrote:
A very important enhancement in the 68010 is that you could take a page fault and handle
it in a way that allowed virtual memory systems. Apollo Computer built some of the first
workstation products, with VM, using a pair of 68000s running in lockstep, to make page
faults work with a chip that didn't handle it right.
paul
AFAIK the 68000 and 68010 were also available in a pin-compatible package, as in the
Cromemco XPU.
Yeah, the 68010 was essentially a "minor" revision of the 68000, and shared the
same pinout in all packages.
It was really a "more than minor, less than major" revison: The 68010 did
change exception stack frame layout and added a register and a couple supervisor-only
instructions to meet Popek & Goldberg virtualization requirements, added the
two-instruction loop cache, and added a signal that indicates a read-modify-write cycle is
taking plce for multi-processor support (which was only actually brought out to a pin on
the 68012, like the additional 7 address lines).
5:51 p.m.
On Aug 7, 2025, at 5:43 PM, Paul Koning <paulkoning(a)comcast.net> wrote:
A very important enhancement in the 68010 is that you could take a page fault and handle
it in a way that allowed virtual memory systems. Apollo Computer built some of the first
workstation products, with VM, using a pair of 68000s running in lockstep, to make page
faults work with a chip that didn't handle it right.
That’s why I said:
> The 68010 did change exception stack frame layout
and added a register and a couple supervisor-only instructions to meet Popek &
Goldberg virtualization requirements
All instructions need to be restartable to meet the Popek & Goldberg requirements,
whether they trap due to a privilege violation or a bus error. Memory is just one of the
things that can be virtualized once a system meeds the requirements.
-- Chris
20 Aug
20 Aug
8:08 a.m.
Minor nit...the DIP48 package 68008 has 20 address pins, but the PLCC
package has 22.
KJ
On Wed, Aug 6, 2025 at 10:26 PM Chris Hanson via cctalk <
cctalk(a)classiccmp.org> wrote:
And the Motorola 68020 was introduced a year earlier,
providing an
implementation of the 32-bit 68000 architecture with full 32-bit address
and data busses and a 32-bit ALU.
The original 68000 from 1979 and its follow-on, the 68010, were
architecturally 32-bit but used a 16-bit external data bus and 24-bit
external address bus and 16-bit ALU to implement the architecture—while the
68008 provided a 68000 with an 8-bit external data bus and 20-bit external
address bus in a smaller package, and the 68012 provided a 68010 with a
31-bit external address bus in a larger PGA package that was pin-compatible
with the 68010. (That is, a PGA socket could accommodate either a 68010 or
a 68012, with the latter supporting a larger physical address space.)
-- Chris
26
days inactive
40
days old
32 comments
15 participants
participants (15)
-
ben -
Bill Gunshannon -
Cameron Kaiser -
Chris Hanson -
David Brownlee -
Fred Cisin -
Guy Sotomayor -
Ken Seefried -
Maciej W. Rozycki -
Martin Bishop -
Mike Stein -
Murray McCullough -
Paul Koning -
Peter Corlett -
Wayne S