The Perfect Computer - 36 bits?
|
From: Toon Moene on 1 Apr 2007 10:22 Morten Reistad wrote: > From my observations of Linux, Linux is pretty infected > with the problems of low quality fixes, blob support, bloat, > eye candy before sunstance, and blatant insecurity. I wasn't aware that there was eye candy in the Linux kernel. At least until my Debian testing bootup says: "Starting xdm." I have seen nothing but straight, large (i.e., readable without glasses to my aging eyes) characters. -- Toon Moene - e-mail: toon(a)moene.indiv.nluug.nl - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html
From: Steve O'Hara-Smith on 1 Apr 2007 05:05 On Sun, 01 Apr 2007 01:39:04 -0500 Charles Richmond <frizzle(a)tx.rr.com> wrote: > CBFalconer wrote: > > Nick Maclaren wrote: > >> Morten Reistad <first(a)last.name> writes: > >>> Lastest pc press blurbs. Vista only runs around 80 of 150 > >>> identified critical XP applications. > >> Hasta la vista? > > > > No, Vista hasta go sista. > > > It's just *another* Mi$uck mess... What can we expect??? > This is their idea of innovation. Indeed, soon there will be new versions of the other 70 that will work on Vista but will not work on XP, 2000, ME, 9x and so forth. These new versions will have new features so the old versions won't reliably read files from the new versions thus forcing updates to the new versions and therefore Vista. This is a painfully familiar pattern that has been reused over and over again going back (at least) to the move to Windows versions of DOS software. -- C:>WIN | Directable Mirror Arrays The computer obeys and wins. | A better way to focus the sun You lose and Bill collects. | licences available see | http://www.sohara.org/
From: krw on 1 Apr 2007 11:21 In article <euo48m$8qk_004(a)s910.apx1.sbo.ma.dialup.rcn.com>, jmfbahciv(a)aol.com says... > In article <MPG.207840b219666d1b98a273(a)news.individual.net>, > krw <krw(a)att.bizzzz> wrote: > >In article <eulkcd$8qk_008(a)s911.apx1.sbo.ma.dialup.rcn.com>, > >jmfbahciv(a)aol.com says... > >> In article <MPG.2077890e34e0efbb98a26e(a)news.individual.net>, > >> krw <krw(a)att.bizzzz> wrote: > >> >In article <460d9c5a$0$1428$4c368faf(a)roadrunner.com>, > >> >Peter_Flass(a)Yahoo.com says... > >> >> jmfbahciv(a)aol.com wrote: > >> >> > In article <euggeu$92m$1(a)gemini.csx.cam.ac.uk>, > >> >> > nmm1(a)cus.cam.ac.uk (Nick Maclaren) wrote: > >> >> > > >> >> >>In article <eugf8g$8qk_003(a)s879.apx1.sbo.ma.dialup.rcn.com>, > >> >> >>jmfbahciv(a)aol.com writes: > >> >> >>|> > >> >> >>|> It could be the way DEC tracked the sales. PDP-10 product line > >> >> >>|> never got any "credit" for all the minis it sold. > >> >> >> > >> >> >>I was actually thinking from the customer end, but cannot say which > >> >> >>was the chicken and which the egg. > >> >> > > >> >> > > >> >> > Neither could DEC managmeent and their bean counters. They ended > >> >> > up ignoring that (I can never remember the correct value) somewhere > >> >> > between 60-70% of the mini customers also had at least one PDP-10. > >> >> > Most had more. > >> >> > > >> >> > >> >> IBM had and has this problem too. Maybe there's just no way to quantify > >> >> it sufficiently for the MBAs that look at this stuff. Many times I've > >> >> seen them cancel a product that probably sold lots of other stuff with > it. > >> >> > >> >We constantly were up against that problem in the crypto group. We > >> >could point to systems that wouldn't have been sold were it not for > >> >ICRF (take-aways from Hitachi, IIRC) but the CPU sales team claimed > >> >them. Since our profits were minimal (intended as a differentiator) > >> >we were up against cancelation every six months or so. When the > >> >layoffs came to the Hudson Valley ('93) we were rather nervous (we > >> >were spared for some unknown reason and I found a life raft to the > >> >frozen North). > >> > > >> > >> Yup. And think of all the funcking money spent trying to cancel > >> and then justify keeping the group around. You could have "made" > >> millions more by simply not discussing it. > > > >In the end, the reason we (all ten of us) were allowed to live is > >that we had a few large customers who swore on a stack of bibles > >they'd never buy another CPU from IBM if they pulled support. They'd > >buy Amdahl first (the knife in the heart ;-). > > > We had quite a few of those. Our woodenheadedness finally wore them > out. They had an unlimited supply of wood in their heads. I moved to BTV; far simpler. -- Keith
From: John Byrns on 1 Apr 2007 11:25 In article <1175381538.964435.181470(a)n59g2000hsh.googlegroups.com>, "Quadibloc" <jsavard(a)ecn.ab.ca> wrote: > David Kanter wrote: > > On Mar 5, 5:20 am, "Quadibloc" <jsav...(a)ecn.ab.ca> wrote: > > > > Struggling with many opcode formats with which I was not completely > > > satisfied in my imaginary architecture that built opcodes up from 16- > > > bit elements, I note that an 18-bit basic element for an instruction > > > solves the problems previously seen, by opening up large vistas of > > > additional opcode space. > > > > Why is 18 bits any better than 32 bits? > > Well, 18 bits is less bits than 32 bits, but it's more bits than 16 > bits. So, if 16 bits aren't enough, jumping to 18 may get me what I > want while using fewer transistors. > > However, further thought has led me to modify my page further, and add > > http://www.quadibloc.com/arch/per01.htm > > where I show it might be possible to build instructions out of units > 12 bits long, to economize on RAM, without giving much up. (Of course, > the PDP-8, and more especially the FPP-12, could be cited as > precedents here.) Your 12-bit long memory units are an interesting alternative to the traditional 8-bit byte orientation. I am curious about several of the design decisions you made in the design of your 12-bit orientated instruction set. 1. When a register is used for indexing, why do only 15 of the 36 bits in the register participate in the address calculation? 2. Why did you restrict the use of the indexed addressing mode to only those instructions that target operands in the first register? 3. Why did you choose 36-bits as the general register size, when using say 24-bits would save transistors? 4. Aren't three distinct floating point formats overkill, wouldn't two, or even only one be enough? After some thought I came up with a tentative instruction set, based on your 12-bit proposal, which would address these issues. The changes can be seen on this page: http://fmamradios.com/arch12.html I have not yet added the non-memory reference instructions, I will complete the page in the next couple of days. Further thought has led me to another more interesting and powerful 12-bit orientated instruction set, with a completely different instruction style, which addresses the issues raised above, as well as accommodates all three of your floating point formats, all while providing greater flexibility in the use of the instruction set. I will work on a page describing this more complex 12-bit instruction set once I finish up the first page. Regards, John Byrns -- Surf my web pages at, http://fmamradios.com/
From: Anne & Lynn Wheeler on 1 Apr 2007 15:21
Morten Reistad <first(a)last.name> writes: > From sharing of segments, startup of databases, startup of deamons > for network, transactions, necessary initialisations of these, > rollback/forward, various spoolers, etc. > > The Tops20 installation I got to know took 17 minutes from load to > usefulness; it was a 2065. A primos-based Prime 4450 (approx 5 mips) > took 27 minutes to get up to speed. This was a transaction system > that distributed live data to lots of clients, and had most of it > in RAM, with sources in databases. cp67 took a couple minutes in the late 60s ... that also was time for automatic restart simulated load after (soft) failure. here is tale about some people at mit having experience with both cp67 and multics in that period ... and the multics coming off very poorly in comparison ... eventually resulting in recoding sections of multics to try and make it more favorable comparison. http://www.multicians.org/thvv/360-67.html it was highlighted by a local cp67 kernel change that resulted in 27 failures/auto-restarts in a single day ... where multics wouldn't have been able to even come close to that number ... just because of the lengthy restart time. i was partially to blaim for that occurance. As an undergraduate I had added the tty/ascii support for cp67 (base system support 2741 and 1052). I had played some games in the code with truncating line-length calculations to one byte. The cp67 service running at MIT wanted to add support for some sort of simulated ascii terminal device over at harvard (plotter?) which had max. line length more like 1200 bytes. Their kernel patch updated some constants for maximum line length ... w/o changing the code that played games with 1byte truncation (which then resulted in some incorrect lengths being calculated and subsequent sotrage overlays). the science center (responsible for cp67) was on the 4th flr of 545 tech sq. http://www.garlic.com/~lynn/subtopic.html#545tech the science center 360/67 machine room was on the 2nd flr and multics was on the 5th flr. My recollection was that the MIT Urban systems lab (and their 360/67, where the referenced cp67 story takes place) was across the tech. sq courtyard in 5?? tech sq. |