No Glory for the PDP-15
Quadibloc
"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
> 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
> 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
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
> 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
"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
> "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
"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
> 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
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
> 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
> 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
<Brian.Ing...@SystematicSW.Invalid> wrote:
> On Mon, 31 Dec 2007 09:45:51 -0800 (PST) in alt.folklore.computers,
>
> >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
> 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-
>
> >>>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
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
> 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
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
suggested as a possible fix, is highly suggestive that the computer
hardware is of poor/unreliable quality.
--.
Rostyk
mensa...@aol.com
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
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
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
for the convenience of use on systems such as unixes and mixed with
languages such as C derivatives.
--
Rostyk
CBFalconer
>
... 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
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
>> 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
> 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
> 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
>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
