The Perfect Computer - 36 bits?
|
From: Andrew Swallow on 29 Mar 2007 15:45 krw wrote: > In article <Mu2dnV2jQ7yzn5HbnZ2dnUVZ8ternZ2d(a)bt.com>, > am.swallow(a)btopenworld.com says... >> Jan Vorbr�ggen wrote: >> [snip] >> >>> They do, and VMS is still being actively developed. AFAIK, even the >>> Alpha is not only being supported but being actively developed. Even >>> VAX/VMS was being updated, not just supported, just a few years ago. A >>> significant number of people a running VMS virtual machines on their PCs >>> because they never ported their applications to something else. It seems >>> likely that these VMs are the fastest VAXen ever built 8-). >>> >>> Jan >> Hmmm. If the VAX and ALPHA instruction sets are now public source then >> clones can be made. Using a PC or Apple bus permits off the shelf ram >> modules and disk drives can be purchased. Writing the CPUs in C or VHDL >> will allow them to be tested on a FPGA and manufactured as ASICs. >> Recompiling the ASIC every 18 months will permit the processor board to >> speed up as the chip foundries reduce gate sizes. > > You make processor development sound so simple. Why do you need to > make an FPGA model? Simulations tell you everything you need to > know, likely faster for less money. There will things that > simulations may not find but there is no reason to believe that an > FPGA model will find them any faster/better. > Simulators cannot talk to PC buses etc FPGAs can. There will be things in there that are not in the documentation. >> A CPU on an ASIC will be able to match block move instructions performed >> by the emulator, other instruction should be 5 to 10 times faster. > > ASIC is the wrong answer. AFAIK all processors today are custom > chips. > >> To keep the general public happy running programs by clicking a mouse >> will be needed. Someone is going to have fun converting clerical >> software like OpenOffice. New native mode device handlers will need >> writing to support the standard peripherals. A way of emulating the PC >> which allows device handlers written in X86 to run thereby permits users >> to buy other hardware modules in the shops. >> >> VAX/VMS the reliable alternative to Windows PCs. > > You're dreaming. That bus left a long time ago. Probably, it is Linux that will have to clean up the mess Microsoft makes. Andrew Swallow
From: Frank McCoy on 29 Mar 2007 16:17 In alt.folklore.computers Toon Moene <toon(a)moene.indiv.nluug.nl> wrote: >Jan Vorbrüggen wrote: > >> > Not having source *or* fiche made me very nervous. >> >> Ah yes, and now think about all those business- and safety-critical >> customers of the Microsoft operating systems... >> >> Jan >> >> PS: For those OSes, quite likely even having the source wouldn't help >> you much... > >I seem to recall that Microsoft was telling the European Community's >competition court that the source *was* the documentation. I don't know about Micro$haft in that matter; but I do recall some people claiming (in more than one company I worked for) that the source-code for a particular program WAS the documentation ... because it was that well commented. (BTW: It wasn't. It was *supposed* to be; but, like always, people ran behind schedule, management pushed, and you can guess what part of the program got put off "until we get this finished". And then, again of course, there wasn't any time or money left to do the documentation; because it was scheduled and budgeted to [supposedly] be done during the coding phase.) Ayup! After that, I learned *never* to put off commenting code "to be done later". Because "later" never ever comes. -- _____ / ' / ™ ,-/-, __ __. ____ /_ (_/ / (_(_/|_/ / <_/ <_
From: Stephen Fuld on 29 Mar 2007 16:29 Rich Alderson wrote: > Stephen Fuld <S.Fuld(a)PleaseRemove.att.net> writes: > >> jmfbahciv(a)aol.com wrote: >>> In article <571ro8F2bdosvU1(a)mid.individual.net>, >>> =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen(a)not-mediasec.de> wrote: >>>>> Only for small problems. What do you do in the cases where a >>>>> reassembly is the way to make the problem go away? >>>> Do a complete SYSGEN? >>> Yes. >> >> Was there no alternative between patching the object code and doing a >> complete sysgen? On the system with which I am most familiar (Non-DEC), >> we mostly did partial sysgens where only a small number of modules were >> re-assembled and the system linked. Out of say 400 modules in the OS, a >> typical gen might assemble half a dozen and a large one perhaps a >> hundred. We did full gens (all elements), very rarely. > > A quick look at http://pdp-10.trailing-edge.com says that the Tops-20 V7.0 > sources involve 165 files, not all of which are going to be Macro-20 source > (Link-20 control files, batch jobs, etc.); Tops-10 v7.04 similarly involves > 181 files. > > In porting Tops-20 to the XKL Toad-1, as well as implementing changes at > Stanford, we frequently re-compiled individual files, or perhaps a half dozen > or so for a major change, and re-linked against the previous builds' .REL > files. I can't speak to Tops-10 development--my involvement with that OS only > began 4 years ago with a new job. OK, then my question goes back to Jan and Barb. Why was a full sysgen required or recommended for the situations you guys were talking about? Wouldn't partial gens do the job without the need for the large resource commitment Jan talked about? -- - Stephen Fuld (e-mail address disguised to prevent spam)
From: Charles Shannon Hendrix on 29 Mar 2007 18:06 ["Followup-To:" header set to alt.folklore.computers.] On 2007-03-28, Nick Maclaren <nmm1(a)cus.cam.ac.uk> wrote: > > 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. At the same time, those of us that do embedded programming need to be able to force things to happen in order and exactly how we said for them to happen. Writing 32-bits when I asked for 16, or writing BAC instead of ABC is verboten. > I was actually thinking of worse problems, such as exception handling > and memory consistency, but the above also applies. Do you mean you don't want to have to deal with exception handling, or that you want it clean enough to rely on? -- shannon "AT" widomaker.com -- ["There are nowadays professors of philosophy, but not philosophers." ]
From: Peter Flass on 29 Mar 2007 18:42
Jan Vorbr�ggen wrote: > AFAIK, even the > Alpha is not only being supported but being actively developed. This must be a change, then. A while ago I think I remember seeing a "roadmap" that called for one or two bumps, and then nothing. |