From: krw on 31 Mar 2007 10:51 In article <m3y7letamg.fsf(a)garlic.com>, lynn(a)garlic.com says... > krw <krw(a)att.bizzzz> writes: > > Sure, but you forgot the 3081 series in there. The 303x series was > > needed because the 3081 technology (originally intended for FS) > > wasn't going to be ready when needed. TCMs, and all that, took a lot > > more work than expected. OTOH, the 303x was pretty much a remapped > > 3168 (with differences you've noted) so could be pushed out the door > > quickly. The 3033 was ready when the economy turned up in '80ish. > > The 3081 wouldn't have been and kabillion$ would have been left on > > the table. > > re: > http://www.garlic.com/~lynn/2007g.html#17 The Perfect Computer - 36 bits? > > we didn't co-op any of the 3081 processor engineers ... just the guys > working on 3033 ... so I knew much less about what the 3081 guys were > doing ... other than i think they got to play leapfrog, the > kingston(?) engineers doing the 3081 while the pok engineers did the > 3033, who then went on to do trout/3090. Both were done in P'ok. IIRC, Kingston was just being built up in the late '70s. Though I was "assigned" to the 303x, I worked about equal time on each. > i.e. get 3033 out in half the time (4-5 years) while it was taking 7-8 > years to get 3081 out (as soon as 3033 was out the door ... switch to > trout/3090 in parallel with finishing 3081) ... or ... are we > possibly in violent agreement. Again, the reason the 303x could be pushed out so fast was that there was little really all that new. The 3081, OTOH, was new from the ground up; LEM=>TCM vs. CoB, TTL vs. ECL, much higher density.... -- Keith
From: krw on 31 Mar 2007 10:56 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 ;-). -- Keith
From: Morten Reistad on 31 Mar 2007 11:18 In article <euliv7$8qk_001(a)s911.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <574mp4F29voomU1(a)mid.individual.net>, > =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen(a)not-mediasec.de> wrote: >>>>Just reboot. >>> Nope. If you don't have the software, you have to a rebuild. >> >>Even Unix and Windows now are intelligent enough to detect the machine >>configuration at boot time, and dynamically load the necessary drivers etc. >at >>that time - something VMS had been doing from day 1. > >How long does it take to reboot? It took a PDP-10 about 4-6 minutes >to go from bootstrap to allowing the first user login. It took >that long because we zeroed memory before allowing system access >to any executable, including the monitor. In this day of super fast >hardware, it takes longer to boot up than a -10 did and they dont' >zero memory. 6 minutes seems about right for an off-the tapes Tops20 installation on a KL-10. Primos has a similar timing on a 4450/99xx class machine. But then you have to start services. That did bring up the time on all pre-1988 systems I have been babysitting to around 30 minutes. Yes, you may log in, but it won't do you much good. Modern *n*x os'es boot in between 40 sec and 3 minutes, but they also use a long time to start services, bringing up a usable system normally takes from 2 to 10 minutes. Modern systems do a _lot_ more for the user. > >Sure. But how do you implement a driver that requires exec code? > >How do you put in code that requires a change to VMS' interrupt >heirarchy? It would be very difficult to do your own exec mode >changes without sources so you can rebuild the monitor. >Patching interrupt level stuff and expecting it to run as a production >machine is only done by the foolish. From 2.6 you don't need source code even in Linux to do this. You just need a proxy that gives you all the symbols to link to. Building device drivers that do this is something we do here as a daily chore. Modern operating systems, be they windows, linux, BSD etc. arbitrate interrupt and DMA resources between devices when they boot. >> Hey, Microsoft >even >>has those for Windows, and has invented a new TLA for them: they're called >>DDK, for driver development kit. > >And look at all the security holes caused by putting drivers up at >the application level of software. Yep. Important issue. Even Microsoft is taking this very seriously. The OpenBSD project refuses Binary Linked OBjects (BLOB) without source to examine. This is a major source of system instability in Windows and Linux, and is generally acknowledged as a severe problem. -- mrr
From: Quadibloc on 31 Mar 2007 18:52 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.) John Savard
From: Brian Boutel on 1 Apr 2007 02:13
Brian Inglis wrote: > On Thu, 29 Mar 07 12:39:33 GMT in alt.folklore.computers, > jmfbahciv(a)aol.com wrote: > > >>In article <460a8553$0$8961$4c368faf(a)roadrunner.com>, >> Peter Flass <Peter_Flass(a)Yahoo.com> wrote: >> >>>jmfbahciv(a)aol.com wrote: >>> >>>>In article <460a471e$0$28137$4c368faf(a)roadrunner.com>, >>>> Peter Flass <Peter_Flass(a)Yahoo.com> wrote: >>>> >>>> >>>>>Morten Reistad wrote: >>>>> >>>>> >>>>>>Just watch the pain unfold when Vista cannot run your application. >>>>>>With binary-only, Microsoft products you will have a similar experience >>>>>>as we had when DEC folded on us. There is no Plan B in this scenario. > > >>>>>>>>The lesson from DEC is that it can happen. >>>>>>>> >>>>>>>>Always have a Plan B. >>>>>> >>>>>As I already said, my plan B is Linux. >>>> >>>> >>>>However, there are a lot of system owners who cannot use that >>>>as their Plan -anythings because they are not in the software >>>>biz. >>> >>>I got excited when I heard Dell was going to (again) ship retail PCs >>>with Linux. Then I contacted support and found out they're going to >>>pre-load some dumb version of DOS, and sell Linux separately. While >>>everyone here would have no trouble installing a new OS, non-M$ systems >>>will continue to lag until they're available pre-loaded and >>>pre-configured. M$ knows this, and I'm sure their fingerprintes are all >>>over everything. >> >>When JMF was dying (1994) and needed a laptop in order to speak, I >>tried to order one from Dell. I was told that it would take >>six months to install Unix. I'm an auld OS babe and smelt the >>rat. > > >>I have not tested this part of the OS biz since then. > > > My first Linux install was 30 minutes from opening the Slackware CD > wrapper to running the OS with an alternate boot to DOS/Windows. > It then took longer just to config a customized kernel to support needed > drivers and eliminate unnecessary ones; the kernel source rebuild took > much longer. > My first Linux kernel builds on a 486 took about an hour, until I added some memory, when it went down to about 10 mins. 8MB was not enough for individual file compiles to run in memory, but 12MB was. --brian -- Wellington, New Zealand "What's life? Life's easy. A quirk of matter. Nature's way of keeping meat fresh." |