No Glory for the PDP-15

217 views
Skip to first unread message

Quadibloc

unread,
Dec 31, 2007, 12:45:51 PM12/31/07
to
I was astounded, as I recently noted, to learn from Gordon Bell's
"Computer Engineering" that the PDP-9 was a microprogrammed machine.

The PDP-4/7/9/15 architecture involved a very simple instruction set.
If anything, the PDP-15 gave the appearance of being an enlarged
version of the PDP-8.

Thus, back in the 1970s, I had wondered - since the PDP-8 was so
cramped that it didn't have even a proper load and store instruction,
but made do with TAD and DCA, why DEC didn't make machines with the
PDP-15 architecture, priced at half again as much as a PDP-8, and make
some effort to migrate users to that, because, clearly, a
straightforwards machine would offer more for the money than one that
was cramped.

But since then, I've learned a few things.

One of them is that a bare-bones PDP-15 cost $15,500, which was close
to half again the price of a PDP-8/e, despite coming in a bigger box.

Another is that DEC had made an effort to bring that architecture to
people at a lower price; the PDP-9/L shows how hard they tried.

But even more importantly, before the PDP-8/e, there were only two
PDP-8 machines that came in a small box; the PDP-8/L and the PDP-8/S.
A PDP-8/I may have had a front panel that looked like it belonged to a
small box machine, but the CPU occupied space behind some blank panel
slots as well. So until the PDP-8/e, the technology for a small-box
PDP-15 didn't exist.

Very shortly after the PDP-8 came out - not *so* shortly after that
DEC didn't have time to introduce the LINC-8 and PDP-8/S as well -
Hewlett-Packard entered the minicomputer fray with the HP-2116. And
then there was the Honeywell 316.

Like the PDP-9, they shared the same basic instruction format as the
PDP-8, except they had the 16-bit word one normally associates with a
typical minicomputer.

So, making a PDP-9/I, a PDP-9 without the extra features of the
PDP-15, but implemented with integrated circuits, would have produced
a "me-too" machine,

Another thing I didn't realize back in the 1970s was that the PDP-4
and its successors had instructions for both two's complenent and
one's complement versions of the basic arithmetic operations. This was
wasteful and outmoded.

The original PDP-11, the PDP-11/20, first shipped in June, 1970, which
was before the PDP-8/e first shipped in March 1971. So it wasn't as if
DEC could have shipped a smaller version of the PDP-9 shortly after
March, 1971, while the radical new PDP-11 delayed DEC's move into more
powerful minicomputers, as opposed to bulky medium-range systems, by
several years.

As is well known, the PDP-11 had an orthogonal two-address
architecture. The program counter and stack pointer were included
along with six general registers in the set of eight registers it
could utilize with a number of addressing modes. Minis from Interdata
and Data General and even HP, with their HP 3000 series, would
eventually offer fancier addressing modes than those of old-style
minis, but the PDP-11 led the way in offering a modern, powerful
architecture to minicomputer users.

And so it was wildly successful and immensely influential.

Thus, DEC made the right decision to come out with the PDP-11, rather
than to attempt to groom the venerable PDP-4/7/9/15 architecture for
the same role. The PDP-15, despite having a bigger number, first
shipped in February 1970, which is why it had a somewhat older-style
front panel, harking back to the PDP-9/L (as I but recently
discovered, thanks to Al Kossow).

Had the PDP-15 come out after the PDP-11/20, it would have been clear
that it was simply there to provide existing users with an upgrade
path, instead of being a new and exciting machine in its own right.
The importance of the PDP-11 in the early development of UNIX, and in
much other innovative work with minicomputers, can hardly be
overstated.

The PDP-1 was a one's complement machine, but the PDP-4 mixed two's
complement and one's complement. The PDP-5 was too small to do
anything like that, and it needed multiple precision arithmetic badly,
and so it was a pure two's complement machine. So was the PDP-6.

The PDP-6 was a 36-bit machine with 16 general registers (like the
Univac 1107!) and included the innovative feature of being able to
handle characters of arbitrary size within its words. Except for the
choice of a 36-bit word length, which eventually became unfashionable,
there wasn't really anything wrong with the PDP-6 architecture.

In fact, there was a lot right with it. It was very successful at
timesharing.

As is well known, researchers at Xerox PARC once built their own clone
of a PDP-10 for their computing research rather than try to use one of
XDS' own Sigma machines. (The Sigma computers were mainframes with
datatypes similar to an IBM 360, but with fixed-length 32-bit
instructions: if the Univac 1107 and the PDP-6 were modernized
imitations of the IBM 704, the Sigma was a retro imitation of the
System/360, allowing it to be cheaper even though it was built from
discrete transistors, not ICs.)

I remember when the first advertisements for the DECsystem-20 came
out. The days of the affordable mainframe seemed to be approaching!
(Well, they were, although I would have to wait until after the 386 SX
came out... and after upgrading from 2 MB to 4 MB of RAM, I remember
installing Yggdrasil Linux in a partition... )

And I remember reading in the trade press about DEC's decision to
abandon that platform cold in favor of the VAX.

Well, it *was* always VAXes, and never DECsystem-20s, that Russian
spies kept trying to smuggle out of the Free World. They may have
known something.

Given the success of the PDP-11 versus DEC's older machines, the
PDP-15 and even the PDP-8, it shouldn't have been surprising that they
would favor the VAX-11/780 and its descendants as representing
modernity, versus the (apparently) dated PDP-6/10/ [DECsystem-] 20
lineage.

However, they did bring out the DECsystem-20 (that system *was* based
on 2900 bit slice technology, IIRC) with great fanfare, and there
really wasn't anything terribly wrong with the PDP-10 architecture.

Without having to rely on hindsight, of course it was wrong to
unexpectedly abandon loyal customers completely. Whatever assistance
DEC might have offered to sites migrating from DECsystem-20 hardware
to VAX hardware at the time of their next upgrade, there would likely
be third-party software which now would have to be replaced at the
very least.

Could DEC have copied IBM, which allowed some models of the System/360
line to emulate the 7094-II? The VAX was microcoded, after all.

While DEC was a much smaller company than IBM, and so couldn't bear
the expense of supporting multiple lines of product indefinitely
(assuming that the multiple lines of product only divided up the slice
of the pie DEC would have without them)... there was a Jupiter project
that had reached an advanced stage of development that was cancelled
at this time as well.

The VAX-11/780 was announced on October 25, 1977.

The DECsystem-20 name was around before then; the KS10 processors, the
ones using AM2900 bit slices and offering the impressive price
reductions, were from 1978. They brought new customers to DEC,
attracted by mainframe power at mini prices.

Had the DECsystem-20 side of the business been losing money badly for
DEC, abandoning it miight have been the only choice. Even then, one
ought to do everything possible to treat one's customers right. If
that wasn't true, then phasing it out gradually and migrating
customers to the VAX would have meant going ahead with Jupiter, aiming
it primarily at existing accounts, and treating the DECsystem-20 side
as a "cash cow".

Why didn't that happen?

I can think of a couple of reasons.

On the day that Jupiter was released, being the newest system from
DEC, it would have been the one with the best price/performance. So,
to keep new accounts from going to Jupiter instead of to VAX systems,
it would have been necessary to make price cuts on the VAX line on
that date - and that would send the wrong message, making it look as
though it was the VAX side that was declining!

If the DECsystem-20 side of the business was small compared to the VAX
side, then it wouldn't have been much of a "cash cow" to, say,
subsidize VAX development.

Internal corporate politics seems like the cause of the hasty
abandomnent of the 20 even from a complete ousider's perspective. The
PDP-11 was the future, the PDP-10 was the past. So it likely was
argued that the DECsystem-20 was diluting the company's focus,
consuming an inordinate share of resources that could be better put to
use on developing the VAX further (was there an internal manpower
shortage within DEC at the time?). The (clearly) specious argument
that selling an old-fashioned 36-bit machine would hurt the company's
image more than abandoning loyal customers may also have been
advanced.

I'm not trying to make excuses for a wrong decision, but while
favoring the VAX can be explained by the desire to be modern and up-to-
date, one doesn't expect an insane decision from a big company. If DEC
needed a lot of additional programmers and engineers in a hurry to
take the VAX where they wanted it to go, the quickest way to obtain
them would be internally. (Even then, a way to finish Jupiter on a
shoestring could have been found, of course.) I expect, therefore,
that it must have seemed rational at the time for some reason.

John Savard

Al Kossow

