The Perfect Computer - 36 bits?
|
From: jmfbahciv on 29 Mar 2007 08:26 In article <eue678$7sq$1(a)south.jnrs.ja.net>, david20(a)alpha2.mdx.ac.uk wrote: >In article <RoWdnSbeC5-WwJfbnZ2dnUVZ8saonZ2d(a)bt.com>, Andrew Swallow <am.swallow(a)btopenworld.com> writes: >>jmfbahciv(a)aol.com wrote: >>> In article <k8idnfPPHuSawZTbRVnyjAA(a)bt.com>, >>> Andrew Swallow <am.swallow(a)btopenworld.com> wrote: >>>> krw wrote: >>>>> In article <DZSdnaHeS49TzpTbnZ2dnUVZ8tXinZ2d(a)bt.com>, >>>>> am.swallow(a)btopenworld.com says... >>>>>> krw wrote: >>>>>>> In article <fqWdnV-JLsRJ_ZXbRVnyiAA(a)bt.com>, >>>>>>> am.swallow(a)btopenworld.com says... >>>>>>>> Morten Reistad wrote: >>>>>>>> [snip] >>>>>>>> >>>>>>>>> DEC _did_ come back with the alpha, just as soon as they had managed >>>>>>>>> to deVAXify their brains. Except, by then the trust in the company had >>>>>>>>> evaporated. >>>>>>>> The only sensible use for the Alpha was to run microcode as a VAX. >>>>>>>> When chip manufacturing technology allowed CISC CPUs on a single chip >>>>>>>> the cost advantages of RISC were over. >>>>>>> I think you'll find there are a few people who will disagree with >>>>>>> you. >>>>>>> >>>>>> Probably but were they customers of DEC? >>>>> Every Alpha ran VAX microcode? Dunno, never seen a real live Alpha. >>>>> >>>> The Alpha was the replacement for the VAX, so a lot of the software >>>> running on the Alpha was VAX/VMS software. The software was either >>>> recompiled or run using a software emulators. >>> >>> I have a plaque given to JMF for his Alpha work. It is customary >>> for applications to be recompiled when going from one architecture >>> to another. This is a fact today. >>> >>>> So a 500 MHz Alpha >>>> ran like a 50 MHz VAX with expensive ram. >>> >>> YOu are grasping at straws. The emulator was a method to help >>> customer go from one architecture to the other. >>> I'm coming to the conclusion that you are not interested in learning >>> a damned thing. >> >>No. I am telling you how DEC committed suicide. >> >>The customers did not ask to change architectures. > >In effect they did. >VAX/VMS systems cost a lot more but provided worse performance than the >competive RISC based UNIX systems. Hence many customers were moving to those >competitors. >Although DEC could have lowered it's prices it was difficult to see how to >increase VAX performance in the long term to compete. >DEC also wanted to move from 32bit to 64bit. >Hence it made sense to move from VAX to the RISC based 64bit ALPHA. > >Note. DEC didn't just drop the VAX. Indeed the NVAX+ systems which came out at >the same time as the Alphas really pushed VAX performance but it was still >worse than Alpha. >The only real problem with the migration from VAX to ALPHA were > >1) The decision to have radically different VMS code-bases which made porting > new Alpha features back to VAX extremely difficult. >2) The dropping of lots of layered software products which were simply not > ported across to Alpha. >3) The lack of an adequate migration path for their Unix users. > >In a fair number of instances VAX users could fund their move to Alpha out of >maintenance savings on their old VAX systems. >However if they didn't want to move to Alpha DEC provided new VAX systems for a >a long period after Alpha was established. > > >Contrast this to HP's(/Compaq's) move of the DEC customers to Itanium > >1) Alpha development killed off before any systems running on Itanium >2) Itaniums perceived as slower than Alphas >3) Tru64 killed off. Features of Tru64 promised to be incorporated in HP-UX. > Features NOT incorporated in HP-UX. >4) Alpha end of sale date announced without consideration being given to > how many important software products had yet to be ported to Itanium. > eg ORACLE for VMS was still not ported a month before the end of sale date. > (End of sale date then extended a while after the previous end of sale date > had passed. End of sale is now end of April this year). This was the exact scenario that was done with TOPS-10. TOPS-10 on the PDP-10 was the corporation's workhorse product. The Alpha running VMS was an equivalent product. (I base this on listening to the customers who used the product--IOW, real facts.) > >About the only good thing that they learned from DEC was that Alpha and Itanium >have the same VMS codebase. <snip> /BAH
From: david20 on 29 Mar 2007 08:37 In article <9gal035ncoglbdnvkd8m7odgl59o2opg9b(a)4ax.com>, David Powell <ddotpowell(a)icuknet.co.uk> writes: >In article <Stydndude4YPyJTbRVnygAA(a)bt.com>, > Andrew Swallow <am.swallow(a)btopenworld.com> in >alt.folklore.computers wrote: > >>jmfbahciv(a)aol.com wrote: > > [big snip here] > >>>> We are talking LSI-11 vs 8086. Even if DEC did not sell to the consumer >>>> market the $1000 business computer on every desk market is enormous. >>> >>> And I'm telling you, again, that DEC did not have the infrastructure >>> to handle that support. DEC's main business was not retail-ish. >> >>Neither did IBM, so IBM created a new distribution infrastructure. >> > >Do you remember Hamilton Rentals, or Rapid Recall? They were the two >distributors appointed by DEC (United Kingdom) in the early 1980s to >sell the small LSI-11 etc stuff. > Hamilton Rentals still exists see http://www.hamilton.co.uk It's now part of the Compel group. David Webb Security team leader CCSS Middlesex University >>DEC sold to the technical part of companies - so the salesmen, >>warehouses and trucks needed in the first year existed. >> > >Trucks with tail-lifts to move VAXes, LSI-11 stuff came in small >cardboard boxes delivered by the postman on his pushbike. :) > >Regards, > >David P. >
From: jmfbahciv on 29 Mar 2007 08:30 In article <571q42F2acqvnU1(a)mid.individual.net>, =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen(a)not-mediasec.de> wrote: >[Good and fair, IMO, description of the VAX->Alpha and Alpha->Itanium transitions] > >> About the only good thing that they learned from DEC was that Alpha and Itanium >> have the same VMS codebase. > >However, that was only possible because of the earlier VAX-to-Alpha port, >which had made sure that the VAXism-infested VAX/VMS codebase was transformed >into something much more portable. Also, the concepts on how to handle the 32- >to 64-bit transition gracefully had already been validated. And some of that work was done by JMF, the other half of my username. It took those with TOPS-10 experience to cause VMS to evolve to be an OS that was useful. (The work wasn't jsut JMF's but the whole contingent of PDP-10 developers who moved to the 32-bit world after the 36-bits were cancelled.) /BAH /BAH
From: jmfbahciv on 29 Mar 2007 08:31 In article <ih8n03puv0jbp4i04l9vh225qa96luaf94(a)4ax.com>, Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote: >fOn Wed, 28 Mar 2007 12:53:35 +0100 in alt.folklore.computers, Andrew >Swallow <am.swallow(a)btopenworld.com> wrote: > >>jmfbahciv(a)aol.com wrote: >>> In article <eubp25$628$1(a)gemini.csx.cam.ac.uk>, >>> nmm1(a)cus.cam.ac.uk (Nick Maclaren) wrote: >>>> In article <DZSdnaHeS49TzpTbnZ2dnUVZ8tXinZ2d(a)bt.com>, >>>> Andrew Swallow <am.swallow(a)btopenworld.com> writes: >>>> |> krw wrote: >>>> |> > In article <fqWdnV-JLsRJ_ZXbRVnyiAA(a)bt.com>, >>>> |> > am.swallow(a)btopenworld.com says... >>>> |> >> Morten Reistad wrote: >>>> |> >> >>>> |> >> The only sensible use for the Alpha was to run microcode as a VAX. >>>> |> >> When chip manufacturing technology allowed CISC CPUs on a single chip >>>> |> >> the cost advantages of RISC were over. >>>> |> > >>>> |> > I think you'll find there are a few people who will disagree with >>>> |> > you. >>>> |> > >>>> |> Probably but were they customers of DEC? >>>> >>>> Yes. >>> >>> What is it with this kid? I had so many woe-is-mes from customers >>> about having to move to Micshits' stuff at that time. And I >>> was not privy to the insides. These were people who I'd met on >>> the newsgroups. >> >>The alternatives to the Alpha were VAX/VMS and PDP-11s not X86. > >.... and SGI, Sun, IBM, Amdahl, Fujistu, Hitachi. VAX was not an alternative. It was shortterm. /BAH
From: jmfbahciv on 29 Mar 2007 08:36
In article <mdd7it1m6wj.fsf(a)panix5.panix.com>, Rich Alderson <news(a)alderson.users.panix.com> wrote: >jmfbahciv(a)aol.com writes: > >> In article <mdd7it2xsdl.fsf(a)panix5.panix.com>, >> Rich Alderson <news(a)alderson.users.panix.com> wrote: > >>> Some people believe that if the PDP-10 ran Tops-10, then a machine running >>> Tops-20 must be a PDP-20, but the reasoning is flawed. Modulo some >>> differences in I/O, > >> I can't think of any; what were you thinking of? > >Tops-20 doesn't know how to talk to disks on the I/O bus, only the RH20 (for >example). I think the only I/O bus peripheral it could talk to was an ARPA >IMP, but I may misremember how that was connected to the -20. But none of the gear was sold on a short cabinet system. You could run TOPS-10 on any PDP-10; you couldn't run TOPS-20 on any PDP-10 :-). This was a point that DEC customers didn't miss even though people in DEC wouldn't see. >>> either operating system will run on the same hardware. I call to your >>> attention the bright orange box labeled "DECSYSTEM-20" on which I run >>> Tops-10 for the PDPplanet project (http://www.pdpplanet.org/). > >> We used the same machine for stand alone for both OSes. The same >> was true for the KS CPU model. This was done on purpose. > >Yes, and I'm very happy with Tops-10 on the 2065. I just wish you could have luxury of getting the feel of our SMP implementation. That will never happen. BEcause of this I will be having this discussion again and again. /BAH |