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
Eugene Miya
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
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
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
"Quadibloc" <jsa...@ecn.ab.ca> wrote in message
news:02915ef0-52fd-4391...@d4g2000prg.googlegroups.com...
>> 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
(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
>
> There would have been no need;-)
>
Anne & Lynn Wheeler
> 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
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
Quadibloc
> 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
> 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
<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
"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
"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."
>
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
"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
> 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
>> 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
>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
"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
> 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
> 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
> 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
>>>> 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
Did you see any tutti fruity monitors?
Johnny Billquist
> 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
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
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
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
<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
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
bits as per the PDP-11 architecture. IIRC the 11/45, 11/55, and 11/70
all used the same CPU with different memory systems, and expanded memory
mapping hardware on the 11/70 to accommodate the larger physical memory.
Rich Alderson
And all that software is presumably long gone along with the PDP-7 version.
Oh, well.
Pete Fenelon
>
> The British were the guys who desparately wanted 10s and 20s.
> It was their govt. who preventing them from buying many.
>
Someone had to prop up the market for GEC.... Did the 63/30 have *any*
market outside universities running Alvey-funded projects? ;)
pete
--
pe...@fenelon.com "irk the purists - if you've never then you ought."
Peter Flass
> "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.
This was (AIUI) a reference to a successful emulation of a 36-bit
architecture on a 32-bit machine. The two systems involved are
immaterial. The 7094 may be as dead as the PDP-10, but was probably
equally important.
Peter Flass
> 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.
The basic idea of unix is simple, but it's stuff like that that drives
people crazy. For heaven's sake, call it "create" (etc.), and just
alias "creat" for the old-timers. Multics had the right idea here with
a "long" name, and one or more shorter aliases for each.
Guy Sotomayor
>
> 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
> bits as per the PDP-11 architecture. IIRC the 11/45, 11/55, and 11/70
> all used the same CPU with different memory systems, and expanded memory
> mapping hardware on the 11/70 to accommodate the larger physical memory.
>
The CPUs in the 11/45, 11/50 and 11/55 were identical (the main
difference was what if any memory was in the fastbus slots). They were
similar to the 11/70 but are not the same. I don't have module
utilizations handy but I doubt there are any boards in common (from
someone who has both an 11/55 and 11/70 currently operational).
--
TTFN - Guy
Peter Flass
I'd say *everyone* had mods to HASP/JES2, which is why so much of it is
still shipped as source. I think most people modified VM, though Lynne
could speak to this better. OS/360, MVS, etc. tried to provide standard
exit points. Most people customized one or more exits, though I don't
know if you'd classify these as a system mod.
Anne & Lynn Wheeler
> I'd say *everyone* had mods to HASP/JES2, which is why so much of it
> is still shipped as source. I think most people modified VM, though
> Lynne could speak to this better. OS/360, MVS, etc. tried to provide
> standard exit points. Most people customized one or more exits,
> though I don't know if you'd classify these as a system mod.
re:
http://www.garlic.com/~lynn/2008.html#14 hacked TOPS-10 monitors
I had also done significant amount of HASP mods. as undergraduate. One
was deleting the RJE support (to recover some space) and replacing it
with 2741 & tty terminal support and a editor that implemented CMS edit
syntax (total different code since cms editor wasn't re-entrant ... and
HASP code had to be re-entrant) ... for an early CRJE
later in the transition from HASP to JES2 (and move to gburg, i've
mentioned before my wife did a stint in the gburg JES group after
working on future system project) ... JES2 had some integration and
distribution problems. The JES2 was doing much of their source
management with the cp67/vm370 processes on CMS ... but then to ship,
they had to convert to "MVS" process.
misc. past posts mentioning hasp, jes, nje, etc
http://www.garlic.com/~lynn/subtopic.html#hasp
Eric Smith
> However, they did bring out the DECsystem-20 (that system *was* based
> on 2900 bit slice technology, IIRC)
Only the bottom-of-the-line 2020, using the KS10 processor.
Eugene Miya
Pete Fenelon <pe...@stratos.fenelon.com> wrote:
>In alt.folklore.computers Eugene Miya <eug...@cse.ucsc.edu> wrote:
>> The British were the guys who desparately wanted 10s and 20s.
>> It was their govt. who preventing them from buying many.
>
>Someone had to prop up the market for GEC.... Did the 63/30 have *any*
>market outside universities running Alvey-funded projects? ;)
8^)
You know, that's a good question.
Do you have any 63/30s?
I was thinking more ICL.
It's easy bait to get Nick Maclauren going.
We shoot ourselves in the foot so many times in this industry.
Our curator is now kicking himself for collection recommendations I made
10 years ago that he prioritized down. I lucked out and saved a DAP and
we got a Meiko, and we are in touch with the Computer Conservation
Society, but people outside the UK are and were so clueless about Alvey
that they can't believe the story. Much less what happened to Turing.
I think I should sometime make time to visit Hodges some time.
--
Eugene Miya
John Byrns <byr...@sbcglobal.net> wrote:
>> >> > 11/55 ....... 780
>> >advantage of a 32 bit wide memory system bus to fill the cache.
>>
>> That gets into the BBN C/70 being 24 bits
>
>11/70, the memory access width was 32 bits, and the processor was 16
>bits as per the PDP-11 architecture. IIRC the 11/45, 11/55, and 11/70
>all used the same CPU with different memory systems, and expanded memory
>mapping hardware on the 11/70 to accommodate the larger physical memory.
See:
I'm waiting and so rarely hear those critical trademarks:
UNIBUS(tm) and MASSBUS(tm).
--
Eugene Miya
>> <jmfb...@aol.com> wrote:
>>>Wrong. It was very important.
>>
>>My God, hell must be freezing over.
>
>Well, Mass. is. It's 5F.
Too warm.
>You, and others, continue to misunderstand me about OSes.
OK: I am open to that statement.
>We were in the business to sell hardware.
I think all your ex-customers agree that's what your sales force, your
engineering staff, janitors and secretaries were in the business to do.
I heard that when I first entered the full time work force.
It was also telling about DEC's attitudes to "foreign" now heterogeneous
equipment (not unique to DEC, just ask IBM) as well as software. Which
of course became DEC's bain.
> It was the customers' needs that dictated the OS.
That's like: We are only following orders.
And the customer is always right.
>I firmly believe in
>supplying what makes the customer do useful work; that way they
>will buy more hardware and tell their friends.
I and the others have no doubt you think that.
And it was nice of your to repackage CDC disk drives, and small Cray
Y-MP/ELs and Maspar 1200s. and ...
>>>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.
Could have been called Multics.
>>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.
That's too general a statement to read. I've read books on Phyllogeny
and Ontogeny (Gould's text book). The people statement is motherhood.
The thought experiment is bump people off in car accidents and reason
what migth have happened. Too many "anys" (too many infinite possibilities).
--
Eric Sosman
>
> Did you see any tutti fruity monitors?
http://www.youtube.com/watch?v=flfB4PGBHhE
--
Eric Sosman
eso...@ieee-dot-org.invalid
John Byrns
wrote:
> In article <byrnsj-3C812D....@newsclstr03.news.prodigy.net>,
Granted that my memory is fading, but I don't remember either the
UNIBUS(tm) or the MASSBUS(tm) having anything to do with processor to
memory communication in the 11/70.
Dennis Ritchie
"Mark Crispin" <m...@CAC.Washington.EDU> wrote in message
news:alpine.OSX.1.00.0...@pangtzu.panda.com...
> 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.
>
> 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.
Who knows what might have been, but as an example of Ken's
thinking, he started to write his own system for the Multics
GE 645. It didn't do much beyond "hello world"; he gave it
up once it was clear the 645 was about to disappear.
> 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.
Not on the PDP-7, but it did on the first PDP-11 system.
...
> 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.
Late 60s. Things began to take off after the C version in 1973, though
there was a little spread before that.
Dennis
Mark Crispin
> Who knows what might have been, but as an example of Ken's
> thinking, he started to write his own system for the Multics
> GE 645. It didn't do much beyond "hello world"; he gave it
> up once it was clear the 645 was about to disappear.
Thanks for that bit of information. Obviously, Ken was determined to
write a kernel!
My youthful effort to write my own kernel (it was called SYS/8) was on the
PDP-8. I got as far as being able to schedule and run 5 independent tasks
(a very basic round-robin scheduler) via a hardware clock but never got
further than that; the PDP-8 in question only had 4K and my request to get
buy the timesharing board and extended memory was rejected. That meant no
hardware relocation or protection from user processes doing IOTs. The
latter was bad enough (gentlemen's timesharing!) but the former was fatal.
Plus its only file store was paper-tape... ;-)
>> 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.
> Not on the PDP-7, but it did on the first PDP-11 system.
A hierarchical filesystem was definitely important, IMHO even more
important than long file names, and UNIX definitely got it right when all
of the PDP-10 operating systems got it wrong. I assume that you folks
picked / because it was easier to type than > on Multics.
Now, I'll quibble over /dev, and even more about sockets. But it isn't
really fair to blame you guys for sockets; that was Berkeley. There was
some religion in the late 1970s to the effect that that sort of interface
was the way to do network communication. Even BBN (which knew better when
they implemented NCP) did something similar in Tenex for TCP. I remember
people insisting that this was "better", although they never could explain
why (we had no trouble explaining why *not*!).
The TOPS-20 community refused to accept the BBN interface for TCP, and we
got a more natural (to us) filesystem interface. It was mind-boggling to
us that UNIX, of all operating systems, didn't allow you to write (or
pipe) to a network printer without the intermediary of a program that knew
how to do network I/O. [It was one of our few "neener-neeners" over the
UNIX guys in the 1980s, otherwise our butts were getting kicked...]
The other thing that I'll complain about in the fundamental design of
UNIX's filesystem is that there is no way to translate from an inode (or
open designator from the user programmer POV) to a path. I understand the
issue with hard links, but could have been a linked list between the lunk
names so you could do the translation (and IMHO this is all the more
reason that you need this capability). Oh well, something to be kept in
mind the next time a new operating system is designed. [IIRC, NT has this
problem too.]
Nonetheless, the fact that the UNIX design has lasted ~ 40 years and shows
no sign of going away any time soon is a credit to the design and its
designers.
>> 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.
> Late 60s. Things began to take off after the C version in 1973, though
> there was a little spread before that.
Interesting then that UNIX time began on January 1, 1970. I would have
thought that you would have had some files with earlier days.
This presumes that time being signed rather than unsigned was an oversight
rather than intent to cover back to some time in 1901...
That's also interesting since it indicates that the UNIX effort actually
predated Tenex.
glen herrmannsfeldt
(snip)
> The other thing that I'll complain about in the fundamental design of
> UNIX's filesystem is that there is no way to translate from an inode (or
> open designator from the user programmer POV) to a path.
I presume you don't count
find / -inum n
-- glen
Johnny Billquist
Correct.
The CPU on the 11/45/55/70 was originally the KB-11B, later replaced with the
KB-11C which have a different FPP. I think the C model could also be used in the
11/45/55 but I'm not 100% sure of that.
The memory on the 11/70 sits on a separate memory bus. 22 (actually 24, but the
high two lines were never used) address lines, and 32 data lines on that address
bus (plus parity). The memory bus is connected directly to the cache system on
the 11/70. And then you have MK-11 and/or MJ-11 memory boxes connected to the
memory bus.
The MOS memory in the MK-11 boxes have an internal bus that is almost identical
to the memory bus on the VAX-11/750. The same 256K memory cards can be used in
both systems.
The 1MB memory cards for the VAX cannot be used in the 11/70 however. Stupid
design detail. With a small hardware hack and software fix, those cards can also
be used in the 11/70.
The Unibus and Massbus controllers in the 11/70 talks to the cache system as
well, and via that out on the memory bus.
The Massbus controllers also appear in Unibus space, of course, and then you can
access the I/O page from the CPU as well.
One, rather tricky, detail was how to access the CSRs of the MK-11 memory boxes,
which were in the Unibus I/O page, when the MK-11 boxes aren't on the Unibus.
Did anyone else ever do this? (I had to, to get 1MB memory cards to work...)
jmfb...@aol.com
cst...@news.dtpq.com (Christopher C. Stacy) wrote:
>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'd say true. The system's programmer on each site had the
job of fiddling when things went wrong. The programmer would
also have pet projects.
Also there probably wasn't two systems that had identical
hardware. We never sent a MONITR.EXE other than the one
on the boot tape for a cold start.
/BAH
jmfb...@aol.com
You are wrong, Morten. I knew that large part of our success was
because of the software we furnished. It was Gordon Bell who
refused to acknowledge that software was important and that it
was becoming more important than the hardwarre. That last piece
is what caused him to remove all software "threats" to the hardware
business.
Since he was the VP of engineering, we had to work under his
aegis. Since he was the VP of engineering and thus the
conroller of the steering committee, he had a large influence
of what projects the steering committee approved and disapproved.
My attitude is, and was, the TOPS-10 attitude. TOPS-10's products
reflected this attitude. The reason the 10 had this attitude
is because it primary developers had the attitude. We understood
that software was the grease that made the creaky hardware work
as best as it could work.
>
>>>>> 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.
Consider a personality trait where the person has to control
all aspects of a thing. When writing OS code this type
of personality will be annoyed, irritated, and dismissive
of an interruption. So the code won't reflect true timesharing
which is event-based. You would tend to see an OS that is
task-based instead. An interruption would be put on list
to be dealt with after the current task is 100% finished.
/BAH
Anne & Lynn Wheeler
> Consider a personality trait where the person has to control
> all aspects of a thing. When writing OS code this type
> of personality will be annoyed, irritated, and dismissive
> of an interruption. So the code won't reflect true timesharing
> which is event-based. You would tend to see an OS that is
> task-based instead. An interruption would be put on list
> to be dealt with after the current task is 100% finished.
we've had this discussion in past threads ... in other threads i've
characterized it as not being able to change coding styles when dealing
with different types of operations ... device drviers tend to be very
event driven ... but I've critized before purely event driven (device
driver) coding styles in schedulers ... which can work much better if it
is dealing more with statistical activity.
this is also related to a joke that i buried in my resource manager.
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
the litigation from commerical and gov. resulted in the 23jun69
unbundling announcement
http://www.garlic.com/~lynn/subtopic.html#unbundle
which started to charge for application software and other services.
however, the case was made that kernel software was still free. cp67
and vm370 continued full source-based distribution and maintenance.
however, the distraction of the future system effort
http://www.garlic.com/~lynn/subtopic.html#futuresys
and a period where products in the 370 pipeline started to dry up
... allowed clone processors to gain a foothold. i claim that then
contributed to the decision to start charging for kernel software
... and the release of my resource manager was selected to be the guinea
pig. however, even with starting to charge for all software ... there
was still a period before the decision to go OCO (object code only)
... recent reference:
http://www.garlic.com/~lynn/2008.html#14 hacked TOPS-10 monitors
a lot of resource manager was low level event oriented coding ... that
permeated all thru the kernel (pathlength optimizatins, fault handling,
elimination of conditiions to leading to zombies, kernel strucutre reorg
anticipating multiprocessor support) ... however, the stated purpose for
the resource manager was advanced dynamic adaptive capability.
one of the corporate revues came up with the state-of-the-art for all
"modern" schedulers was low-level "tuning" knobs. this totally ignored
all the code that monitored all the low-level operational
characteristics and dynamically adapted to configuration and workload.
So i had to add low-level "tuning" knobs to be considered
"state-of-the-art".
documentation was provided describing exactly what the tuning knobs did
as well as the "algorithms" behind what went on ... as well as all the
code was available.
the joke? (which went undetected for decades?) was what operations
research call "degress of freedom" ... i.e. the dynamic adaptive code
had more "degrees of freedom" than the tuning knobs. one of my
characterizations was that the typical people dealing with low-level
kernel code (in 360 assembler) didn't recognize something that was
effectively dealing in time-dimension.
misc past posts mentioning tuning knobs:
http://www.garlic.com/~lynn/97.html#12 OSes commerical, history
http://www.garlic.com/~lynn/2002c.html#13 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002c.html#16 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002c.html#28 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2004o.html#10 Multi-processor timing issue
http://www.garlic.com/~lynn/2005b.html#58 History of performance counters
http://www.garlic.com/~lynn/2006b.html#21 IBM 3090/VM Humor
http://www.garlic.com/~lynn/2007g.html#56 The Perfect Computer - 36 bits?
Mark Crispin
> Mark Crispin wrote:
>> The other thing that I'll complain about in the fundamental design of
>> UNIX's filesystem is that there is no way to translate from an inode (or
>> open designator from the user programmer POV) to a path.
> I presume you don't count
> find / -inum n
Right. That find comand is more of a system manager/programmer POV, as
only root can guarantee that it will actually return the needed results.
UNIX lacks the equivalent of TOPS-20 JFNS%, which given a file designator
would return a canonical, fully-qualified file specification. In the case
of UNIX it would have to be a way to get multiple file specifications
(fortunately, you do have the link count so you know how much space to
allow).
The problem is that the fundamental UNIX filesystem design doesn't have
the necessary pointers to do this. One way of doing this would be to have
the inode have a pointer to a directory entry that is the head of a
linked-list of directory entries that are hard links to the file. To
unlink, either (one-way links) you run down the linked list until you find
the to-be unlinked entry's previous to tie to the to-be unlinked entry's
next, or (two-way links) you update both the previous and the next of the
unlinked entry. More reads to do one write, or two writes; pick your
poison.
However, we're not done yet. Each directory needs a way to derive its own
path. Fortunately, UNIX normally forbids directories to be lunk, so we
don't have to worry about a directory having multiple paths. Even so, the
choices are unpleasant. Either we store the full path in the directory
(potentially a huge string) or we store the directory's name within its
superior, and then read that string from the superior (fortunately the ..
entry makes that easier) and repeat until we hit the root. You can do the
something like the latter now, with considerably more work as to get your
own name you have to scan the all the directory entries in the superior
until you find your inode.
It's easy to see why the designers of UNIX chose to punt on this question.
The unfortunate consequence is that by punting this issue in the kernel,
they damned four decades of application programmers to do the necessary
workarounds in their application. All those programs which worry about
".." in paths (or the impact of symlinks) for security reasons would
suddenly have a non-issue...
Oh well. To be fixed in the new operating system... ;-)
John Byrns
Johnny Billquist <b...@update.uu.se> wrote:
> Correct.
> The CPU on the 11/45/55/70 was originally the KB-11B, later replaced with the
> KB-11C which have a different FPP. I think the C model could also be used in
> the
> 11/45/55 but I'm not 100% sure of that.
>
> The memory on the 11/70 sits on a separate memory bus. 22 (actually 24, but
> the
> high two lines were never used) address lines, and 32 data lines on that
> address
> bus (plus parity). The memory bus is connected directly to the cache system
> on
> the 11/70.
I assume that you meant to say the the two low order address lines were
never used and that saying the "high two lines were never used" was a
typo, or am I missing something?
Mark Crispin
> Q: So, why does find continue to search the filesystem,
> once it has found the inode "n"?
> A: Because inodes are only unique within a volume,
> and a *NIX filesystem is typically composed of multiple volumes,
> meaning you still can't translate an inum to a path, *uniquely*.
I used "inode number" as a shorthand for "device number and inode number".
The actual thing that most programs are interested in is translation from
file designator to path.
Morten Reistad
So, one of the main thing DEC made to sell had to be produced by knowing,
capable engineers as skunk-works because of bad management.
It was still done, and had tacit approval from management, but they
got back to the party line on several occations, in "important speeches".
This is what I mean that the low-end engineers were really the ones
forming the direction of DEC, the management was utterly clueless.
It is a credit to those engineers that it worked for so long. It
is to the utter detriment of management, and should be put on a
pedestal as a stellar example of non-management.
But the repression is over, no need to use samizdat langauge.
yes, I know what you mean. This is also beaten to death
in literature.
Yes, rank manateurs will write lousy operating system code.
** NEXT **
-- mrr
Eugene Miya
John Byrns <byr...@sbcglobal.net> wrote:
>In article <477d8aed$1@darkstar>, eug...@cse.ucsc.edu (Eugene Miya)
>wrote:
>> In article <byrnsj-3C812D....@newsclstr03.news.prodigy.net>,
>> John Byrns <byr...@sbcglobal.net> wrote:
>> >> >> > 11/55 ....... 780
>> >> >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.
>> >>
>> >> Was a 70 32 or 22 bits?
>> >> That gets into the BBN C/70 being 24 bits
>> >
>> >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
>> >bits as per the PDP-11 architecture. IIRC the 11/45, 11/55, and 11/70
>> >all used the same CPU with different memory systems, and expanded memory
>> >mapping hardware on the 11/70 to accommodate the larger physical memory.
>>
>> See:
>> I'm waiting and so rarely hear those critical trademarks:
>> UNIBUS(tm) and MASSBUS(tm).
>
>Granted that my memory is fading, but I don't remember either the
>UNIBUS(tm) or the MASSBUS(tm) having anything to do with processor to
>memory communication in the 11/70.
If merely processor to memory, you should hear "backplane" at some time.
--
Pete Fenelon
>>Someone had to prop up the market for GEC.... Did the 63/30 have *any*
>>market outside universities running Alvey-funded projects? ;)
>
> 8^)
> You know, that's a good question.
> Do you have any 63/30s?
>
No, my old Department had one, which was pretty much unloved and the
only notable incident in its career was that one of the technicians
broke her ankle when they were finally removing the thing in the early
90s.
> we got a Meiko, and we are in touch with the Computer Conservation
> Society, but people outside the UK are and were so clueless about Alvey
For Universities with the right technical or political connections,
it was a kit bonanza!
I know a few private collectors who have a lot of old UK ex-academic
kit - there was some real exotica out there (as well as vanilla
stuff like PERQs with ICL badges on them ;))
Christopher C. Stacy
> On Fri, 4 Jan 2008, Dennis Ritchie posted:
>>> 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.
>> Not on the PDP-7, but it did on the first PDP-11 system.
>
> A hierarchical filesystem was definitely important, IMHO even more
> important than long file names, and UNIX definitely got it right when
> all of the PDP-10 operating systems got it wrong. I assume that you
> folks picked / because it was easier to type than > on Multics.
There were several native (and networked) file systems on the Lisp
Machine, but the Symbolics "LMFS" is the one I'm interested in here.
Bernie Greenberg (from Multics) was a principal developer.
It had all the reliability and recovery properties that you would like
in the face of the relatively flakey disk hardware of the day.
It was a hierarchical file system whose filenames looked like
">Foo>bar>baz.text.3", with arbitrary name, type, and version numbering.
(You don't need to specify the version number for the latest; you can
also ask for oldest of course.) There were also relative directories
as in Multics. Filesystem nodes have various properties (eg. backup flags),
and you could make up new ones. There were version retention properties,
and Undelete, Expunge, and so on - much like TOPS-20 that way.
File system security was a capability-based system.
Owing to the impossibility of buffer overflows and various other
classes of bugs on the tagged data hardware of the Lisp Machine,
LMFS made for a very secure file server.
> The TOPS-20 community refused to accept the BBN interface for TCP, and
> we got a more natural (to us) filesystem interface. It was
> mind-boggling to us that UNIX, of all operating systems, didn't allow
> you to write (or pipe) to a network printer without the intermediary
> of a program that knew how to do network I/O. [It was one of our few
> "neener-neeners" over the UNIX guys in the 1980s, otherwise our butts
> were getting kicked...]
The Lisp Machine network API was an object-oriented stream interface.
The usual way was to ask for a high-level service (eg. TERMINAL)
on a particular host name, and it would use the distributed name
and service subsystem to resolve that into the most desirable available
combination of network/medium (eg. TCP/IP, CHAOS, DECNET, DNA, etc)
and protocol (TELNET, SUPDUP, etc.) for you, and hand you a stream.
Operations on the stream are the methods available via multiple
inheritence, which includes generic IO and network device control.
There were layers of lower-level interfaces for system programmers.
> The other thing that I'll complain about in the fundamental design of
> UNIX's filesystem is that there is no way to translate from an inode
> (or open designator from the user programmer POV) to a path. I
> understand the issue with hard links, but could have been a linked
> list between the lunk names so you could do the translation (and IMHO
> this is all the more reason that you need this capability). Oh well,
> something to be kept in mind the next time a new operating system is
> designed. [IIRC, NT has this problem too.]
The Lisp Machine allowed the programmer to open any file on any
operating system on any connected network using the remote host's
own native file syntax. (Practically every well-known system and
network and protocol I can think of was implemented.) The first token
in any filename is the host name, followed by a colon, followed by
whatever syntax was appropriate.
It understood in great detail all about filenames on all the operating
systems, allowing the program to manipulate pathname components correctly
using generic operations. Even merging filename components across
operating systems. (An example application is the proper and
intelligent filename completion, including hierarchical wildcard
processing, in the interactive command-line.)
So the programmer just writes
(OPEN "XX:<FRED.DERF>HELLO.TXT")
and that would open up and return a stream to a file on
the TOPS-20 host "XX" (through the generic service interface
described above).
File stream operations are generic.
Some flavors of streams could do more operations.
The semantics are specified based on the generic API
and the remote host's file service.
(Some operations that are not actually supported in the
remote host could be emulated for you on this end; the
distributed service database was used to configure that.
Examples include wildcards and version numbers.)
(The network and file subsystems also had block/buffer protocols
underneath them, if you needed to manually control the IO for
some reason. Applications really just used streams, though.
In some complex network applications, two streams and signalling.)
This "generic function, object-oriented" approach echoes
both the generic device driver protocol of ITS and the
way that Lisp works.
Anyway, to get to the specific point above...
When you have a file stream open, there is a generic operation that
will return the pathname object that opened it. You can also ask for
the "truename", which is the pathname object for the file you got
(which for example would have the actual version number filled in,
or could have chased a symbolic link.)
I've said a mouthful here and left out a zillion details.
In general, the above stuff did all the right things and you can
let your imaginations run wild with correct assumptions.
I'll try to answer any questions as best as I can.
Aside from myriad questions of details that could be raised about
the wild claims above, I could also make some comparisons and
notes about things like pipes and addressing (memory) segments.
But then maybe we should change the subject line.
The time frame of all that stuff, in the incarnation I have described it,
is 1983 (although a lot of it was present in the late 70s).
The Lisp Machine drew heavily from the experience of people who had
developed TENEX, Multics, ITS, and other systems. (I don't think
we ever had any actual Bell Unix people aboard, but certainly all
were familiar with Unix, and a few of the people had done some
development on the Berkeley fork.)
Quadibloc
> I assume that you meant to say the the two low order address lines were
> never used and that saying the "high two lines were never used" was a
> typo, or am I missing something?
If the two low address lines were never used, then only one of every
four words in memory would have been accessible.
If the hardware accessed 32 bits of data at a time, and addresses were
byte addresses, the two low-order bits of the address would not have
been brought out to the address bus (except for use with I/O devices
perhaps), so this wouldn't be referred to as never using the two low-
order address lines.
Not using the high-order addressing lines can happen when a system's
memory expansion capabilities are not increased enough to use up the
effective physical address space. You could design a computer when 1
Kbyte memory chips are available to have enough address lines to work
with memory boards using 16 Kbyte memory chips... but then end up
bringing out a memory board for it with 4 Kbyte memory chips only, the
system being too obsolete by the time 16 Kbyte memory chips are
available. (The extra address lines are to get customers to buy the
computer in the belief their investment is secure, but then making new
memory boards for an old computer is less profitable than getting
everyone to buy a new computer. At least this is how PC makers today
seem to work, even if DEC may not have behaved like that.)
John Savard
John Byrns
wrote:
And also flat cables of some sort because the processor and memory were
in separate cabinets.
Joe Pfeiffer
>
> I used "inode number" as a shorthand for "device number and inode
> number". The actual thing that most programs are interested in is
> translation from file designator to path.
I'll agree that the fact files don't necessarily have unique paths is
a design flaw; it's unfortunate that when symbolic links were
introduced multiple hard links didn't go away.
Eugene Miya
>>>>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
>>>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.
In article <6kullf....@eden.reistad.name>,
Morten Reistad <fi...@last.name> wrote:
>In article <fllfn8$8qk...@s830.apx1.sbo.ma.dialup.rcn.com>,
> <jmfb...@aol.com> wrote:
>>You are wrong, Morten. I knew that large part of our success was
Morten is right.
>>because of the software we furnished. It was Gordon Bell who
>>refused to acknowledge that software was important and that it
>>was becoming more important than the hardwarre. That last piece
>>is what caused him to remove all software "threats" to the hardware
>>business.
>>
>>Since he was the VP of engineering, we had to work under his aegis.
Of course, you are merely following orders.
Well Fred Brooks of IBM recanted some of his Unix ideas. Gordon did, too.
I've seen Gordon and others note that even Unix or windows operating
systems work has stagnated.
>>My attitude is, and was, the TOPS-10 attitude. TOPS-10's products
>>reflected this attitude. The reason the 10 had this attitude
>>is because it primary developers had the attitude. We understood
>>that software was the grease that made the creaky hardware work
>>as best as it could work.
And of course the 10/20 line, much less the 11/VAX line could do no wrong.
>So, one of the main thing DEC made to sell had to be produced by knowing,
>capable engineers as skunk-works because of bad management.
>
>It was still done, and had tacit approval from management, but they
>got back to the party line on several occations, in "important speeches".
>
>This is what I mean that the low-end engineers were really the ones
>forming the direction of DEC, the management was utterly clueless.
>It is a credit to those engineers that it worked for so long. It
>is to the utter detriment of management, and should be put on a
>pedestal as a stellar example of non-management.
People make light of Watson's small numbers comment (or Gates or Olsen).
In Watson's case, over time I've come not to blame him, I think it was
his engineers whom were more in a state of denial. You have to blame
both managers and engineers for missing things. DEC and IBM blew
various projects and in DEC's case the farm. Numerous named and unamed
firms did stupid things. There's a whole family tree at attempts to
make 16 bit minis. And other machines.
>But the repression is over, no need to use samizdat langauge.
Agreed here.
>>>>>Xerox management
>>>>
>>>>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.
>>
>>Consider a personality trait where the person has to control
>>all aspects of a thing. When writing OS code this type
>>of personality will be annoyed, irritated, and dismissive
>>of an interruption. So the code won't reflect true timesharing
>>which is event-based. You would tend to see an OS that is
>>task-based instead. An interruption would be put on list
>>to be dealt with after the current task is 100% finished.
>
>yes, I know what you mean. This is also beaten to death
>in literature.
I'm not fully clear what Barb means.
Barb is big on self-flagelation. I'd tell that OS designer to take off
and play computer games for a while. I can't see how some people can
code pissed off, just like code "under the influence" tends not to be
consistent code. I'm not clear about true time sharing, and event vs.
task based. She like interrupts. She's out of the polled I/O community.
Her bias.
>Yes, rank manateurs will write lousy operating system code.
>** NEXT **
Not a bad box for its time. The Web is based on it.
Jobs deserves credit for it.
--
Al Kossow
>> I know a few private collectors who have a lot of old UK ex-academic
>> kit - there was some real exotica out there (as well as vanilla
>> stuff like PERQs with ICL badges on them ;))
>
> Well we have Perqs.
We DON'T have Perq software, or any Perq 2's or later, Eugene.
--
Posted via a free Usenet account from http://www.teranews.com
Eugene Miya
>>>market outside universities running Alvey-funded projects? ;)
In article <45e255-...@fenelon.com>,
Pete Fenelon <pe...@stratos.fenelon.com> wrote:
>No, my old Department had one, which was pretty much unloved and the
>only notable incident in its career was that one of the technicians
>broke her ankle when they were finally removing the thing in the early
>90s.
Find us one. We can either get it here or Bletchley.
>> we got a Meiko, and we are in touch with the Computer Conservation
>> Society, but people outside the UK are and were so clueless about Alvey
>
>For Universities with the right technical or political connections,
>it was a kit bonanza!
They never returned my phone calls for purchasing information.
Surprised me whhen LLNL got one. No one to my knowledge ever got any
real work done on it. I did like my Butterfly/Monaarch/TC2000 account.
>I know a few private collectors who have a lot of old UK ex-academic
>kit - there was some real exotica out there (as well as vanilla
>stuff like PERQs with ICL badges on them ;))
Well we have Perqs. We are OK for them. Offer them to Bletchey.
--
Eugene Miya
>>> kit - there was some real exotica out there (as well as vanilla
>>> stuff like PERQs with ICL badges on them ;))
>> Well we have Perqs.
In article <477eaf5c$0$26112$8826...@free.teranews.com>,
Al Kossow <a...@spies.com> wrote:
>We DON'T have Perq software, or any Perq 2's or later, Eugene.
Go after the software Al.
I am tasked to go after other things.
--
glen herrmannsfeldt
(I wrote)
>>I presume you don't count
>>find / -inum n
> Q: So, why does find continue to search the filesystem,
> once it has found the inode "n"?
I think it is fundamental to find that it continue on unless
told to stop.
> A: Because inodes are only unique within a volume,
> and a *NIX filesystem is typically composed of multiple volumes,
> meaning you still can't translate an inum to a path, *uniquely*.
Yes, one should search starting at the appropriate mount point.
It gets more interesting with NFS running, too.
-- glen
Morten Reistad
>>>>>>My God, hell must be freezing over.
>
>In article <6kullf....@eden.reistad.name>,
>Morten Reistad <fi...@last.name> wrote:
>>In article <fllfn8$8qk...@s830.apx1.sbo.ma.dialup.rcn.com>,
>> <jmfb...@aol.com> wrote:
>>>You are wrong, Morten. I knew that large part of our success was
> Morten is right.
>>>because of the software we furnished. It was Gordon Bell who
>>>refused to acknowledge that software was important and that it
>>>was becoming more important than the hardwarre. That last piece
>>>is what caused him to remove all software "threats" to the hardware
>>>business.
>>>
>>>Since he was the VP of engineering, we had to work under his aegis.
>
>Of course, you are merely following orders.
>
>Well Fred Brooks of IBM recanted some of his Unix ideas. Gordon did, too.
>I've seen Gordon and others note that even Unix or windows operating
>systems work has stagnated.
Well, the Linux project is done. An open, extensible, all-round
platform suited for the desktop, server and development
environments. Based on the Unix/Posix api, but with adoptions of all
the major other platforms like Gnu, KDE, OpenGL, ALSA, BSD, KAME, Elf,
Internet tools, nfs/nis, mozilla, mysql, etc etc. With Ubuntu as the
finishing touch on design; and the 2.6 kernel, and the 4.x set of gcc
& toolchain the project is pretty much finished.
This has stabelised the development world, and brought all the tools
out into the open.
So, the interesting stuff is not happening on the desktop anymore.
The interesting stuff happens on all the small devices; which we will
literally have hundreds off to surround us. I expect there to be an
Internet for these soon; just as the desktops languished for a decade
in isolation, the small gadgets have been living in isolation for way
too long.
>
>>>My attitude is, and was, the TOPS-10 attitude. TOPS-10's products
>>>reflected this attitude. The reason the 10 had this attitude
>>>is because it primary developers had the attitude. We understood
>>>that software was the grease that made the creaky hardware work
>>>as best as it could work.
>
>And of course the 10/20 line, much less the 11/VAX line could do no wrong.
>
>>So, one of the main thing DEC made to sell had to be produced by knowing,
>>capable engineers as skunk-works because of bad management.
>>
>>It was still done, and had tacit approval from management, but they
>>got back to the party line on several occations, in "important speeches".
>>
>>This is what I mean that the low-end engineers were really the ones
>>forming the direction of DEC, the management was utterly clueless.
>>It is a credit to those engineers that it worked for so long. It
>>is to the utter detriment of management, and should be put on a
>>pedestal as a stellar example of non-management.
>
>People make light of Watson's small numbers comment (or Gates or Olsen).
>In Watson's case, over time I've come not to blame him, I think it was
>his engineers whom were more in a state of denial. You have to blame
>both managers and engineers for missing things. DEC and IBM blew
>various projects and in DEC's case the farm. Numerous named and unamed
>firms did stupid things. There's a whole family tree at attempts to
>make 16 bit minis. And other machines.
>
>>But the repression is over, no need to use samizdat langauge.
>
>Agreed here.
The biggest lesson is that the management of forefront technology
firms must be visionaries, or they will falter, and the back pressure
from their investors and customers will overwhelm them.
Forefront tech companies _must_ lead the customers. MS & Apple are
doing this. You see the examples of this in the automotive world.
Honda & Toyota are leading their customers, and are winning big in
a world where change now must happen fast. The US and German firms
are clueless to what is happening around them. The french and other
europeans are caught in the middle, and have got the message, but have
an execution problem.
>>>>>>Xerox management
>>>>>
>>>>>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.
>>>
>>>Consider a personality trait where the person has to control
>>>all aspects of a thing. When writing OS code this type
>>>of personality will be annoyed, irritated, and dismissive
>>>of an interruption. So the code won't reflect true timesharing
>>>which is event-based. You would tend to see an OS that is
>>>task-based instead. An interruption would be put on list
>>>to be dealt with after the current task is 100% finished.
>>
>>yes, I know what you mean. This is also beaten to death
>>in literature.
>
>I'm not fully clear what Barb means.
>Barb is big on self-flagelation. I'd tell that OS designer to take off
>and play computer games for a while. I can't see how some people can
>code pissed off, just like code "under the influence" tends not to be
>consistent code. I'm not clear about true time sharing, and event vs.
>task based. She like interrupts. She's out of the polled I/O community.
>Her bias.
She has had an upbringing on scalable systems. You code robust state
machines, data driven systems, and leave the imperative coding model.
This was the mental change that brought us good gui's, telecom systems etc.
>>Yes, rank manateurs will write lousy operating system code.
>
>
>>** NEXT **
>
>Not a bad box for its time. The Web is based on it.
>Jobs deserves credit for it.
The web may have had it's roots in the Next, but is has moved on
a long time ago.
Take this from someone who once participated in declining world
wide exclusive rights for http and html.
-- mrr
Charles Richmond
In the book _The Magic Garden Explained_, there is a foreword
which tells the story of how the first UNIX was brought up at
an Australian university. I found it very interesting...
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
Johnny Billquist
Yes. A22 and A23 do exist on the memory bus, but the 11/70 don't use them. But
you could in theory make another CPU that used the same memory bus, with 16Meg.
It's also interesting to note that atleast RSX has provisions for a coarser page
address granularity. Normally it's 64bytes, but RSX can handle 256Byte
granularity in the system calls as well, even though there is no real point for
it. But if you had shifted the PAR register up two bits, you'd have use for A22
and A23, and you'd have 256Byte granularity.
Someone at DEC was thinking about possible extensions of the PDP-11 back then...
But I guess they decided that 4M was enough.
Also, I should check this up better, but I think that A0 and A1 also is used.
The CPU never reads less than 32 bits, but writes can be shorter. The cache
system will gate the byte into the appropriate part of the 32-bit word, but I
think it puts out the actual byte address on the memory bus, along with some
control signals, so that the right byte(s) are gated to the memory, and the rest
remain as before.
(My memory is a bit hazy, it was a couple of years since I last needed to look
at this.)
Johnny Billquist
Well, on all Unibus PDP-11s except the 11/70, "backplane" is equivalent to
"Unibus". :-)
Mike Ross
>The British were the guys who desparately wanted 10s and 20s.
>It was their govt. who preventing them from buying many.
I don't buy that. Somewhere, I have the DECUS UK 10/20 SIG list of sites in
operation; somewhen I'll scan it and publish it.
What makes you think the British govt. had any say in what machines got bought?
Mike
--
http://www.corestore.org
'As I walk along these shores
I am the history within'
Mike Ross
wrote:
>"Dennis Ritchie" <d...@bell-labs.com> writes:
>
>> "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.
>
>And all that software is presumably long gone along with the PDP-7 version.
>Oh, well.
Rich: I wouldn't give up hope. Dennis: I seem to remember an email discussion
from a few years ago where you told me there was a ?printed listing? of the
PDP-7 source buried somewhere which really should be scanned? Or am I suffering
from bit-rot?