unread,
Dec 31, 2007, 1:14:00 PM12/31/07
to Quadibloc
Quadibloc wrote:
> If DEC
> needed a lot of additional programmers and engineers in a hurry to
> take the VAX where they wanted it to go, the quickest way to obtain
> them would be internally.

Melinda Varian's history of CMS
http://www.princeton.edu/~melinda/25paper.pdf

notes that there was a large layoff of IBM programmers in the mid 70's
as they transferred CMS development to NY.

I had heard that there was a large influx of IBM influence in the mid
70's at DEC. Was this one of the sources?

--
Posted via a free Usenet account from http://www.teranews.com

Mark Crispin

unread,
Dec 31, 2007, 2:13:36 PM12/31/07
to
On Mon, 31 Dec 2007, Quadibloc posted:

> Had the PDP-15 come out after the PDP-11/20, it would have been clear
> that it was simply there to provide existing users with an upgrade
> path, instead of being a new and exciting machine in its own right.

The 18-bit machines had become obscure even in the early 1970s. PDP-8/e,
PDP-10 (KA10, KI10), and various form of PDP-11 were uniquitous, but PDP-9
and PDP-15 were machines that were heard of, but rarely (or never) seen.

The first 18-bit machine that I saw was the PDP-1 at MIT in 1976, and by
that time it was ancient. My next encounter was with a PDP-15 at Stanford
in 1977.

> The importance of the PDP-11 in the early development of UNIX, and in
> much other innovative work with minicomputers, can hardly be
> overstated.

Indeed.

> Well, it *was* always VAXes, and never DECsystem-20s, that Russian
> spies kept trying to smuggle out of the Free World. They may have
> known something.

The Soviets were apparently able to buy PDP-10 systems legally, without
having to smuggle them. I don't know if any were DECSYSTEM-20 (note the
capitalization; it was DECsystem-10 and DECSYSTEM-20 due to a legal
settlement with Singer).

> Had the DECsystem-20 side of the business been losing money badly for
> DEC, abandoning it miight have been the only choice.

Digital (DEC by this time had ceased to exist) was making money hand over
fist on the DECSYSTEM-20.

> If
> that wasn't true, then phasing it out gradually and migrating
> customers to the VAX would have meant going ahead with Jupiter, aiming
> it primarily at existing accounts, and treating the DECsystem-20 side
> as a "cash cow".

That was Digital's strategy.

> Why didn't that happen?

Digital failed, repeatedly, to build a viable follow-on processor to the
KL10. Both Jupiter (2080/4050) and Venus (VAX 8600) projects were in deep
trouble for multiple reasons, a great many of which were in management.

I heard that Alan Kotok was called in to straighten up the mess, and he
came back with an ultimatum: pick which one to save because he'd only be
able to save one. The decision was to save Venus.

The Jupiter instruction set architecture was quite nice and very well
thought-out; in reviewing it today, my favorable impressions are renewed.
However, the hardware in the lab was a mess. I heard rumors of boards
with 50+ ECOs made to them.

There were earlier efforts: Unicorn, Dolphin, and Minnow (which amusingly
lived up to its name by taking a dive into the solder bath) being the most
notable. Minnow was the machine that threatened VAX. It got as far as
running EDDT before it was axed.

From time to time, I've thought about implementing Jupiter in klh10.
However, the Jupiter support code in TOPS-20 has almost certainly
succumbed to software rot, and that has daunted me. Implementing an XKL-1
would probably be more interesting, but that presumes that XKL would make
their sources available to the hobbyist community.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Anne & Lynn Wheeler

unread,
Dec 31, 2007, 3:39:10 PM12/31/07
to

Al Kossow <a...@spies.com> writes:
> Melinda Varian's history of CMS
> http://www.princeton.edu/~melinda/25paper.pdf
>
> notes that there was a large layoff of IBM programmers in the mid 70's
> as they transferred CMS development to NY.
>
> I had heard that there was a large influx of IBM influence in the mid
> 70's at DEC. Was this one of the sources?

the actual situation was that in the wake of cancelling future
system project
http://www.garlic.com/~lynn/subtopic.html#futuresys

there were mad rush to try and get stuff back into the 370 product
pipeline. the favorite son operating system group in POK managed to
convince the corporation that it needed all of the vm370/cms developers
up in burlington mall ... in order to make the mvs/xa schedule; aka
kill/terminate the vm370/cms product and transfer everybody from the
burlington development group to POK to support mvs/xa development.

quite a few of the people in the burlington group didn't leave the area
... and got jobs at various places like dec, prime, etc. some number
showed up in the vms group.

endicott (mid-range) did manage to salvage the vm370/cms product
mission, but effectively had to reconstitute a group from scratch.

... aka, the cp67/cms development group split off from the science
center
http://www.garlic.com/~lynn/subtopic.html#545tech

and growing rapidly (in part working on the morph of cp67 to vm370) took
over (absorbed) the boston programming center on the 3rd flr (545 tech
sq). it also fairly quickly outgrew the space on the 3rd flr ... and
moved out to the old SBC (which had been transferred to cdc) vacant
bldg. in burlington mall.

the news about shutting down the burlington group and move to pok was to
be sprung at the various last minute (possibly hoping to minimize time
people had to find alternatives) ... however the information leaked out
a couple months early. there then was a concerted witch hunt attempting
to identify the source of the leak.

the future system distraction ... and then mad rush to try and get stuff
back into the product pipeline created the opportunity for a lot of
stuff that i had been doing to be picked up and shipped in vm370 product
(some of which i had even done as undergraduate for cp67 but dropped in
the morph from cp67 to vm370).

during the heyday of FS, i continued to do 360/370 work ... and even
made some less than flattering references to FS work ... including
drawing similarties to the effort with a cult film that had been playing
down in central sq). some old email references to moving
lots of work from cp67 to vm370
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102

some amount of kernel restructuring and small subset of work
was picked up for vm370 release 3 (including feature referred
to as DCSS) ... some recent posts.
http://www.garlic.com/~lynn/2007u.html#81 IBM mainframe history, was Floating-point myths
http://www.garlic.com/~lynn/2007v.html#49 IBM mainframe history, was Floating-point myths
http://www.garlic.com/~lynn/2007v.html#50 IBM mainframe history, was Floating-point myths


then it was decided to package a bunch of my other stuff as an
independent product offering ... and a bunch of other stuff that i had
done as undergraduate for cp67 was released on vm370
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

