The Perfect Computer - 36 bits?
|
From: jmfbahciv on 17 Mar 2007 06:38 In article <64zKh.153484$5j1.81907(a)bgtnsc04-news.ops.worldnet.att.net>, Stephen Fuld <S.Fuld(a)PleaseRemove.att.net> wrote: >jmfbahciv(a)aol.com wrote: > >snip > >> But the question here isn't about style but why (or how) >> these managers assumed that customers could be dicated to >> as if they were subordinates. > >Come on Barb. You know the answer to that. :-) > They assumed that because >it was a good assumption because it was quite often true for over the >previous three decades! When these managers were coming up, IBM was so >dominant that they *could* dictate to customers and most of them would >"obey". Note that I am not commenting on the value or goodness of the >situation, nor of its applicability to the different environment of the >DEC marketplace (where it clearly wasn't nearly as effective), just >answering your question. :-) It made us a lot of money. IBM didn't mind because we were their anti-monopoly cushion. > >I am making the assumption >> that most managers knew that products were being made and >> sold to other people. > >Yes, but in small enough numbers that they could be largely ignored. I sometimes wonder if you moved them all to a mill environment if that kind of self-maintained ignorance would be erased. /BAH
From: jmfbahciv on 17 Mar 2007 06:44 In article <45faca01$0$1342$4c368faf(a)roadrunner.com>, Peter Flass <Peter_Flass(a)Yahoo.com> wrote: >jmfbahciv(a)aol.com wrote: >> >> There were many sane ways to move customers from the one product >> line to the other, IF that was a goal. The choice was the most >> insane method. This was part of the IBM thinking that was >> injected (sorry, Lynn) into middle management. IBM customers >> were used to being ordered around "for their own good". > >Maybe in some respects, but many would say the reason for IBM's success >was that it always tried to maintain backwards-compatibility. A program >from the earliest 360 days (executable, not just source) will run the >same today on the most recent version of the hardware and OS. That's 42 >years of compatibility! That is NOT maintaining backwards compatibility. You create a design that simply won't _break_ old code. Then you don't have to spend a single maintenance dollar on your customers' old code. I am assuming that you are using the word 'maintenance' very loosely but it cannot be used this way if you are designing tomorrow's CPU. This is the most important point of the design. Everything else is bits and bytes. If you have to maintain your customers' old code (which includes all of your old code), you'll go bankrupt. Period. /BAH
From: jmfbahciv on 17 Mar 2007 07:17 In article <mddwt1g4wcp.fsf(a)panix5.panix.com>, Rich Alderson <news(a)alderson.users.panix.com> wrote: >jmfbahciv(a)aol.com writes: > >> In article <etbjul$b66$1(a)gal.iecc.com>, johnl(a)iecc.com (John L) wrote: > >>> Well, sure, you could keep running your old 18 bit programs, just like >>> on a 386 you can keep running your old 16 bit 286 programs. But if >>> you wanted to use the larger address space, > >[snip] > >>> you had to rewrite your >>> programs, and since segmented address spaces sucked as badly then as >>> it does now, we didn't. Where I was (Yale) we moved to 4BSD on a Vax. > >> I don't understand. Why did you have to change code to run on >> a -20 when the backplane was installed? There was nothing, other >> than your local requirements, that forced you to change code. > >*This* is what I was talking about in previous posts: Not using a changed >architecture with an expanded instruction set, but using the old architecture >with expanded memory. > >Let's say you have a CAD program that runs on the PDP-10. Call it SUDS, for >the sake of argument. The amount of work that can be done in an 18-bit space >is sufficient for some time, but eventually you need to do work on a board >larger than will fit into your system. > >So you have to revise SUDS to use "extended addressing" and "non-zero sections" >so that your board representations can be held in memory. But this means that >you have to rewrite a lot of nonobvious parts of SUDS, because the architecture >only allows addressing of non-zero sections from non-zero sections, and in such >a section, where addresses are not 18 bits but 30, certain common instructions >do not work, for example AOBJN, the most common loop type. > >(For those not familiar with the PDP-10, AOBJN _A_dds _O_ne to _B_oth halves of >the accumulator (AC) specified, and if the resulting value is _N_egative, it >_J_umps to the 18-bit address specified in the instruction. It is frequently >used to loop over table entries: The number of table entries, negated, is put >in the left half of the AC and the address of the first entry is put in the >right half, and the AC is used as an (18-bit) index register to reference the >table entries in the loop body. At the bottom of the loop, AOBJN AC,LUPTOP and >you're now pointing at the next entry at the top of the loop. > >In extended sections, 30-bit addresses in ACs interfere with AOBJN, so all >loops of this kind have to be rewritten. A number of other gotchas of similar >stripe exist.) > >And that's why some people left the PDP-10 behind, Barb. The -10 already had "segmentation" in its philosophy. You didn't run any code without GETSEGing. So I don't understand how you expected an enhancement to make segment boundaries invisible. Given: 72-bit words-- I would assume (if the instruction was implemented) that the equivalent of the PDP-10's AOBJN would work on 72 bits or whatever. But this is the kind of thing that needs to be thought about when designing the extensible piece. Now, for the sake of the new design piece of this thread, why was that code using AOBJNs? /BAH
From: jmfbahciv on 17 Mar 2007 07:22 In article <m3wt1hp4vk.fsf(a)garlic.com>, Anne & Lynn Wheeler <lynn(a)garlic.com> wrote: >John Ahlstrom <AhlstromJK(a)comcast.net> writes: >> See: >> >> Virtualizing the VAX architecture >> Preliminary Design of a VAX-I1 Virtual Machine Monitor Security >> Kernel. Technical Report DEC TR-126, Digital Equipment Corporation, >> Hudson, MA, ... >> portal.acm.org/citation.cfm?id=115952.115990 - Similar pages >> >> >> A Retrospective on the VAX VMM Security Kernel >> 45 {45} P. A. Karger, "Preliminary design of a VAX-11 virtual machine >> monitor security kernel," Digital Equip. Corp., Hudson, MA, >> Tech. Rep. ... >> portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=123459 - Similar pages >> [ More results from portal.acm.org ] > >may have been somewhat/totally coincidental ... but when POK convinced >corporate that the vm370 development group (at the time, located in >the old SBC bldg. in burlington mall) had to be shutdown (including >the product) and everybody moved to POK help get MVS/XA out the door >.... some number of people didn't moved ... and several round up at >DEC (workng on what was to become vax/vms) All of this cancelling stuff...when did this happen? I don't want a year; I want a contect of the state of the economy at the time. (I don't know a better way to write the question). > >Endicott managed to salvage some of the mission and keep the product >from totally being canceled. > >a few recent posts mentioning the event: >http://www.garlic.com/~lynn/2007.html#23 How to write a full-screen Rexx debugger? >http://www.garlic.com/~lynn/2007e.html#41 IBM S/360 series operating systems history >http://www.garlic.com/~lynn/2007f.html#14 more shared segment archeology I was always amazed that the Ultrix group survived. I don't know how they did it. As one story that JMF used tell went...maybe they gave better blow jobs. /BAH
From: Peter Flass on 17 Mar 2007 07:39
jmfbahciv(a)aol.com wrote: > > The Alpha was getting started to become a "raional" > system. VAX was junk. Then, as with TOPS-10, DEC essentially > canned VMS. Custoemers who were very happy with VMS on Alpha > saw the signs and did the intelligent thing and moved to another > architecture. This was in the 90s. I liked the VAX architecture very much. It was really a "programmer-oriented" instruction set, maybe one of the last. VMS just wasn't a TOPS-10/-20 replacement system. |