The Perfect Computer - 36 bits?
|
From: Nick Maclaren on 27 Mar 2007 04:43 In article <byrnsj-FDFD08.19484226032007(a)newsclstr02.news.prodigy.com>, John Byrns <byrnsj(a)sbcglobal.net> writes: |> |> I always thought DEC should have extended the PDP-11 to 32 bits and |> skipped the VAX. The PDP-11 was a very elegant design whose fatal flaw |> was its 16 bitness, while the VAX seemed overly complex to me. The PDP-11 never made much impact as a 'general' computer, especially in the commercial arena, whereas the PDP-10 and PDP-20 did. The VAX was intended to capture the latter market and, in the research arena, it did. |> I can't |> remember how I thought DEC should have gone about extending the PDP-11 |> instruction set to 32 bits, I guess that gives me a second chance to |> think about it. Do you know what the proposals were at the time for how |> the PDP-11 instruction set could have been extended to 32 bits? No. And the ISA was irrelevent for the purposes I mean - it was the design and functionality that mattered. Regards, Nick Maclaren.
From: Quadibloc on 27 Mar 2007 06:45 David Kanter wrote: > On Mar 26, 5:09 pm, Andrew Swallow <am.swal...(a)btopenworld.com> wrote: > > 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. > > That's entirely untrue, and ridiculous to boot. Anyone who has > actually designed a CPU will tell you that there is an extra cost > associated with CISCy architectures. All things being equal, I've > heard estimates from those who would know (i.e. have implemented both > CISC and RISC) as being in the 20-30% neighborhood. Currently, any > possible performance delta is more than outweighed by the fact that > x86 gets access to cutting edge processes a year in advance of every > RISC familiy. .. There is an extra cost associated with RISC architectures too; code density tends to be lower. The main reason *for* RISC architectures is their lower development costs. With a few small exceptions - such as IBM making chips for its z/Architecture machines - everyone out there who is producing non-x86 microprocessors is using a RISC architecture for that reason. I find this sad, as I would have liked to have a relatively elegant and clean, but conventional, microprocessor available, such as the 68020 architecture. ColdFire omits indexed memory access, which means it omits too much. John Savard
From: Nick Maclaren on 27 Mar 2007 07:08 In article <1174992323.115637.216890(a)p15g2000hsd.googlegroups.com>, "Quadibloc" <jsavard(a)ecn.ab.ca> writes: |> David Kanter wrote: |> > |> > That's entirely untrue, and ridiculous to boot. Anyone who has |> > actually designed a CPU will tell you that there is an extra cost |> > associated with CISCy architectures. All things being equal, I've |> > heard estimates from those who would know (i.e. have implemented both |> > CISC and RISC) as being in the 20-30% neighborhood. Currently, any |> > possible performance delta is more than outweighed by the fact that |> > x86 gets access to cutting edge processes a year in advance of every |> > RISC familiy. |> . |> There is an extra cost associated with RISC architectures too; code |> density tends to be lower. |> |> The main reason *for* RISC architectures is their lower development |> costs. With a few small exceptions - such as IBM making chips for its |> z/Architecture machines - everyone out there who is producing non-x86 |> microprocessors is using a RISC architecture for that reason. |> |> I find this sad, as I would have liked to have a relatively elegant |> and clean, but conventional, microprocessor available, such as the |> 68020 architecture. ColdFire omits indexed memory access, which means |> it omits too much. There is no reason that a RISC architecture cannot have a clean ISA, and there is no particular reason for saying that indexed access must be built-in to the basic instruction format. While needing a separate instruction for indexing makes the code bulkier, that hasn't been a major issue for over a decade. It is a great pity that the new RISC systems (as distinct from previous inventions of the approach) concentrated entirely on making the hardware simple, often at the cost of making the software hell to get right. Which is one of the reasons that many aspects of modern software are so much worse than they were 25 years ago. It wasn't, and it isn't, necessary. Regards, Nick Maclaren.
From: jmfbahciv on 27 Mar 2007 07:03 In article <eu938g$9t7$1(a)gemini.csx.cam.ac.uk>, nmm1(a)cus.cam.ac.uk (Nick Maclaren) wrote: > >In article <56qh33F29t3i0U1(a)mid.individual.net>, >Del Cecchi <cecchinospam(a)us.ibm.com> writes: >|> >|> They probably would have run out of pdp-8 and pdp-11 customers sooner or >|> later. And by the early 80's I would think those systems were in the >|> down part of the lifecycle. > >Unclear. PDP11s dominated the (computer) communications in the early >1980s, even in many sites with System/370 mainframes! They were run >for many years after their official demise, because they were just SO >much better for the purpose than anything else. > >What DEC should have done (and was told so at the time) was to produce >a 32-bit PDP11, specialised for such purposes, and capture the computer >communication market. This would have been a completely separate range >from the VAX, but would have needed very little software support, and >not all that much in the way of peripheral support. Yup. Those people were killing off the cash cows. I never understood why. Query: Do you think the 8's could have been sold as a radio Shack item for you hardware kiddies who were playing back then? I always thought a child's "piano" connected to an -8 and the appropriate lights would have made a very popular toy. The toggles would have been the keys, of course. /BAH
From: jmfbahciv on 27 Mar 2007 07:05
In article <byrnsj-FDFD08.19484226032007(a)newsclstr02.news.prodigy.com>, John Byrns <byrnsj(a)sbcglobal.net> wrote: >In article <eu938g$9t7$1(a)gemini.csx.cam.ac.uk>, > nmm1(a)cus.cam.ac.uk (Nick Maclaren) wrote: > >> In article <56qh33F29t3i0U1(a)mid.individual.net>, >> Del Cecchi <cecchinospam(a)us.ibm.com> writes: >> |> >> |> They probably would have run out of pdp-8 and pdp-11 customers sooner or >> |> later. And by the early 80's I would think those systems were in the >> |> down part of the lifecycle. >> >> Unclear. PDP11s dominated the (computer) communications in the early >> 1980s, even in many sites with System/370 mainframes! They were run >> for many years after their official demise, because they were just SO >> much better for the purpose than anything else. >> >> What DEC should have done (and was told so at the time) was to produce >> a 32-bit PDP11, specialised for such purposes, and capture the computer >> communication market. This would have been a completely separate range >> from the VAX, but would have needed very little software support, and >> not all that much in the way of peripheral support. > >I always thought DEC should have extended the PDP-11 to 32 bits and >skipped the VAX. No. The VAX was the DEC's answer to perceived need for an agility w.r.t. byte manipulation. The KL BIS didn't work well. > The PDP-11 was a very elegant design whose fatal flaw >was its 16 bitness, while the VAX seemed overly complex to me. I can't >remember how I thought DEC should have gone about extending the PDP-11 >instruction set to 32 bits, I guess that gives me a second chance to >think about it. Do you know what the proposals were at the time for how >the PDP-11 instruction set could have been extended to 32 bits? I can't answer this. /BAH |