misc. past posts mentioning burlington mall group
http://www.garlic.com/~lynn/94.html#2 Schedulers
http://www.garlic.com/~lynn/98.html#7 DOS is Stolen!
http://www.garlic.com/~lynn/99.html#179 S/360 history
http://www.garlic.com/~lynn/2000b.html#54 Multics dual-page-size scheme
http://www.garlic.com/~lynn/2000b.html#55 Multics dual-page-size scheme
http://www.garlic.com/~lynn/2001m.html#47 TSS/360
http://www.garlic.com/~lynn/2001m.html#49 TSS/360
http://www.garlic.com/~lynn/2001n.html#67 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2002e.html#27 moving on
http://www.garlic.com/~lynn/2002h.html#34 Computers in Science Fiction
http://www.garlic.com/~lynn/2002h.html#59 history of CMS
http://www.garlic.com/~lynn/2002j.html#17 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002m.html#9 DOS history question
http://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?
http://www.garlic.com/~lynn/2002p.html#14 Multics on emulated systems?
http://www.garlic.com/~lynn/2003c.html#0 Wanted: Weird Programming Language
http://www.garlic.com/~lynn/2003d.html#8 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003f.html#53 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
http://www.garlic.com/~lynn/2003h.html#34 chad... the unknown story
http://www.garlic.com/~lynn/2003k.html#0 VSPC
http://www.garlic.com/~lynn/2003k.html#55 S/360 IPL from 7 track tape
http://www.garlic.com/~lynn/2004.html#20 BASIC Language History?
http://www.garlic.com/~lynn/2004.html#32 BASIC Language History?
http://www.garlic.com/~lynn/2004c.html#47 IBM 360 memory
http://www.garlic.com/~lynn/2004d.html#42 REXX still going strong after 25 years
http://www.garlic.com/~lynn/2004e.html#37 command line switches [Re: [REALLY OT!] Overuse of symbolic
http://www.garlic.com/~lynn/2004g.html#24 |d|i|g|i|t|a|l| questions
http://www.garlic.com/~lynn/2004g.html#35 network history (repeat, google may have gotten confused?)
http://www.garlic.com/~lynn/2004g.html#38 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004k.html#23 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of
http://www.garlic.com/~lynn/2004m.html#6 a history question
http://www.garlic.com/~lynn/2004m.html#54 Shipwrecks
http://www.garlic.com/~lynn/2004n.html#7 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004q.html#72 IUCV in VM/CMS
http://www.garlic.com/~lynn/2005f.html#58 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005h.html#37 Software for IBM 360/30
http://www.garlic.com/~lynn/2005j.html#25 IBM Plugs Big Iron to the College Crowd
http://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005p.html#0 Article: The True Value of Mainframe Security
http://www.garlic.com/~lynn/2005q.html#12 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#14 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005s.html#35 Filemode 7-9?
http://www.garlic.com/~lynn/2005s.html#36 Filemode 7-9?
http://www.garlic.com/~lynn/2006b.html#18 {SPAM?} Re: Expanded Storage
http://www.garlic.com/~lynn/2006j.html#44 virtual memory
http://www.garlic.com/~lynn/2006l.html#25 Mainframe Linux Mythbusting (Was: Using Java in batch on z/OS?)
http://www.garlic.com/~lynn/2006m.html#21 The very first text editor
http://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks
http://www.garlic.com/~lynn/2006m.html#28 Mainframe Limericks
http://www.garlic.com/~lynn/2006o.html#51 The Fate of VM - was: Re: Baby MVS???
http://www.garlic.com/~lynn/2006r.html#41 Very slow booting and running and brain-dead OS's?
http://www.garlic.com/~lynn/2006s.html#1 Info on Compiler System 1 (Univac, Navy)?
http://www.garlic.com/~lynn/2006u.html#28 Assembler question
http://www.garlic.com/~lynn/2007f.html#25 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007f.html#28 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#39 Wylbur and Paging
http://www.garlic.com/~lynn/2007l.html#58 Scholars needed to build a computer history bibliography
http://www.garlic.com/~lynn/2007m.html#66 Off Topic But Concept should be Known To All
http://www.garlic.com/~lynn/2007p.html#29 Newsweek article--baby boomers and computers
http://www.garlic.com/~lynn/2007p.html#35 Newsweek article--baby boomers and computers
http://www.garlic.com/~lynn/2007q.html#0 A question for the Wheelers - Diagnose instruction
http://www.garlic.com/~lynn/2007s.html#33 Age of IBM VM
http://www.garlic.com/~lynn/2007s.html#36 Oracle Introduces Oracle VM As It Leaps Into Virtualization
http://www.garlic.com/~lynn/2007t.html#68 T3 Sues IBM To Break its Mainframe Monopoly
http://www.garlic.com/~lynn/2007u.html#40 Computer language history


Quadibloc

unread,
Dec 31, 2007, 4:15:25 PM12/31/07
to
On Dec 31, 12:13 pm, Mark Crispin <m...@CAC.Washington.EDU> wrote:
> Digital failed, repeatedly, to build a viable follow-on processor to the
> KL10.  Both Jupiter (2080/4050) and Venus (VAX 8600) projects were in deep
> trouble for multiple reasons, a great many of which were in management.
>
> I heard that Alan Kotok was called in to straighten up the mess, and he
> came back with an ultimatum: pick which one to save because he'd only be
> able to save one.  The decision was to save Venus.
>
> The Jupiter instruction set architecture was quite nice and very well
> thought-out; in reviewing it today, my favorable impressions are renewed.
> However, the hardware in the lab was a mess.  I heard rumors of boards
> with 50+ ECOs made to them.

I had noticed a mention of Dolphin and Minnow on the Columbia
University web site.

If Jupiter had been 80% - 90% complete, and hadn't had serious
problems, then, of course, cancelling it would have been an irrational
decision.

