The Perfect Computer - 36 bits?
|
From: Nick Maclaren on 28 Mar 2007 04:40 In article <mdd7it2xsdl.fsf(a)panix5.panix.com>, Rich Alderson <news(a)alderson.users.panix.com> writes: |> |> > The PDP-11 never made much impact as a 'general' computer, especially |> > in the commercial arena, whereas the PDP-10 and PDP-20 did. |> |> Point of order: There is no such thing in the DEC/Digital product line as a |> "PDP-20". The highest number in the PDP series was the PDP-16. |> |> 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, 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/). Thank you for the correction - I always thought that a PDP-20 was some sort of a tweak of the PDP-10, but never used either personally. It ain't what you know that causes the trouble, .... Regards, Nick Maclaren.
From: Nick Maclaren on 28 Mar 2007 04:42 In article <4609993a$0$18859$4c368faf(a)roadrunner.com>, Peter Flass <Peter_Flass(a)Yahoo.com> writes: |> > |> > 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. |> |> I, as a programmer, shouldn't have to worry about ordering the |> instructions so as not to lose cycles (pipeline slots, whatever.) |> That's what hardware/microcode is for. Indeed. Simple, high-level, constraints are one thing, but the arcane rules on instruction ordering are another. I was actually thinking of worse problems, such as exception handling and memory consistency, but the above also applies. Regards, Nick Maclaren.
From: Nick Maclaren on 28 Mar 2007 04:46 In article <46099a6a$0$18859$4c368faf(a)roadrunner.com>, Peter Flass <Peter_Flass(a)Yahoo.com> writes: |> |> > |> Yeah I seem to recall there being a couple of PDP11s hooked to a |> > |> 370 in the early 1980s (and late 1970s) not far from you. |> > |> > Yup :-) And we weren't the only such site, because those mainframes |> > were dire for single-character interactions and related communications |> > work and peripheral driving. |> |> Series-1's were also in this market. IBM sold them with an IUP as a |> terminal driver. "Yale ASCII" or something like that. I know. My point stands. While it is an over-simplification, the Series-1 was very much an SNA engine, and lived or died with that. Despite IBM's belief, SNA never made much headway into the scientific markets, and didn't make as much even in the commercial ones as they claimed. I can't remember if the Series-1 ever did support the 'X.' protocols, but it may have done (probably too little, too late). Regards, Nick Maclaren.
From: Nick Maclaren on 28 Mar 2007 04:51 In article <1175040218.850087.297730(a)n76g2000hsh.googlegroups.com>, "David Kanter" <dkanter(a)gmail.com> writes: |> On Mar 27, 10:50 am, Andrew Swallow <am.swal...(a)btopenworld.com> |> wrote: |> |> > We can certainly have a nice debate as to whether anything containing |> > floating point hardware is RISC. |> |> You are certainly welcome to have that debate, but I doubt anyone will |> take you seriously. The benefits of FP are rather evident. But whether it is RISC is less so :-( A couple of decades ago, I pointed out that it could perfectly well be implemented by the ISA providing suitable primitives for emulating it in software, with a considerable increase in functionality. That blew the mind of a lot of numerical people, but was true; for example, the Alpha typically had enough spare cycles to do it, even on numerical codes. The reason that has never been done (Crusoe etc. possibly excepted) is that it can't compete on benchmarketing and for the most extreme number-crunching codes. The latter are very rare even in HPC. Regards, Nick Maclaren.
From: Nick Maclaren on 28 Mar 2007 04:54
In article <1175042659.644301.148050(a)o5g2000hsb.googlegroups.com>, "Quadibloc" <jsavard(a)ecn.ab.ca> writes: |> |> > 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. |> |> I'll certainly agree that RISC doesn't have to be like the Itanium. While the Itanium is significantly the worst, all of the Alpha, SPARC and MIPS were very bad in at least some respects. I never looked at the PowerPC or newer ARMs in enough detail to be certain of that; older ARMs plain didn't support many of the facilities I am referring to. Regards, Nick Maclaren. |