6 May
2021
6 May
'21
9:53 p.m.
From: Liam Proven <lproven at gmail.com>
To: "Discussion: On-Topic and Off-Topic
Posts" <cctalk at classiccmp.org>
Subject: Re: Motor generator
I think because for lesser minds, such as mine, [APL is] line noise.
A friend of mine, a Perl guru, studied A-Plus for a while. (Morgan
Stanley's in-house APL dialect.) He said to me that "when I came back
to Perl, I found it irritatingly verbose..." and then was immediately
deeply shocked at the thought.
I seriously think this is why Lisp didn't go mainstream. For a certain
type of human mind, it's wonderful and clear and expressive, but for
most of us, it's just a step too far.
Ditto Forth, ditto Postscript, etc.
Plain old algebraic infix notation has thrived for half a millennium
because it's easily assimilated and comprehended, and many arguably
better notations just are not.
The importance of being easy, as opposed to being clear, or
unambiguous, or expressive, etc., is widely underestimated.
Yes, that. C is a great assembly language preprocessor for a PDP-11. The
PDP-11 is a beautiful, intelligible architecture, where things happen one
at a time in sequence. This is easy to think about. Unfortunately it's
got very little to do with the way that modern high-performance silicon
gets stuff done.
(Aside: it's also weird that the one-thing-at-a-time sequencing is the
thing that feels logical and intuitive to us since it is absolutely not how
our brains work.)
I would argue that Forth and Postscript are hard to understand for a
different reason than APL: APL is inherently vectorized, and requires, more
or less, that you treat matrices as single entities. Not many people's
brains work that way. It's hard enough to learn to treat complex numbers
as single entities. Forth and Postscript require you to keep a really deep
stack in your brain to understand the code, and people aren't really very
good at doing that for more than three or four items (much fewer than 7 +/-
2). Both of these are much more difficult for most people to work with and
reason about than something imperative and infix-based.
The fundamental problem is the impedance mismatch between the way most
people think (which would at the very least take a radical reframing of
curricula to change, and might not work anyway: look at the failure of the
New Math, which was indeed very elegant, taught mathematics from first
principles as set theory, and was not at all geared to the way young
children _actually learn things_) and where we can continue to squeeze
performance out of silicon. This is really not tractable. I think our
best hope is to make the silicon really good at generating and figuring out
graphs so it can dispatch lots of pieces of what feels like a sequential
problem in parallel and come out with the same answer as you would have
gotten doing it the naive one-step-at-a-time way. But we've already done
that, and, yeah, it mostly works, but the abstraction is leaky and then you
get Meltdown and Spectre.
I don't have any answers other than "move to Montana, drop off the grid,
and raise dental floss."
Adam
7 May
7 May
12:43 a.m.
On May 6, 2021, at 5:53 PM, Adam Thornton via cctalk
<cctalk at classiccmp.org> wrote:
Sort of. But while a lot of things happen in parallel, out of order, speculatively, etc.,
the programming model exposed by the hardware still is the C sequential model. A whole
lot of logic is needed to create that appearance, and in fact you can see that all the way
back in the CDC 6600 "scoreboard" and "stunt box". Some processors
occasionally relax the software-visible order, which tends to cause bugs, create marketing
issues, or both -- Alpha comes to mind as an example.
...
Yes, that. C is a great assembly
language preprocessor for a PDP-11. The
PDP-11 is a beautiful, intelligible architecture, where things happen one
at a time in sequence. This is easy to think about. Unfortunately it's
got very little to do with the way that modern high-performance silicon
gets stuff done. (Aside: it's also weird that the
one-thing-at-a-time sequencing is the
thing that feels logical and intuitive to us since it is absolutely not how
our brains work.)
I would argue that Forth and Postscript are hard to understand for a
different reason than APL: APL is inherently vectorized, and requires, more
or less, that you treat matrices as single entities. Not many people's
brains work that way.
I wonder. Consider object oriented programming, where objects that have all manner of
stuff inside are treated as a unit and have operations performed on them.
Agreed on stack languages. While there's nothing inherently hard about them, they
don't fit the way we're taught to handle formulas all the way from grade one. In
fact, while APL is infix, it's right-associative, which is a definite problem.
It's unfortunate Iverson didn't fix the assignment operator problem the way POP-2
did, by pointing it to the right so all operators could be left-associative.
If Martin Rem's associons ever take off (see my previous email) that will require a
similar mental process as the one for APL of treating composite data as single entities.
paul
2:35 a.m.
New subject: Pipelining and Dec Jupiter thoughts....
Sort of. But while a lot of things happen in
parallel, out of order, speculatively, etc., the programming model exposed by the hardware
still is the C sequential model. A whole lot of logic is needed to create that
appearance, and in fact you can see that all the way back in the CDC 6600
"scoreboard" and "stunt box". Some processors occasionally relax the
software-visible order, which tends to cause bugs, create marketing issues, or both --
Alpha comes to mind as an example.
Interesting to see this.
I've been reading a lot recently about the Jupiter/Dolphin project and
the more I read the more I understand why it just could not be done. At
the time (and to an extent even now) the only way to really improve a
system's performance was to pipeline the processor, and the Pdp10
instruction set just wasn't easy to do that with.
They had a great concept: An Instruction fetch/decode system (IBOX), an
execution engine (EBOX), the obligitory vector processor or FPU (HBOX)
and of course the memory system (MBOX). Break the process up into steps
and have the parts all work in parallel to boost performance.
Unfortunately they started to find way too many cases where an indirect
instruction would be fetched that would be based on the AC, which was
being changed by another instruction in the EBOX. This would blow out
all the prefetched work in the pipe, forcing the IBOX to do a costly
reload.
Likewise branch prediction couldn't be done well because most branches
and skips depended on the value in the AC which was once again usually
being modified in the EBOX down the pipe. As soon as it was modified the
pipe had to be flushed and reloaded. It looks like they tried to put
that logic into the IBOX to catch these issues, but that resulted in a
flat processor that wasn't going to benefit from any parallelism, an
endless series of bugs, and an IBOX that was pretty much running with
its own EBOX.
It got worse when they realized that the Extended memory segments in the
2060 architecture totally wrecked the concept of an instruction
decoder/execution box. There were just too many places where an indirect
instruction to another section which was then based on the AC's would
result in Ibox tossing the queue and invalidating the translation
buffers. Increasing the translation buffer helped (I think that's one of
the things they did on the final 2065 to make it faster) but they
couldn't make that big and fast enough. I guess an indirect jump
instruction based on comparing the AC to an indirect address pointing to
an extended segment would be enough to make any decoder just cry.
It's sad to read, you can almost see then realizing it was doomed. The
Foonly F1 was a screamer, but it was basically the KA10 instruction set
and couldn't run extended memory segments like the 2060. And when they
tried to do the same thing with the F4 it came out to be a little slower
than a 2060. I used to think they put only one extended segment in the
2020 to cripple the box, but maybe they started running into the same
problem and ran out of microcode space to try and address it.
Couple this with the fact that much of the 20 series programs were built
in assembler (and why not, it was an amazing thing to program) and you
just had too many programs with cool bespoke code that would totally
trash a pipeline. Fixing compilers to order instructions properly could
have worked, but people just wrote in assembler it wasn't going to
happen and they weren't about to re-code their app to please the new
scheduler God.
The VAX instruction set was a lot less beautiful, but could be pipelined
easier especially with the dedicated MMU so they took the people and
pipelined the hell out of the 780 resulting in the nifty 8600/8650 and
later the 8800's. Dec learned their lesson when they built Alpha, and
even Intel realized that their instruction set needed to be pipelined
for the Pentium Pro and above processors.
Ah well. I don't think it was evil marketing or VAX monsters that killed
the KC10, it was simply the fact that the amazing instruction set
couldn't be pipelined to make it more efficient for hardware and the
memory management system wasn't as efficient as the pdp11/Vax MMU concept.
6:06 a.m.
New subject: Pipelining and Dec Jupiter thoughts....
Chris - great and interesting overview. Do you have a reading list for more
details? Thanks!
Lee Courtney
On Thu, May 6, 2021 at 7:35 PM Chris Zach via cctalk <cctalk at classiccmp.org>
wrote:
--
Lee Courtney
+1-650-704-3934 cell
Sort of. But while a lot of things happen in
parallel, out of order,
speculatively, etc., the programming model exposed by the
hardware still is
the C sequential model. A whole lot of logic is needed to create that
appearance, and in fact you can see that all the way back in the CDC 6600
"scoreboard" and "stunt box". Some processors occasionally relax
the
software-visible order, which tends to cause bugs, create marketing issues,
or both -- Alpha comes to mind as an example.
Interesting to see this.
I've been reading a lot recently about the Jupiter/Dolphin project and
the more I read the more I understand why it just could not be done. At
the time (and to an extent even now) the only way to really improve a
system's performance was to pipeline the processor, and the Pdp10
instruction set just wasn't easy to do that with.
They had a great concept: An Instruction fetch/decode system (IBOX), an
execution engine (EBOX), the obligitory vector processor or FPU (HBOX)
and of course the memory system (MBOX). Break the process up into steps
and have the parts all work in parallel to boost performance.
Unfortunately they started to find way too many cases where an indirect
instruction would be fetched that would be based on the AC, which was
being changed by another instruction in the EBOX. This would blow out
all the prefetched work in the pipe, forcing the IBOX to do a costly
reload.
Likewise branch prediction couldn't be done well because most branches
and skips depended on the value in the AC which was once again usually
being modified in the EBOX down the pipe. As soon as it was modified the
pipe had to be flushed and reloaded. It looks like they tried to put
that logic into the IBOX to catch these issues, but that resulted in a
flat processor that wasn't going to benefit from any parallelism, an
endless series of bugs, and an IBOX that was pretty much running with
its own EBOX.
It got worse when they realized that the Extended memory segments in the
2060 architecture totally wrecked the concept of an instruction
decoder/execution box. There were just too many places where an indirect
instruction to another section which was then based on the AC's would
result in Ibox tossing the queue and invalidating the translation
buffers. Increasing the translation buffer helped (I think that's one of
the things they did on the final 2065 to make it faster) but they
couldn't make that big and fast enough. I guess an indirect jump
instruction based on comparing the AC to an indirect address pointing to
an extended segment would be enough to make any decoder just cry.
It's sad to read, you can almost see then realizing it was doomed. The
Foonly F1 was a screamer, but it was basically the KA10 instruction set
and couldn't run extended memory segments like the 2060. And when they
tried to do the same thing with the F4 it came out to be a little slower
than a 2060. I used to think they put only one extended segment in the
2020 to cripple the box, but maybe they started running into the same
problem and ran out of microcode space to try and address it.
Couple this with the fact that much of the 20 series programs were built
in assembler (and why not, it was an amazing thing to program) and you
just had too many programs with cool bespoke code that would totally
trash a pipeline. Fixing compilers to order instructions properly could
have worked, but people just wrote in assembler it wasn't going to
happen and they weren't about to re-code their app to please the new
scheduler God.
The VAX instruction set was a lot less beautiful, but could be pipelined
easier especially with the dedicated MMU so they took the people and
pipelined the hell out of the 780 resulting in the nifty 8600/8650 and
later the 8800's. Dec learned their lesson when they built Alpha, and
even Intel realized that their instruction set needed to be pipelined
for the Pentium Pro and above processors.
Ah well. I don't think it was evil marketing or VAX monsters that killed
the KC10, it was simply the fact that the amazing instruction set
couldn't be pipelined to make it more efficient for hardware and the
memory management system wasn't as efficient as the pdp11/Vax MMU concept.
9:55 a.m.
New subject: Pipelining and Dec Jupiter thoughts....
http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp10/
Has a *lot* of stuff. As I start cranking up my brain to drag BLT out of
the shed and start working on it I'm finding this stuff to be a serious
refresher.
C
On 5/7/2021 2:06 AM, Lee Courtney wrote:
Chris - great and interesting overview. Do you have a
reading list for
more details? Thanks!
Lee Courtney
On Thu, May 6, 2021 at 7:35 PM Chris Zach via cctalk
<cctalk at classiccmp.org <mailto:cctalk at classiccmp.org>> wrote:
Sort of.? But while a lot of things happen in
parallel, out of
order, speculatively, etc., the programming model exposed by
the
hardware still is the C sequential model.? A whole lot of logic is
needed to create that appearance, and in fact you can see that all
the way back in the CDC 6600 "scoreboard" and "stunt box".? Some
processors occasionally relax the software-visible order, which
tends to cause bugs, create marketing issues, or both -- Alpha
comes to mind as an example.
Interesting to see this.
I've been reading a lot recently about the Jupiter/Dolphin project
and
the more I read the more I understand why it just could not be
done. At
the time (and to an extent even now) the only way to really improve a
system's performance was to pipeline the processor, and the Pdp10
instruction set just wasn't easy to do that with.
They had a great concept: An Instruction fetch/decode system
(IBOX), an
execution engine (EBOX), the obligitory vector processor or FPU
(HBOX)
and of course the memory system (MBOX). Break the process up into
steps
and have the parts all work in parallel to boost performance.
Unfortunately they started to find way too many cases where an
indirect
instruction would be fetched that would be based on the AC, which was
being changed by another instruction in the EBOX. This would blow out
all the prefetched work in the pipe, forcing the IBOX to do a costly
reload.
Likewise branch prediction couldn't be done well because most
branches
and skips depended on the value in the AC which was once again
usually
being modified in the EBOX down the pipe. As soon as it was
modified the
pipe had to be flushed and reloaded. It looks like they tried to put
that logic into the IBOX to catch these issues, but that resulted
in a
flat processor that wasn't going to benefit from any parallelism, an
endless series of bugs, and an IBOX that was pretty much running with
its own EBOX.
It got worse when they realized that the Extended memory segments
in the
2060 architecture totally wrecked the concept of an instruction
decoder/execution box. There were just too many places where an
indirect
instruction to another section which was then based on the AC's would
result in Ibox tossing the queue and invalidating the translation
buffers. Increasing the translation buffer helped (I think that's
one of
the things they did on the final 2065 to make it faster) but they
couldn't make that big and fast enough. I guess an indirect jump
instruction based on comparing the AC to an indirect address
pointing to
an extended segment would be enough to make any decoder just cry.
It's sad to read, you can almost see then realizing it was doomed.
The
Foonly F1 was a screamer, but it was basically the KA10
instruction set
and couldn't run extended memory segments like the 2060. And when
they
tried to do the same thing with the F4 it came out to be a little
slower
than a 2060. I used to think they put only one extended segment in
the
2020 to cripple the box, but maybe they started running into the same
problem and ran out of microcode space to try and address it.
Couple this with the fact that much of the 20 series programs were
built
in assembler (and why not, it was an amazing thing to program) and
you
just had too many programs with cool bespoke code that would totally
trash a pipeline. Fixing compilers to order instructions properly
could
have worked, but people just wrote in assembler it wasn't going to
happen and they weren't about to re-code their app to please the new
scheduler God.
The VAX instruction set was a lot less beautiful, but could be
pipelined
easier especially with the dedicated MMU so they took the people and
pipelined the hell out of the 780 resulting in the nifty 8600/8650
and
later the 8800's. Dec learned their lesson when they built Alpha, and
even Intel realized that their instruction set needed to be pipelined
for the Pentium Pro and above processors.
Ah well. I don't think it was evil marketing or VAX monsters that
killed
the KC10, it was simply the fact that the amazing instruction set
couldn't be pipelined to make it more efficient for hardware and the
memory management system wasn't as efficient as the pdp11/Vax MMU
concept.
--
Lee Courtney
+1-650-704-3934 cell 
6:34 a.m.
New subject: Pipelining and Dec Jupiter thoughts....
On 5/6/21 7:35 PM, Chris Zach via cctalk wrote:
> Ah well. I don't think it was evil marketing or VAX monsters that killed the
KC10, it was simply the fact that the amazing instruction set
> couldn't be pipelined to make it more efficient for hardware and the memory
management system wasn't as efficient as the pdp11/Vax MMU concept.
I've never found any documentation on what System Concepts did to make faster systems.
Just crank up the clock speed?
DEC was already using ECL.
It was pretty sad reading all of the memos when I first dug them out of the DEC corporate
archive at CHM.
I forget now if the architects for Jupiter were originally from IBM and got hired into
DEC. Kotok wanted to go in
a completely different direction with 36 bit systems.
12:10 p.m.
New subject: Pipelining and Dec Jupiter thoughts....
On May 7, 2021, at 2:34 AM, Al Kossow via cctalk
<cctalk at classiccmp.org> wrote:
On 5/6/21 7:35 PM, Chris Zach via cctalk wrote:
Speaking of ECL: DEC did some amazing work with ECL VLSI in the early 1990s. There was
an R&D project called "BIPS" (for "billion instructions per
second") -- which aimed to build a single-chip processor that would run at a
gigahertz. That was way faster than the clock speeds of the time, and the notion was that
to do this you needed to use ECL logic. But there wasn't any large scale integration
with ECL, so DEC set out to create that. Part of the problem was that each ECL fab had
its own design rules, and those fabs were a shaky business (not enough volume). That
meant creating a CAD system which could adjust the design to a new set of design rules
quickly.
They built an interesting hybrid system where you could write the design partly as
geometries (for things like memory cells), partly as transistors, partly as gates, and
partly as C code. I remember an example, where they had a transistor schematic for a
single-bit latch, and then wrapped it in a loop: "for (i=0; i < 64; i++) {
<schematic> }". The magic was that (apart from the few bits of explicit
geometry-level design) it was all parameterized, so they could regenerate the actual wafer
geometry overnight for a new fab. The CAD system also allowed extracting a behavioral
model from the design.
The original plan, if I remember right, was to build an Alpha with this technology. That
morphed into building a MIPS, and I think they might have gotten that to work.
Another part of the puzzle was figuring out how to feed 100 watts of power to a chip, and
get rid of that amount of heat, neither of which were anywhere close to what was done at
the time. I still have some of the tech reports that describe that piece (and I
contributed a wild idea -- which unfortunately DEC didn't get around to patenting
before the project was shut down).
paul
Ah well. I don't think it was evil marketing
or VAX monsters that killed the KC10, it was simply the fact that the amazing instruction
set couldn't be pipelined to make it more efficient for hardware and the memory
management system wasn't as efficient as the pdp11/Vax MMU concept.
I've never found any documentation on what System Concepts did to make faster
systems. Just crank up the clock speed?
DEC was already using ECL. 
3:45 p.m.
New subject: Pipelining and Dec Jupiter thoughts....
On 05/07/2021 07:10 AM, Paul Koning via cctalk wrote:
They built an interesting hybrid system where you could
write the design partly as geometries (for things like
memory cells), partly as transistors, partly as gates, and
partly as C code. I remember an example, where they had a
transistor schematic for a single-bit latch, and then
wrapped it in a loop: "for (i=0; i < 64; i++) {
<schematic> }". The magic was that (apart from the few
bits of explicit geometry-level design) it was all
parameterized, so they could regenerate the actual wafer
geometry overnight for a new fab.
That sounds a lot like VHDL, which can be used
to synthesize
chip layout.
Another part of the puzzle was figuring out how to
feed
100 watts of power to a chip, and get rid of that amount
of heat, neither of which were anywhere close to what was
done at the time. I still have some of the tech reports
that describe that piece (and I contributed a wild idea --
which unfortunately DEC didn't get around to patenting
before the project was shut down). paul
IBM was tinkering with high density ECL
system construction
from 1965 or so, as a follow-on to the System 360.
They had
several aborted projects, FS (Future System) and ACS
(Advanced Computer System) that were very advanced
supercomputers. The technology eventually came out as the
309x series, with several hundred MSI ECL chips on a ceramic
interconnect substrate, water-cooled
with a big plate with copper "nails" that pressed down on
the back of the ICs. That was the 308x system, introduced
in 1984.
Jon
4:29 p.m.
New subject: Pipelining and Dec Jupiter thoughts....
On May 7, 2021, at 11:45 AM, Jon Elson <elson at
pico-systems.com> wrote:
On 05/07/2021 07:10 AM, Paul Koning via cctalk wrote:
It's a bit different. In VHDL you can do gate level or behavioral modeling, but the
idea of wrapping a picture in a "for" loop was something I haven't seen
anywhere else.
Also, this was 30 years ago, roughly, when chip design technology was a whole lot more
limited.
They built an interesting hybrid system where you could write the design partly as
geometries (for things like memory cells), partly as transistors, partly as gates, and
partly as C code. I remember an example, where they had a transistor schematic for a
single-bit latch, and then wrapped it in a loop: "for (i=0; i < 64; i++) {
<schematic> }". The magic was that (apart from the few bits of explicit
geometry-level design) it was all parameterized, so they could regenerate the actual wafer
geometry overnight for a new fab.
That sounds a lot like VHDL, which can be used
to synthesize chip layout. Another part
of the puzzle was figuring out how to feed 100 watts of power to a chip, and get rid of
that amount of heat, neither of which were anywhere close to what was done at the time. I
still have some of the tech reports that describe that piece (and I contributed a wild
idea -- which unfortunately DEC didn't get around to patenting before the project was
shut down). paul
IBM was tinkering with high density ECL system construction from
1965 or so, as a follow-on to the System 360. They had several aborted projects, FS
(Future System) and ACS (Advanced Computer System) that were very advanced supercomputers.
The technology eventually came out as the
309x series, with several hundred MSI ECL chips on a ceramic interconnect substrate,
water-cooled
with a big plate with copper "nails" that pressed down on the back of the ICs.
That was the 308x system, introduced in 1984.
4:38 p.m.
New subject: Pipelining and Dec Jupiter thoughts....
On 5/7/21 5:10 AM, Paul Koning wrote:
Speaking of ECL: DEC did some amazing work with ECL
VLSI in the early 1990s. There was an R&D project called "BIPS" (for
"billion instructions per second") -- which aimed to build a single-chip
processor that would run at a gigahertz. That was way faster than the clock speeds of the
time, and the notion was that to do this you needed to use ECL logic.
IBM ran into the same problem in the 60's. The technology they developed with Moto was
used by Amdahl in his clones.
"biCMOS" was tried in the 90's. I worked with Exponential Technology on
their 500MHz PowerPC. The problem with it was
the on-chip caches were too small so the CPU spent most of its time stalled.
6:36 p.m.
On 5/6/2021 6:43 PM, Paul Koning via cctalk wrote:
I wonder. Consider object oriented programming, where objects that have
all manner of stuff inside are treated as a unit and have operations
performed on them.
I don't buy the class model of OOP. Classes
are LIKE each other not
someting that can shared between them. If that was the case move
X-windows to MS-windows would be just X->XWIN = convert(X->M$WIN) for
screen display.
I think of variables and the stack nesting of
variables.
I find it confusing. Where are varibles for a=b+c. found. At what level
can you find just who defined what with out reading the whole
program.How many links must be checked to get your data.
Ben.
Agreed on stack languages. While there's nothing
inherently hard
about them, they don't fit the way we're taught to handle
formulas all
the way from grade one. In fact, while APL is infix, it's
right-associative, which is a definite problem. It's unfortunate
Iverson didn't fix the assignment operator problem the way POP-2 did, by
pointing it to the right so all operators could be left-associative.
1333
days inactive
1334
days old
10 comments
7 participants
participants (7)
-
aek＠bitsavers.org -
athornton＠gmail.com -
bfranchuk＠jetnet.ab.ca -
cz＠alembic.crystel.com -
elson＠pico-systems.com -
leec2124＠gmail.com -
paulkoning＠comcast.net