Cancelling a project that was in deep trouble, mismanaged, and non-
viable, however, is not a decision that I can fault. (And, of course,
the more vital VAX project was also in deep trouble, which means it
isn't sabotage.) And if Jupiter had an ISA other than that of the
KS-10 processor, that's also getting into rather ambitious territory.

The decision to save the new VAX instead of the new PDP-10 makes
sense.

This might not excuse their choice to abruptly withdraw support for
the DECSYSTEM-20 - and there would always be the option of tame, low
development cost option of providing upgrade options which consisted
of the same basic machine implemented in newer, faster technology.

As for XLR, I see they're in the business of fiber optic switches now,
their glory days of PDP-10 cloning being behind them.

John Savard

Carl Appellof

unread,
Dec 31, 2007, 7:26:07 PM12/31/07
to

"Quadibloc" <jsa...@ecn.ab.ca> wrote in message
news:02915ef0-52fd-4391...@d4g2000prg.googlegroups.com...

> Could DEC have copied IBM, which allowed some models of the System/360
> line to emulate the 7094-II? The VAX was microcoded, after all.
>

The VAX 11/780 could run PDP-11 code natively, as well as running VAX code.
THAT is the market DEC was trying to protect at the time - PDP-11 users that
wanted to move up from 11/70s. It was all altruism either. In the early
releases of VMS, many of the command line utilities still ran from MCR via
the RSX-11 subsystem.

I think it would have been tough, even in microcode, to emulate a 36-bit
machine with a 32-bit architecture.

Carl


Quadibloc

unread,
Dec 31, 2007, 7:56:38 PM12/31/07
to
On Dec 31, 5:26 pm, "Carl Appellof" <doctor...@yahoo.com> wrote:
> "Quadibloc" <jsav...@ecn.ab.ca> wrote in message
news:02915ef0-52fd-4391-
b6b2-92a...@d4g2000prg.googlegroups.com...

>
> > Could DEC have copied IBM, which allowed some models of the System/360
> > line to emulate the 7094-II? The VAX was microcoded, after all.
>
> The VAX 11/780 could run PDP-11 code natively, as well as running VAX code.
> THAT is the market DEC was trying to protect at the time - PDP-11 users that
> wanted to move up from 11/70s.

And that I understand. The VAX was a higher priority; it served both a
larger market, and one more likely to sustain the customer in the
future, and one with more growth possibilities.

> It was all altruism either. In the early
> releases of VMS, many of the command line utilities still ran from MCR via
> the RSX-11 subsystem.
>
> I think it would have been tough, even in microcode, to emulate a 36-bit
> machine with a 32-bit architecture.

Yes, you would be using 64 bits of storage for a 32-bit word. IBM did
accomplish it, though, so it was possible.

Could they have also kept their existing pdp-10 user base reasonably
happy without too much expense - if so, then they can be said to have
failed.

John Savard

John Byrns

unread,
Dec 31, 2007, 8:09:13 PM12/31/07
to
In article <BMfej.162$dl1...@newsfe06.lga>,
"Carl Appellof" <doct...@yahoo.com> wrote:

> "Quadibloc" <jsa...@ecn.ab.ca> wrote in message
> news:02915ef0-52fd-4391...@d4g2000prg.googlegroups.com...
> > Could DEC have copied IBM, which allowed some models of the System/360
> > line to emulate the 7094-II? The VAX was microcoded, after all.
> >
>
> The VAX 11/780 could run PDP-11 code natively, as well as running VAX code.
> THAT is the market DEC was trying to protect at the time - PDP-11 users that
> wanted to move up from 11/70s.

But the VAX 11/780 wasn't a move up from the 11/70 in performance. We
moved from an 11/70 to an 11/780, and the 11/780 didn't match the
performance of the 11/70, of course the 11/70 had serious limitations on
the size of programs that could be run and the 11/780 certainly fixed
that problem.


Regards,

John Byrns

--
Surf my web pages at, http://fmamradios.com/

Anne & Lynn Wheeler

unread,
Dec 31, 2007, 8:26:10 PM12/31/07
to
Anne & Lynn Wheeler <ly...@garlic.com> writes:
> quite a few of the people in the burlington group didn't leave the area
> ... and got jobs at various places like dec, prime, etc. some number
> showed up in the vms group.

re:
http://www.garlic.com/~lynn/2007v.html#96 source for VAX programmers

there was a joke about the head of POK (aka center of ibm mainframe
land) being a major contributor to VMS.

Brian Inglis

unread,
Jan 1, 2008, 12:40:10 AM1/1/08
to
On Mon, 31 Dec 2007 09:45:51 -0800 (PST) in alt.folklore.computers,
Quadibloc <jsa...@ecn.ab.ca> wrote:

>The importance of the PDP-11 in the early development of UNIX, and in
>much other innovative work with minicomputers, can hardly be
>overstated.

The importance of the PDP-7 running the first edition of Unix written in
assembler is rarely mentioned.

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Brian....@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply

Peter Flass

unread,
Jan 1, 2008, 7:55:10 AM1/1/08
to
Quadibloc wrote:

> On Dec 31, 5:26 pm, "Carl Appellof" <doctor...@yahoo.com> wrote:
>
>>"Quadibloc" <jsav...@ecn.ab.ca> wrote in message
>
> news:02915ef0-52fd-4391-
> b6b2-92a...@d4g2000prg.googlegroups.com...
>
>>>Could DEC have copied IBM, which allowed some models of the System/360
>>>line to emulate the 7094-II? The VAX was microcoded, after all.
>>
>>The VAX 11/780 could run PDP-11 code natively, as well as running VAX code.
>>THAT is the market DEC was trying to protect at the time - PDP-11 users that
>>wanted to move up from 11/70s.
>
>
> And that I understand. The VAX was a higher priority; it served both a
> larger market, and one more likely to sustain the customer in the
> future, and one with more growth possibilities.
>
>
>>It was all altruism either. In the early
>>releases of VMS, many of the command line utilities still ran from MCR via
>>the RSX-11 subsystem.
>>
>>I think it would have been tough, even in microcode, to emulate a 36-bit
>>machine with a 32-bit architecture.
>
>
> Yes, you would be using 64 bits of storage for a 32-bit word. IBM did
> accomplish it, though, so it was possible.

It's unfortunate memory was expensive back then. Prices have dropped so
much that throwing away 45% of your memory would be a reasonable
tradeoff today, but it would have been a major hit a few years ago.

Johnny Billquist

unread,
Jan 1, 2008, 8:27:50 AM1/1/08
to
Brian Inglis skrev:

> On Mon, 31 Dec 2007 09:45:51 -0800 (PST) in alt.folklore.computers,
> Quadibloc <jsa...@ecn.ab.ca> wrote:
>
>> The importance of the PDP-11 in the early development of UNIX, and in
>> much other innovative work with minicomputers, can hardly be
>> overstated.
>
> The importance of the PDP-7 running the first edition of Unix written in
> assembler is rarely mentioned.

One could possibly argue that the PDP-7 version of Unix wasn't important. It's
Unix, which makes it the real orgin of the whole operating system tree, but much
of what have made Unix name didn't exist or originate with the PDP-7 version.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

Quadibloc

unread,
Jan 1, 2008, 8:29:10 AM1/1/08
to
On Dec 31 2007, 10:40 pm, Brian Inglis

<Brian.Ing...@SystematicSW.Invalid> wrote:
> On Mon, 31 Dec 2007 09:45:51 -0800 (PST) in alt.folklore.computers,
>
> Quadibloc <jsav...@ecn.ab.ca> wrote:
> >The importance of the PDP-11 in the early development of UNIX, and in
> >much other innovative work with minicomputers, can hardly be
> >overstated.
>
> The importance of the PDP-7 running the first edition of Unix written in
> assembler is rarely mentioned.

Not that rarely. It certainly is true that Unix was born on the PDP-7.
But that machine still was not very influential in the way that the
PDP-11 was influential, because there was not a large number of
programmers whose experience included work on a PDP-4, 7, 9, or 15 as
a significant part.

Of course, the PDP-11 - or UNIX - is a *bad* influence in some ways in
my opinion.

Just the other day, I did a file.readlines() in Python, and I had to
insert extra code to get rid of the trailing newlines in all the lines
but the first. What gave these people the idea that the record
delimiter belongs to the record, if not the bad example of C? They
would never have learned such notions from FORTRAN or APL, running on
an IBM System/360 - where records can contain all 256 characters, and
their extent is defined in another way entirely (like Pascal strings).

John Savard

mensa...@aol.com

unread,
Jan 1, 2008, 12:48:25 PM1/1/08
to
On Jan 1, 6:55�am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:
> Quadibloc wrote:
> > On Dec 31, 5:26 pm, "Carl Appellof" <doctor...@yahoo.com> wrote:
>
> >>"Quadibloc" <jsav...@ecn.ab.ca> wrote in message
>
> > news:02915ef0-52fd-4391-
> > b6b2-92ade459b...@d4g2000prg.googlegroups.com...

>
> >>>Could DEC have copied IBM, which allowed some models of the System/360
> >>>line to emulate the 7094-II? The VAX was microcoded, after all.
>
> >>The VAX 11/780 could run PDP-11 code natively, as well as running VAX code.
> >>THAT is the market DEC was trying to protect at the time - PDP-11 users that
> >>wanted to move up from 11/70s.
>
> > And that I understand. The VAX was a higher priority; it served both a
> > larger market, and one more likely to sustain the customer in the
> > future, and one with more growth possibilities.
>
> >>It was all altruism either. �In the early
> >>releases of VMS, many of the command line utilities still ran from MCR via
> >>the RSX-11 subsystem.
>
> >>I think it would have been tough, even in microcode, to emulate a 36-bit
> >>machine with a 32-bit architecture.
>
> > Yes, you would be using 64 bits of storage for a 32-bit word. IBM did
> > accomplish it, though, so it was possible.
>
> It's unfortunate memory was expensive back then. �Prices have dropped so
> much that throwing away 45% of your memory would be a reasonable
> tradeoff today, but it would have been a major hit a few years ago.

Yeah, we never had any memory boards as spares, always had
to disable another machine because the programmers wnated
to swap memory boards "because my program isn't working".
Guess how many times that fixed a problem.

Walter Bushell

unread,
Jan 1, 2008, 1:13:49 PM1/1/08
to
In article <477a37c3$0$11051$4c36...@roadrunner.com>,
Peter Flass <Peter...@Yahoo.com> wrote:

I don't know about you, but losing half of my memory today would be a
major loss. Most of us had more of it ten years ago too.

Anne & Lynn Wheeler

unread,
Jan 1, 2008, 2:12:05 PM1/1/08
to
"Carl Appellof" <doct...@yahoo.com> writes:
> I think it would have been tough, even in microcode, to emulate a 36-bit
> machine with a 32-bit architecture.

there were number of microengines used to emulate 360, 1401, 1410, 1610,
7090, etc

recent reference here to 360/30
http://www.garlic.com/~lynn/2007v.html#99 It keeps getting uglier

and some numbere of 360 FE manuals
http://bitsavers.org/pdf/ibm/360/fe/

which makes some reference to the native hardware of the machines
... and at least for 360/30, talks about 1401 & 1610 emulation mode.

360/65 had front panel selector for 709x emulation

a misc references to (36-bit) 709x:

IBM 7090 CompWisdom
http://www.compwisdom.com/topics/IBM-7090
IBM Archives: 7090 Data Processing System
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP7090.html
IBM Archives: 7090 Data Processing System (continued)
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP7090B.html
IBM 7090/94 Architecture Home Page
http://dgatx.com/computing/people/Jack-Harper/pubs/2004/IBM-7090/archive.html

Rostyslaw J. Lewyckyj

unread,
Jan 1, 2008, 5:30:17 PM1/1/08
to
I have unfortunately had serious arguements with the modern Fortran gurus
about permissible record contents. They insist that only characters from
the standard defined Fortran character set are allowed as character data.
i.e. not all bit combinations of a machines byte are allowed i.e. the bit
combinations used as control characters are out of band, especially the
NULL, CR, BS, et.c. of the 8-bit character set.
--
Rostyk

Rostyslaw J. Lewyckyj

unread,
Jan 1, 2008, 5:51:25 PM1/1/08
to
The simple fact that something like a memory board swap was even
suggested as a possible fix, is highly suggestive that the computer
hardware is of poor/unreliable quality.
--.
Rostyk

mensa...@aol.com

unread,
Jan 1, 2008, 6:06:07 PM1/1/08
to
On Jan 1, 4:51 pm, "Rostyslaw J. Lewyckyj" <urj...@bellsouth.net>
wrote:

They were DEC LSI-11 boards, there was never an issue of
hardware reliability, the programmers were incompetent.
But higher up in the food chain so I had to do what I
was told.

When you couple such blatant stupidity with an operating
system like RT-11 (that didn't support sub-directories or
file fragmentation) some fun problems turned up.

Quadibloc

unread,
Jan 1, 2008, 6:15:03 PM1/1/08
to
On Jan 1, 3:30 pm, "Rostyslaw J. Lewyckyj" <urj...@bellsouth.net>
wrote:
> Quadibloc wrote:

> > Just the other day, I did a file.readlines() in Python, and I had to
> > insert extra code to get rid of the trailing newlines in all the lines
> > but the first. What gave these people the idea that the record
> > delimiter belongs to the record, if not the bad example of C? They
> > would never have learned such notions from FORTRAN or APL, running on
> > an IBM System/360 - where records can contain all 256 characters, and
> > their extent is defined in another way entirely (like Pascal strings).

> I have unfortunately had serious arguements with the modern Fortran gurus


> about permissible record contents. They insist that only characters from
> the standard defined Fortran character set are allowed as character data.
> i.e. not all bit combinations of a machines byte are allowed i.e. the bit
> combinations used as control characters are out of band, especially the
> NULL, CR, BS, et.c. of the 8-bit character set.

It depends what machine you're running on.

On a System/360, saving a 32-bit fload in A4 format is perfectly
legitimate - and completely safe.

But on a DOS or UNIX machine, that doesn't work, and you have to
convert to decimal - or use a *binary* file rather than a straight
text file.

It may well be, therefore, that putting characters outside the FORTRAN
character set in records is an extension to the FORTRAN standard,
which, as a language standard, defines what _must_ work on *all*
machines running FORTRAN, no matter what their operating system or
character set.

John Savard

Peter Flass

unread,
Jan 1, 2008, 6:31:57 PM1/1/08
to
Rostyslaw J. Lewyckyj wrote:

Not all combinations are allowed if you expect portability. There's
some (fortunately not much) Multics code that depends on 9-bit bytes.

Rostyslaw J. Lewyckyj

unread,
Jan 1, 2008, 7:00:10 PM1/1/08
to
Eggsactly! These were in arguements about restricting the language
for the convenience of use on systems such as unixes and mixed with
languages such as C derivatives.
--
Rostyk

CBFalconer

unread,
Jan 1, 2008, 7:34:40 PM1/1/08
to
Quadibloc wrote:
>
... snip ...

>
> Just the other day, I did a file.readlines() in Python, and I had
> to insert extra code to get rid of the trailing newlines in all
> the lines but the first. What gave these people the idea that the
> record delimiter belongs to the record, if not the bad example of
> C? They would never have learned such notions from FORTRAN or APL,
> running on an IBM System/360 - where records can contain all 256
> characters, and their extent is defined in another way entirely
> (like Pascal strings).

Try ggets.zip, in fully portable standard C, and put in public
domain. No variation in newline returning (all absorbed).
Available at:

<http://cbfalconer.home.att.net/download/>

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>

jmfb...@aol.com

unread,
Jan 2, 2008, 8:54:14 AM1/2/08
to
In article <fldf56$kcp$1...@Tempo.Update.UU.SE>,

Johnny Billquist <b...@update.uu.se> wrote:
>Brian Inglis skrev:
>> On Mon, 31 Dec 2007 09:45:51 -0800 (PST) in alt.folklore.computers,
>> Quadibloc <jsa...@ecn.ab.ca> wrote:
>>
>>> The importance of the PDP-11 in the early development of UNIX, and in
>>> much other innovative work with minicomputers, can hardly be
>>> overstated.
>>
>> The importance of the PDP-7 running the first edition of Unix written in
>> assembler is rarely mentioned.
>
>One could possibly argue that the PDP-7 version of Unix wasn't important.

Wrong. It was very important.

> It's
>Unix, which makes it the real orgin of the whole operating system tree, but
much
>of what have made Unix name didn't exist or originate with the PDP-7 version.

It set the tradeoffs the developers had to make when designing each
monitor computing request section.

You would have seen a very, very, very different OS if ATT had
bought a PDP-10 for the guys or an IBM 360.

/BAH

Mark Crispin

unread,
Jan 2, 2008, 11:08:59 AM1/2/08
to
On Wed, 2 Jan 2008, jmfb...@aol.com posted:

>> One could possibly argue that the PDP-7 version of Unix wasn't important.
> Wrong. It was very important.

Its importance was that it was done. However, UNIX would have languished
in obscurity had they not moved to a PDP-11 and rewritten it in C.

IIRC, the first PDP-11 version of UNIX was written in assembly language;
and when the question of an Interdata port came up they got tired of
rewriting everything in assembly language each time and hence the decision
to use C.

> You would have seen a very, very, very different OS if ATT had
> bought a PDP-10 for the guys or an IBM 360.

UNIX would not have been written if they had a PDP-10.

Peter Flass

unread,
Jan 2, 2008, 1:12:13 PM1/2/08
to
Mark Crispin wrote:
> On Wed, 2 Jan 2008, jmfb...@aol.com posted:
>
>>> One could possibly argue that the PDP-7 version of Unix wasn't
>>> important.
>>
>> Wrong. It was very important.
>
>
> Its importance was that it was done. However, UNIX would have
> languished in obscurity had they not moved to a PDP-11 and rewritten it
> in C.
>
> IIRC, the first PDP-11 version of UNIX was written in assembly language;
> and when the question of an Interdata port came up they got tired of
> rewriting everything in assembly language each time and hence the
> decision to use C.
>
>> You would have seen a very, very, very different OS if ATT had
>> bought a PDP-10 for the guys or an IBM 360.
>
>
> UNIX would not have been written if they had a PDP-10.
>

There would have been no need;-)

