The Perfect Computer - 36 bits?
|
From: John Ahlstrom on 16 Mar 2007 01:58 Eugene Miya wrote: >>>>> backward compatibility >>> Well, let's see, when did VAX/VM come out? Some time in the latter 80s? >>> I'm sure the IBM VM/370 people were grinning at the time. > > In article <MeSdnVgMNdXQ5mXYnZ2dnUVZ_rvinZ2d(a)comcast.com>, > William Pechter <pechter(a)pechter.dyndns.org> wrote: >> VAX/VMS was somewhere around '79 or so. > > VMS 1.0 was 1978/77 depending when you count. I saw a 780 at DECUS in > Anaheim in 1978. > >> It was in the 2.5 varient by '82. > > Is that right? I thought the VAX Virtual Machine was later than that. > I.e., you could run VMS and Ultrix on the same hardware at the same time. > 82, STUG (The Software Tools User Group) was really started to take off. > 4.2BSD was a Fabry/Joy glimmer, and TCP was a couple years away. > ANd we were getting an 11/782 and LLNL a 11/784 (which we late upgraded > to, and I think the whole count for MA780s was 5). > Ames, LLNL, CMU, DEC, and 1 more. CSU FC? Or a UK machine. I should > ask Sopka. > One of you - Pechter - is talking about Virtual Memory System. Eugene is talking about Virtual Machine. Did VAX Virtual Machine ever get into a product? JKA
From: John Ahlstrom on 16 Mar 2007 02:01 Rich Alderson wrote: -- snip snip > > The index base can be 35 bits, if you like. (Not 36 because of the sign bit, > but that's still a 32GW address.) Unfortunately, the *instruction* *format* > does not give you more than 18 bits on top of whatever is in the index AC. > Being able to address more than that 18 bits' worth is the concern, not > "How big an address can I get out of the index register?" > > *That's* where the address space is limited. > > The VAX architecture, with its variable-length instructions, can address both > a source and a destination in a single instruction which are more than 18 bits > away from their respective indexes. (IIRC, they can go to 24 bits, but they're > addressing octets, not words.) > -- snip snip IBM had been getting 2**24 bit memory and 24 bit addresses with 12 bit displacements in instructions since 1964 (announcement) or 1965 (delivery). Granted they had a base register as well as an index register in their effective address calculation, but that could always have been done in a previous instruction in a 10-like machine with 35-bit addresses and 18 bit displacements. JKA
From: Anne & Lynn Wheeler on 16 Mar 2007 04:17 John Ahlstrom <AhlstromJK(a)comcast.net> writes: > IBM had been getting 2**24 bit memory and 24 bit addresses > with 12 bit displacements in instructions since 1964 (announcement) > or 1965 (delivery). Granted they had a base register as well > as an index register in their effective address calculation, > but that could always have been done in a previous instruction > in a 10-like machine with 35-bit addresses and 18 bit displacements. 360/67 ... had two virtual memory modes ... one was 24-bit addressing and the other was 32-bit addressing. 360/67 functional characteristics (dated 1967, from bitsavers): http://www.bitsavers.org/pdf/ibm/360/funcChar/A27-2719-0_360-67_funcChar.pdf in transition to 370 virtual memory, only 24-bit addressing was supported. 370-xa re-introduced virtual addressing larger than 24-bits ... but it was only 31-bits (instead of 32-bits) ... and operating system had to support 24-bit applications, 31-bit applications, and mixed-mode applications. things got a lot more complicated when 64-bit addressing was introduced ... and having to support three different addressing modes. recent principles of operations http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/CCONTENTS?SHELF=DZ9ZBK03&DN=SA22-7832-03&DT=20040504121320 from above ... 1.1.5 Trimodel Addressing http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/1.1.5?SHELF=DZ9ZBK03&DT=20040504121320
From: jmfbahciv on 16 Mar 2007 07:51 In article <etbs49$1ki8$1(a)si05.rsvl.unisys.com>, David W Schroth <David.Schroth(a)unisys.com> wrote: >jmfbahciv(a)aol.com wrote: >> In article <45f875eb$0$27065$4c368faf(a)roadrunner.com>, >> Peter Flass <Peter_Flass(a)Yahoo.com> wrote: >> >>>jmfbahciv(a)aol.com wrote: >>> >>> >>>>In article <45f730c0$0$16659$4c368faf(a)roadrunner.com>, >>>> Peter Flass <Peter_Flass(a)Yahoo.com> wrote: >>>> >>>> >>>>>jmfbahciv(a)aol.com wrote: >>>>> >>>>> >>>>> >>>>>>In article <et4hl0$1vlg$1(a)gal.iecc.com>, johnl(a)iecc.com (John L) wrote: >>>>>> >>>>>> >>>>>> ><snip> >> >> >> Is a 64GW indexing range too small? >> > >Back then, no. > >Now, yes. > >I have to say, as someone who has participated in the exercise of >expanding a 36-bit architecture from using 18-bit addresses to using >much larger addressing, that the effort is considerably more difficult >than you realize. I have made no assumption about difficulty other than it exists. > Especially when one has to maintain backward >compatibility (something we've been doing for longer than DEC ever had to). No,no. YOu don't ever maintain backwards compatibility. That's the mistake that the industry is always making; it is usual fatal. What you do is not break it unless you clearly state that no software, other than what ships, will work. If you do this, you have to state it from the first day when the first sentence of the project is written; and you have have to make it public so that the people who would buy your gear can plan. This will take minimmally three years; I've heard that the product cycles are six months. Thus this last one can never be an option, IMO. /BAH
From: jmfbahciv on 16 Mar 2007 07:58
In article <etbjul$b66$1(a)gal.iecc.com>, johnl(a)iecc.com (John L) wrote: >>>You could easily have designed a machine similar to the -10 with wider >>>address calculcations, which is what they did for the -20's extended >>>addressing, but then you had a different instruction set. >> >>No, it wasn't a different instruction set; it was an expanded >>instruction set. > >I was there. It was a different instruction set. I also was there. The "-20" also was also on the "-10". The same microcode was shipped to both OS customers. > >>> If you were >>>going to have to change all your programs anyway, >> >>NO! NO! NO! NO!! This is exactly wrong. > >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, This is the key. When you recompiled you used the newer tools that had the new support. The rule has to be that, once you rebuild a program, there is no going back to the "old way". That is how you gently herd your customer base into the corrals that use the new gear. The ones who stay with the old gear are not broken; and the ones who buy the new gear slowly adjust by attrition of their software evolutions. And I don't know how to reword this last one to make it more understandable. > 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. /BAH |