The Perfect Computer - 36 bits?
|
From: David W Schroth on 15 Mar 2007 12:26 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. Especially when one has to maintain backward compatibility (something we've been doing for longer than DEC ever had to). > /BAH > Regards, David W. Schroth
From: Peter Flass on 15 Mar 2007 16:52 jmfbahciv(a)aol.com wrote: > In article <MeSdnVgMNdXQ5mXYnZ2dnUVZ_rvinZ2d(a)comcast.com>, > pechter(a)pechter.dyndns.org (William Pechter) wrote: >> >>VAX/VMS was somewhere around '79 or so. >>It was in the 2.5 varient by '82. > > > And it didn't do backwards compatibility very efficiently. > This was part of the stupidity. The -10 was, above all, a timesharing machine. The VAX wasn't; I'd call it a general-purpose mini, but at any rate it was aimed at an entirely different market. By dumping the-10 and -20, DEC cut those customers off at the knees. possibly they felt they didn't have enough resources to support two distinct lines, but otherwise it was just plain dumb.
From: Rich Alderson on 15 Mar 2007 17:11 glen herrmannsfeldt <gah(a)ugcs.caltech.edu> writes: > Rich Alderson wrote: >> jmfbahciv(a)aol.com writes: > (snip) >>> Why? I still don't understand why you are constraining the index >>> base to be 18 bits. I'd make it 36 (if we had a 36-bit word >>> boundary architecture). Those 18 bits is 18 wires, right? >> 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?" > It would be similar to most RISC architectures. There is an additional > instruction which will load the high bits of a register from an > immediate field, so any address can be reached in two instructions. > It also works well for indexing into arrays of structures, where the > index points to the beginning of the structure, and the offset to the > structure element. OK, I like that. That's doable. A lot less schratzing around with multiple ACs to set addresses prior to the actual work being done. -- Rich Alderson | /"\ ASCII ribbon | news(a)alderson.users.panix.com | \ / campaign against | "You get what anybody gets. You get a lifetime." | x HTML mail and | --Death, of the Endless | / \ postings |
From: Joseph H Allen on 15 Mar 2007 17:37 In article <mdd3b46us8z.fsf(a)panix5.panix.com>, Rich Alderson <news(a)alderson.users.panix.com> wrote: >glen herrmannsfeldt <gah(a)ugcs.caltech.edu> writes: > >> Rich Alderson wrote: > >>> jmfbahciv(a)aol.com writes: > >> (snip) > >>>> Why? I still don't understand why you are constraining the index >>>> base to be 18 bits. I'd make it 36 (if we had a 36-bit word >>>> boundary architecture). Those 18 bits is 18 wires, right? > >>> 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?" > >> It would be similar to most RISC architectures. There is an additional >> instruction which will load the high bits of a register from an >> immediate field, so any address can be reached in two instructions. >> It also works well for indexing into arrays of structures, where the >> index points to the beginning of the structure, and the offset to the >> structure element. > >OK, I like that. That's doable. A lot less schratzing around with multiple >ACs to set addresses prior to the actual work being done. I thought there was an indirect bit? Just force all programs to stick their 36-bit addresses and constants in the first 256KW, meaning that there already is a way to load 36-bit constants into the registers. I don't think you have to change the instruction format at all to support 36-bit addresses. move 2, @100 Load register 2 from word at address 100. move 2, [7777777] MACRO reserves space for the constant 7777777 somewhere in the first 256KW, sticks its address into the 18-bit field and sets the I bit. (it's all coming back... the registers were memory mapped at address zero). -- /* jhallen(a)world.std.com AB1GO */ /* Joseph H. Allen */ int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0) +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2 ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
From: glen herrmannsfeldt on 16 Mar 2007 00:17
Rich Alderson wrote: > glen herrmannsfeldt <gah(a)ugcs.caltech.edu> writes: (snip on extending the PDP-10 address space) >>It would be similar to most RISC architectures. There is an additional >>instruction which will load the high bits of a register from an >>immediate field, so any address can be reached in two instructions. >>It also works well for indexing into arrays of structures, where the >>index points to the beginning of the structure, and the offset to the >>structure element. > OK, I like that. That's doable. A lot less schratzing around with multiple > ACs to set addresses prior to the actual work being done. There are two ways to extend an instruction set. One is with new opcodes, the other is with a mode bit somewhere. Old programs run with the mode bit off, and so run as before. One complication is the indirect and index registers in old addresses. Do these go away? If they stay, there are still 13 unused bits. What do those 13 bits do now? -- glen |