Mark Crispin

unread,
Jan 2, 2008, 1:31:26 PM1/2/08
to
On Wed, 2 Jan 2008, Peter Flass posted:
> Mark Crispin wrote:
>> UNIX would not have been written if they had a PDP-10.
> There would have been no need;-)

My point exactly.

John Savard

unread,
Jan 2, 2008, 5:06:05 PM1/2/08
to
On Wed, 02 Jan 08 13:54:14 GMT, jmfb...@aol.com wrote, in part:

>You would have seen a very, very, very different OS if ATT had
>bought a PDP-10 for the guys or an IBM 360.

True, but isn't the Unix we ended up with really the one we would have
gotten if they could have bought a PDP-11 for them in the first place?

John Savard
http://www.quadibloc.com/index.html

Eugene Miya

unread,
Jan 2, 2008, 6:08:56 PM1/2/08
to
In article <l8jjn3l6vms0vre2m...@4ax.com>,

Brian Inglis <Brian....@SystematicSW.ab.ca> wrote:
>On Mon, 31 Dec 2007 09:45:51 -0800 (PST) in alt.folklore.computers,
>Quadibloc <jsa...@ecn.ab.ca> wrote:
>>The importance of the PDP-11 in the early development of UNIX, and in
>>much other innovative work with minicomputers, can hardly be
>>overstated.
>
>The importance of the PDP-7 running the first edition of Unix written in
>assembler is rarely mentioned.

Also do not discount the PDP-9, nor the Interdata/Perkin-Elmer 7/32,
8/32, and 3200 series efforts, the TSS 360 port, and the Univac 1100 port.
We are all here because of them.

--

Eugene Miya

unread,
Jan 2, 2008, 6:18:30 PM1/2/08
to
On Mon, 31 Dec 2007 09:45:51 -0800 (PST) in alt.folklore.computers,
Quadibloc <jsa...@ecn.ab.ca> wrote:
>>>> The importance of the PDP-11 in the early development of UNIX, and in
>>>> much other innovative work with minicomputers, can hardly be
>>>> overstated.

Brian Inglis skrev:


>>> The importance of the PDP-7 running the first edition of Unix written in
>>> assembler is rarely mentioned.

In article <fldf56$kcp$1...@Tempo.Update.UU.SE>,


Johnny Billquist <b...@update.uu.se> wrote:
>>One could possibly argue that the PDP-7 version of Unix wasn't important.

In article <flg526$8qk...@s873.apx1.sbo.ma.dialup.rcn.com>,


<jmfb...@aol.com> wrote:
>Wrong. It was very important.

My God, hell must be freezing over.

>> It's
>>Unix, which makes it the real orgin of the whole operating system tree, but
>much
>>of what have made Unix name didn't exist or originate with the PDP-7 version.
>
>It set the tradeoffs the developers had to make when designing each
>monitor computing request section.
>
>You would have seen a very, very, very different OS if ATT had
>bought a PDP-10 for the guys or an IBM 360.

Quite true.
But I think Xerox management denying a 10 acquitision was more important
and involved hardware and in some ways even more impressive. Harder call.
I wish I had been able to save that hardware.

--

Eugene Miya

unread,
Jan 2, 2008, 6:28:17 PM1/2/08
to
In article <alpine.OSX.1.00.0...@pangtzu.panda.com>,
Mark Crispin <m...@CAC.Washington.EDU> wrote:
Ah Mr. Crispin, Lynn's ex-.
>On Mon, 31 Dec 2007, Quadibloc posted:
>> Well, it *was* always VAXes, and never DECsystem-20s, that Russian
>> spies kept trying to smuggle out of the Free World. They may have
>> known something.
>
>The Soviets were apparently able to buy PDP-10 systems legally, without
>having to smuggle them. I don't know if any were DECSYSTEM-20 (note the
>capitalization; it was DECsystem-10 and DECSYSTEM-20 due to a legal
>settlement with Singer).

Spies are overrated.
The Soviet management, like my honorable ancestors in the 80s and now
the Chinese choose to follow what IBM does. Their VAX smuggling, forget
that, cloning (we have one) efforts only amounted to 5-6 dozen machines.
The number of 10s had to be in the handfuls (even smaller).

The difference was the address space.

The British were the guys who desparately wanted 10s and 20s.
It was their govt. who preventing them from buying many.

>Digital failed, repeatedly, to build a viable follow-on processor to the
>KL10. Both Jupiter (2080/4050) and Venus (VAX 8600) projects were in deep
>trouble for multiple reasons, a great many of which were in management.

Yup Mark got that right.

--

Eugene Miya

unread,
Jan 2, 2008, 6:33:04 PM1/2/08
to

"Quadibloc" <jsa...@ecn.ab.ca> wrote in message
news:02915ef0-52fd-4391...@d4g2000prg.googlegroups.com...
>> Could DEC have copied IBM, which allowed some models of the System/360
>> line to emulate the 7094-II? The VAX was microcoded, after all.

What's this 7094 infatuation? It's another dead architecture.

In article <BMfej.162$dl1...@newsfe06.lga>,
Carl Appellof <doct...@yahoo.com> wrote:

>The VAX 11/780 could run PDP-11 code natively, as well as running VAX code.
>THAT is the market DEC was trying to protect at the time - PDP-11 users that

>wanted to move up from 11/70s. It was all altruism either. In the early

>releases of VMS, many of the command line utilities still ran from MCR via
>the RSX-11 subsystem.

Yup. 70s ran about as fast as a 780 for small address codes. Use more
than 65K for real memory with overlays you could watch performance degrade.

An 11/55 with its bipolar cache could run faster than a 780 if you could
fit into memory.

>I think it would have been tough, even in microcode, to emulate a 36-bit
>machine with a 32-bit architecture.

It was considered. I know the DARPA SPICE guys thought about that.
They just didn't have good enough people in that end; they had to
concentrate on SPICE.

--

glen herrmannsfeldt

unread,
Jan 2, 2008, 7:00:55 PM1/2/08
to
Mark Crispin wrote:
(snip)

> UNIX would not have been written if they had a PDP-10.

Maybe not so obvious.

The idea of doing things simple when others find the more
complex way of doing them is not so common, but when it does
happen it is probably somewhat independent of the available
hardware.

Many OS seem to have been written following Brooks
(The Mythical Man Month) "second system effect."

Supposedly when asked what they would have done differently
to unix many years later, the answer was to write "creat"
with an "e". More commands and functions might have had
longer names, but the basic idea of a simple OS might
still have occurred.

-- glen

Rostyslaw J. Lewyckyj

unread,
Jan 2, 2008, 7:18:26 PM1/2/08
to
Or an IBM 360

>
> There would have been no need;-)
>
One more guilt burden to pile on ATT!

Anne & Lynn Wheeler

unread,
Jan 2, 2008, 7:25:47 PM1/2/08
to
glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
> Supposedly when asked what they would have done differently
> to unix many years later, the answer was to write "creat"
> with an "e". More commands and functions might have had
> longer names, but the basic idea of a simple OS might
> still have occurred.

similar but different thread from crypto mailing list, virtual machine
operating system as a simple/micro kernel ... also mentioning vax/vms
vmm
http://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software iminent
http://www.garlic.com/~lynn/aadsm28.htm#6 Death of antivirus software iminent
http://www.garlic.com/~lynn/aadsm28.htm#8 Death of antivirus software iminent

Rich Alderson

unread,
Jan 2, 2008, 8:17:50 PM1/2/08
to
eug...@cse.ucsc.edu (Eugene Miya) writes:

You're talking about MAXC, right?

--
Rich Alderson "You get what anybody gets. You get a lifetime."
ne...@alderson.users.panix.com --Death, of the Endless

Rich Alderson

unread,
Jan 2, 2008, 8:20:40 PM1/2/08
to
eug...@cse.ucsc.edu (Eugene Miya) writes:

Was there a PDP-9 port? Mr. Ritchie, sir?

Quadibloc

unread,
Jan 2, 2008, 9:04:11 PM1/2/08
to
On Jan 2, 4:33 pm, eug...@cse.ucsc.edu (Eugene Miya) wrote:

> An 11/55 with its bipolar cache could run faster than a 780 if you could
> fit into memory.

Not bipolar cache. Bipolar main memory. As I learned through my foray
into computer front panel drawing.

John Savard

Quadibloc

unread,
Jan 2, 2008, 9:07:03 PM1/2/08
to
On Jan 2, 4:08 pm, eug...@cse.ucsc.edu (Eugene Miya) wrote:

> Also do not discount the PDP-9, nor the Interdata/Perkin-Elmer 7/32,
> 8/32, and 3200 series efforts, the TSS 360 port, and the Univac 1100 port.
> We are all here because of them.

I don't know about you, but none of those ports happened before I was
born.

Or do you mean the Internet, as it exists today, owes its existence to
the unique combination of early UNIX ports that took place?

John Savard

John Byrns

unread,
Jan 2, 2008, 9:20:48 PM1/2/08
to
In article
<c5db1823-25a4-4e16...@s19g2000prg.googlegroups.com>,
Quadibloc <jsa...@ecn.ab.ca> wrote:

Yes, it was the 11/70 that had the cache. IIRC the 11/70 also had the
advantage of a 32 bit wide memory system bus to fill the cache.


Regards,

John Byrns

--
Surf my web pages at, http://fmamradios.com/

Dennis Ritchie

unread,
Jan 2, 2008, 10:45:42 PM1/2/08
to

"Rich Alderson" <ne...@alderson.users.panix.com> wrote in message
news:mddwsqriu...@panix5.panix.com...
>
> Was there a PDP-9 [Unix] port? Mr. Ritchie, sir?

Yes, Ken moved the -7 system to both the PDP-9 and PDP-15
just to try them out. Minimal effort, just some new drivers, no
effort to take advantage of extra features on either. Total time
they actually ran was probably measured in hours or a few
days at most. One of the machines ran a step-and-repeat
camera for making IC masks.

Dennis


Dennis Ritchie

unread,
Jan 2, 2008, 10:56:33 PM1/2/08
to

"glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message
news:TZydndXC-7IVueHa...@comcast.com...

> Mark Crispin wrote:
> (snip)
>
>> UNIX would not have been written if they had a PDP-10.
>
> Maybe not so obvious.
>
...
We did try to get a PDP-10. I don't think the system
would have been all that different--Ken wanted to write an OS
and didn't care all that much about what hardware.
What would have been different was acceptance-- The
PDP-11 (being cheaper and newer) was ascending, the PDP-10
and followons were declining. PDP-11s could readily be bought
by a small department in a Univ. or company and run by them.

>
> Many OS seem to have been written following Brooks
> (The Mythical Man Month) "second system effect."
>
I suppose Unix was a "second system" for us since
we had worked on Multics, but given hardware constraints,
the impulse was more to take some ideas and grow them,
not perfect and expand.
...

Dennis


Dennis Ritchie

unread,
Jan 2, 2008, 11:05:59 PM1/2/08
to

"Mark Crispin" <m...@CAC.Washington.EDU> wrote in message
news:alpine.OSX.1.00.0...@pangtzu.panda.com...

> On Wed, 2 Jan 2008, jmfb...@aol.com posted:
>>> One could possibly argue that the PDP-7 version of Unix wasn't
>>> important.
>> Wrong. It was very important.
>
> Its importance was that it was done. However, UNIX would have languished
> in obscurity had they not moved to a PDP-11 and rewritten it in C.

True enough.

> IIRC, the first PDP-11 version of UNIX was written in assembly language;
> and when the question of an Interdata port came up they got tired of
> rewriting everything in assembly language each time and hence the decision
> to use C.

Actually things were mostly in C by the time the Interdata came
along. We hadn't bothered to rewrite some random stuff, and ramping
up for the Interdata provided the impulse to do most of the remnants--
never did rewrite the -11 assembler by 7th edition time.

Dennis


Mark Crispin

unread,
Jan 3, 2008, 1:28:14 AM1/3/08
to
On Thu, 3 Jan 2008, Dennis Ritchie posted:

> We did try to get a PDP-10. I don't think the system
> would have been all that different--Ken wanted to write an OS
> and didn't care all that much about what hardware.

Would he have actually done it though, particularly if you folks had
gotten a Tenex system? In particular, I wonder if Ken would have focused
on the shell and tools instead of the kernel if there was an existing
Tenex kernel.

My belief is that an attribute (some would say fault) of the PDP-10 was
that the machine instruction set was pleasant enough that it was alright
(for some value of "alright" greater than other platforms) to write large
applications in assembly language; and a similar attribute/fault of Tenex
(later TOPS-20) tended to stifle other OS efforts.

IMHO, other than being in assembly language, the only thing really wrong
with Tenex/TOPS-20 at the kernel level was the wrong process model; too
much was associated with the process tree (including UID and connected
directory!) instead of being per-process; and a process tree could not be
broken up. Tenex had piping, standard input/output, etc.

Did UNIX have a hierarchical filesystem from inception? Tenex did not,
and TOPS-20's was indisputably inferior to UNIX's; but that was years
later.

> What would have been different was acceptance-- The
> PDP-11 (being cheaper and newer) was ascending, the PDP-10
> and followons were declining.

But if I'm correct, the timeframe in which you folks started UNIX was the
early 1970s, wasn't it? That outcome was by no means obvious at that
time, although perhaps it was by the late 1970s.

jmfb...@aol.com

unread,
Jan 3, 2008, 7:24:13 AM1/3/08
to
>On Wed, 2 Jan 2008, Peter Flass posted:
>> Mark Crispin wrote:
>>> UNIX would not have been written if they had a PDP-10.
>> There would have been no need;-)
>
>My point exactly.

Do you think they would have run a vanilla monitor?

/BAH

jmfb...@aol.com

unread,
Jan 3, 2008, 7:29:13 AM1/3/08
to
In article <477c1bc6$1@darkstar>, eug...@cse.ucsc.edu (Eugene Miya) wrote:
>On Mon, 31 Dec 2007 09:45:51 -0800 (PST) in alt.folklore.computers,
>Quadibloc <jsa...@ecn.ab.ca> wrote:
>>>>> The importance of the PDP-11 in the early development of UNIX, and in
>>>>> much other innovative work with minicomputers, can hardly be
>>>>> overstated.
>
>Brian Inglis skrev:
>>>> The importance of the PDP-7 running the first edition of Unix written in
>>>> assembler is rarely mentioned.
>
>In article <fldf56$kcp$1...@Tempo.Update.UU.SE>,
> Johnny Billquist <b...@update.uu.se> wrote:
>>>One could possibly argue that the PDP-7 version of Unix wasn't important.
>
>In article <flg526$8qk...@s873.apx1.sbo.ma.dialup.rcn.com>,
> <jmfb...@aol.com> wrote:
>>Wrong. It was very important.
>
>My God, hell must be freezing over.

Well, Mass. is. It's 5F. You, and others, continue to misunderstand
me about OSes. We were in the business to sell hardware. It was
the customers' needs that dictated the OS. I firmly believe in
supplying what makes the customer do useful work; that way they
will buy more hardware and tell their friends.


>
>>> It's
>>>Unix, which makes it the real orgin of the whole operating system tree, but
>>much
>>>of what have made Unix name didn't exist or originate with the PDP-7
version.
>>
>>It set the tradeoffs the developers had to make when designing each
>>monitor computing request section.
>>
>>You would have seen a very, very, very different OS if ATT had
>>bought a PDP-10 for the guys or an IBM 360.
>
>Quite true.
>But I think Xerox management denying a 10 acquitision was more important
>and involved hardware and in some ways even more impressive. Harder call.
>I wish I had been able to save that hardware.

Just look at the tradeoffs made plus the non-goals. You can discern
the evolution of the software that we see today. And the people who
did the work are also important. If the Alpha male had control issues
you would never see a true timesharing system where anything can
happen at any time in any way.

/BAH

jmfb...@aol.com

unread,
Jan 3, 2008, 7:35:46 AM1/3/08
to
In article <5u34n6F...@mid.individual.net>,

"Dennis Ritchie" <d...@bell-labs.com> wrote:
>
>"glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message
>news:TZydndXC-7IVueHa...@comcast.com...
>> Mark Crispin wrote:
>> (snip)
>>
>>> UNIX would not have been written if they had a PDP-10.
>>
>> Maybe not so obvious.
>>
> ...
> We did try to get a PDP-10. I don't think the system
>would have been all that different--Ken wanted to write an OS
>and didn't care all that much about what hardware.

I suspect that your approach to disk files would have been
different.

And possibly the scheduling.

>What would have been different was acceptance-- The
>PDP-11 (being cheaper and newer) was ascending, the PDP-10
>and followons were declining.

Perhaps. I can think of a scenario where a desktop-sized box would
have been a PDP-10.

<snip>

/BAH

Christopher C. Stacy

unread,
Jan 3, 2008, 10:09:03 AM1/3/08
to
jmfb...@aol.com writes:
> Do you think they would have run a vanilla monitor?

I had always heard that most sites ran a hacked
version of TOPS-10 ("nobody runs a vanilla monitor").
How true was that?

I also believe it was not uncommon for IBM sites
to fiddle with the provided software.

My experience with either of those systems was
linited to a few sites, though, so I may have
a distorted impression.

Anne & Lynn Wheeler

unread,
Jan 3, 2008, 10:45:31 AM1/3/08
to
cst...@news.dtpq.com (Christopher C. Stacy) writes:
> I had always heard that most sites ran a hacked
> version of TOPS-10 ("nobody runs a vanilla monitor").
> How true was that?
>
> I also believe it was not uncommon for IBM sites
> to fiddle with the provided software.
>
> My experience with either of those systems was
> linited to a few sites, though, so I may have
> a distorted impression.

it was especially true of cp67 and vm370 ... both shipped not only with
source, but the maintenance was also done in source. slightly related
recent post
http://www.garlic.com/~lynn/2007u.html#29 Folklore references to CP67 at Lincoln Labs

it was less true of the other systems ... since they didn't ship as
source distribution ... although source listings were available.

this changed in the early 80s with the transition to OCO (object code
only); recent posts mentioning OCO
http://www.garlic.com/~lynn/2007u.html#8 Open z/Architecture or Not
http://www.garlic.com/~lynn/2007u.html#9 Open z architecture and Linux questions


in the middle of the OCO wars there was some analysis of (waterloo)
"SHARE" library for vm370 ... that there was a many lines of source in
the "SHARE" library ... as there was in the base product. ... recent
post mentioning share (source) library:
http://www.garlic.com/~lynn/2007n.html#3 Is Parallel Programming Just Too Hard?

part of the corporate transition to OCO was to provide "user exits" ...
places where users could add calleable routines associated with specific
functions.

in recent thread in crypto mailing lists ... there were comments about
early systems not being built specifically for "security". recent
reference
http://www.garlic.com/~lynn/2008.html#12 No Glory for the PDP-15

and posts


http://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software iminent
http://www.garlic.com/~lynn/aadsm28.htm#6 Death of antivirus software iminent
http://www.garlic.com/~lynn/aadsm28.htm#8 Death of antivirus software iminent

however, the idea that a system that didn't provide security was sort of
a foreign concept ... and therefor having to build a seperate system
specifically for security (because normal systems didn't provide
security) was also a foreign concept.

besides the gov. and commercial institutions with high integrity
requirements there were also commercial timesharing (cp67 & vm370 based)
service bureaus
http://www.garlic.com/~lynn/subtopic.html#timeshare

and one of the things that they would do, was make cms "padded cell"
modifications to limit the harm that users might do themselves (as
opposed to underlying security that limited harm that they could do the
system or each other).

one example of the level of security ... is some of these commercial
timesharing service bureaus were providing services to competitive wall
street firms (all on the same machine).

Mark Crispin

unread,
Jan 3, 2008, 11:00:33 AM1/3/08
to
On Thu, 3 Jan 2008, Christopher C. Stacy posted:

> I had always heard that most sites ran a hacked
> version of TOPS-10 ("nobody runs a vanilla monitor").
> How true was that?

Unlike TOPS-20, it was a standard part of the TOPS-10 installation to
build a monitor (MONGEN) that was customized for the site. Every TOPS-10
site that I encountered had local monitor hacks, some more extensive than
others.

That doesn't mean that there weren't vanilla TOPS-10 monitors out there,
just that I never say any.

Mark Crispin

unread,
Jan 3, 2008, 11:04:46 AM1/3/08
to
On Thu, 3 Jan 2008, jmfb...@aol.com posted:

>>>> UNIX would not have been written if they had a PDP-10.
>>> There would have been no need;-)
>> My point exactly.
> Do you think they would have run a vanilla monitor?

I don't think that they would have run TOPS-10, as it was unsuited for
their purposes. My assumption was that they would have run Tenex; and
there really wasn't such a thing as "vanilla Tenex"

Walter Bushell

unread,
Jan 3, 2008, 11:27:55 AM1/3/08
to

Did you see any tutti fruity monitors?

Johnny Billquist

unread,
Jan 3, 2008, 11:58:22 AM1/3/08
to
John Byrns skrev:

> In article
> <c5db1823-25a4-4e16...@s19g2000prg.googlegroups.com>,
> Quadibloc <jsa...@ecn.ab.ca> wrote:
>
>> On Jan 2, 4:33 pm, eug...@cse.ucsc.edu (Eugene Miya) wrote:
>>
>>> An 11/55 with its bipolar cache could run faster than a 780 if you could
>>> fit into memory.
>> Not bipolar cache. Bipolar main memory. As I learned through my foray
>> into computer front panel drawing.
>
> Yes, it was the 11/70 that had the cache. IIRC the 11/70 also had the
> advantage of a 32 bit wide memory system bus to fill the cache.

Correct. 2K cache. 2 way associative. Each cache line was 32 bits.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

Eugene Miya

unread,
Jan 3, 2008, 2:23:36 PM1/3/08
to
In article <mddzlvn...@panix5.panix.com>,

Rich Alderson <ne...@alderson.users.panix.com> wrote:
>eug...@cse.ucsc.edu (Eugene Miya) writes:
>> On Mon, 31 Dec 2007 09:45:51 -0800 (PST) in alt.folklore.computers,
>> Quadibloc <jsa...@ecn.ab.ca> wrote:
>>> You would have seen a very, very, very different OS if ATT had
>>> bought a PDP-10 for the guys or an IBM 360.
>
>> Quite true.
>> But I think Xerox management denying a 10 acquitision was more important
>> and involved hardware and in some ways even more impressive. Harder call.
>> I wish I had been able to save that hardware.
>
>You're talking about MAXC, right?

Yep.

I actually once did see it on a PARC visit.
Had I known certain things, I would have made a better effort to get
them to have preserved it. As a result, I've trying to make certain
other PARC hardware which is now merely sitting unused gets an important
chance to get preserved. That, and all the other things the CHM wants
me to help them on...... If you guys only knew....

--

Eugene Miya

unread,
Jan 3, 2008, 2:26:35 PM1/3/08
to
In article <byrnsj-A458FC....@newsclstr03.news.prodigy.net>,

John Byrns <byr...@sbcglobal.net> wrote:
>In article
><c5db1823-25a4-4e16...@s19g2000prg.googlegroups.com>,
> Quadibloc <jsa...@ecn.ab.ca> wrote:
>
>> On Jan 2, 4:33 pm, eug...@cse.ucsc.edu (Eugene Miya) wrote:
>>
>> > An 11/55 with its bipolar cache could run faster than a 780 if you could
>> > fit into memory.
>>
>> Not bipolar cache. Bipolar main memory. As I learned through my foray
>> into computer front panel drawing.
>
>Yes, it was the 11/70 that had the cache. IIRC the 11/70 also had the
>advantage of a 32 bit wide memory system bus to fill the cache.

Gawd, I can't believe I wrote cache.
I blame Alan Smith and Terje.
Crays also had bipolar and ECL memories.

Was a 70 32 or 22 bits?
That gets into the BBN C/70 being 24 bits (I have to collect one of
those... any one want to donate one? I know where I can get a 30)

--

Eugene Miya

unread,
Jan 3, 2008, 2:49:31 PM1/3/08
to
In article <47bda86f-8d6e-4537...@h11g2000prf.googlegroups.com>,

I'm not certain what you are getting at. I'm not certain what you
regard as unique.

You can get some of the OS vitriol from Barb. 11s had DOS, RT-11, RSTS, RSX,
internally and other OSes like TSX externally (and who know what else?).
DEC was seen in the mainframe world as a joke of a company. But I would
have to argue that DEC from 1962 on was a far more important firm than IBM.
Computers were just still too expensive even for the firming buying
them, so they were buying their futures.

Most firms didn't have enough resources to consider communications. IBM
and DEC were rare exceptions (one had to really experience non-IBM and
non-DEC environments to appreciate that, and DECnet wasn't that bad; SNA
token rings, etc. France, they really tried IBM as a company).
That's a whole separate but related can of worms.

Naw the problem with all those early machines was their dependent
investments in their OSes. There were the machine language guys hardware
guys who were fervent in their work. Everyone had to concentrate on speed and
compilers, which weren't enough. Ken and Dennis literally put a lot of
people out of work in the 80s. But they also employed thousands, they
gave a boost to the workstation sector, the minisupercomputer (I would
say sic) sector, etc.

The expression "Unix-like" was a joke in 2 difference sectors: those who
thought Unix was a joke (compared to Ada at the time as stagnating
experiments in new PLS and OSes) annd the "Xerox-like" joke ("But we are
Xerox").

It was running ported code. (I only heard Clark's great comment later.)
Combining OSes and networks, I had an IBMish GE guy noted that it would
have taken 3-6 months to write and debug a DR-11W (I think it was W not
B) driver for hyperchannel (I just started a wikipedia page on NSC).
That's when I used net.arch in early usenet to just ask. I had a driver
in less than 24 hours. That was the kind of thing which killed off the
mainframe dinosaurs. I sometimes wonder where those GE guys went.

--

Morten Reistad

unread,
Jan 3, 2008, 2:18:13 PM1/3/08
to
In article <flikep$8qk...@s997.apx1.sbo.ma.dialup.rcn.com>,

<jmfb...@aol.com> wrote:
>In article <477c1bc6$1@darkstar>, eug...@cse.ucsc.edu (Eugene Miya) wrote:
>>On Mon, 31 Dec 2007 09:45:51 -0800 (PST) in alt.folklore.computers,
>>Quadibloc <jsa...@ecn.ab.ca> wrote:
>>>>>> The importance of the PDP-11 in the early development of UNIX, and in
>>>>>> much other innovative work with minicomputers, can hardly be
>>>>>> overstated.
>>
>>Brian Inglis skrev:
>>>>> The importance of the PDP-7 running the first edition of Unix written in
>>>>> assembler is rarely mentioned.
>>
>>In article <fldf56$kcp$1...@Tempo.Update.UU.SE>,
>> Johnny Billquist <b...@update.uu.se> wrote:
>>>>One could possibly argue that the PDP-7 version of Unix wasn't important.
>>
>>In article <flg526$8qk...@s873.apx1.sbo.ma.dialup.rcn.com>,
>> <jmfb...@aol.com> wrote:
>>>Wrong. It was very important.
>>
>>My God, hell must be freezing over.
>
>Well, Mass. is. It's 5F. You, and others, continue to misunderstand
>me about OSes. We were in the business to sell hardware. It was
>the customers' needs that dictated the OS. I firmly believe in
>supplying what makes the customer do useful work; that way they
>will buy more hardware and tell their friends.

That chapter should be quoted in textbooks. Look at yourself, how the
denial jumps out of the text. You were, and are, in total denial about what
the customers wanted. You say you sold hardware, and in the next sentence
you state that the hardware wouldn't sell without specific changes to the
software. And yet you keep up the delusion that you didn't sell software.

>>>> It's
>>>>Unix, which makes it the real orgin of the whole operating system tree, but
>>>much
>>>>of what have made Unix name didn't exist or originate with the PDP-7
>version.
>>>
>>>It set the tradeoffs the developers had to make when designing each
>>>monitor computing request section.
>>>
>>>You would have seen a very, very, very different OS if ATT had
>>>bought a PDP-10 for the guys or an IBM 360.
>>
>>Quite true.
>>But I think Xerox management denying a 10 acquitision was more important
>>and involved hardware and in some ways even more impressive. Harder call.
>>I wish I had been able to save that hardware.
>
>Just look at the tradeoffs made plus the non-goals. You can discern
>the evolution of the software that we see today. And the people who
>did the work are also important. If the Alpha male had control issues
>you would never see a true timesharing system where anything can
>happen at any time in any way.

I just cannot make sense of that one.

-- mrr

John Byrns

unread,
Jan 3, 2008, 4:05:52 PM1/3/08
to
In article <477d36eb$1@darkstar>, eug...@cse.ucsc.edu (Eugene Miya)
wrote:

> In article <byrnsj-A458FC....@newsclstr03.news.prodigy.net>,

Going from very dim memories, the memory address was 22 bits on the
11/70, the memory access width was 32 bits, and the processor was 16