The Perfect Computer - 36 bits?
|
From: Rich Alderson on 14 Mar 2007 19:16 jmfbahciv(a)aol.com writes: > In article <mddtzwpgcq7.fsf(a)panix5.panix.com>, > Rich Alderson <news(a)alderson.users.panix.com> wrote: >> jmfbahciv(a)aol.com writes: >>> In article <et4hl0$1vlg$1(a)gal.iecc.com>, johnl(a)iecc.com (John L) wrote: >>>>> So what was missing in the PDP-10 architecture? >>>> Address bits, the same thing that killed every other old architecture. >>> Address bits with respect to what? I don't see the problem. >>> I'm not a hardware type but a fetch for effective address >>> calculations can be 36-bits wide. Can it not? >> No, it cannot. The largest offset from an index base (the only way to go >> beyond 18 bits of address) is 2^18, and there's no way to get around that. > 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?" *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.) >> And there's only one of those per instruction, for most classes of >> instruction. > There are many free instruction number slots left. There are quite > a few device codes left. There are a lot fewer than you think, and not nearly enough to have a general instruction set that handles larger than 18 bits of address. > I don't see why the instuction set can't be "extended" (a term I > am hesitant to use) to be 72-bits. The KI had already started > tranforming from 36 to 72. > I never understood why this one didn't continue. Are you talking about the double-word instructions? Yes, *data* can be 71 bits long (you lose the sign bit in the second word), but that's got nothing to do with *addresses*. If that's not what you are thinking of, please spell it out for me. >>> You don't have to change current instructions. You can >>> add, or extend, existing instructions to manipulate greater >>> than 18-bit addresses. >>> For example, refer to the DECsystem-10 Reference Card, part number >>> DEC-10XSRCA-B-D. Note that the blue print indicated the KI-10 >>> only add-ons. >>>> The DEC 20 extended addressing was a clever hack, but it was basically >>>> 286 style segmented addresses which are a nightmare to program. >>> Of course it was a hack. It was a way to provide computing service >>> until the next architecture was in production. >>> I'm not sure that we ever expected regular users to use it. >> Since it is the only way to get a program with large data structures to fit >> in more than 256KW of memory, and since large data structures are required >> for a number of modern applications, regular users *have* to use it if thye >> are going to program those applications on the PDP-10 architecture. > By "use it", I meant code it. I was assuming that regular everyday > users wouldn't be coding in machine language. Even if "regular everyday users" aren't going to be coding (at whatever level), someone has to write the applications that they are going to use. And those application programmers have to be able to get decent performance out of the architecture, even if they write in "high-level" languages. If the only way to simulate a large address space is to manipulate addresses in index registers for every useful instruction, you don't have a chance in Hell of getting good performance out of the application. This is not theoretical. I've been there on the PDP-10. Most of the modern computing world has been there on the 80286. Segmented address spaces suck. -- 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: Eugene Miya on 14 Mar 2007 20:29 >>>>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. --
From: Quadibloc on 14 Mar 2007 21:03 Eugene Miya wrote: > Well if you had done homework you would have seen where the S-1 guys saw > its limitations and planned to expand for the future. Looking at the S-1 architecture manual, I see that it had a 30-bit virtual address, where addresses were 9-bit quarter-word addresses. I thought the PDP-10 addressed memory in whole words. The PDP-10 also had the unusual feature of dividing words into bytes that didn't necessarily fill the whole word. The S-1 also has an 18-bit floating-point type... beating out the FOX-1 from Foxboro for the world's shortest floating-point type before high-end graphics cards came along! But the floating-point formats for the S-1 had a *hidden bit*, like the PDP-11, but very much *unlike* the PDP-10. It does have 16 general registers, like a PDP-10. But it doesn't appear to be fully upwards-compatible, able to execute PDP-10 binaries without a recompile. John Savard
From: l_cole on 14 Mar 2007 21:16 On Mar 14, 4:16 pm, Rich Alderson <n...(a)alderson.users.panix.com> wrote: > jmfbah...(a)aol.com writes: > > In article <mddtzwpgcq7....(a)panix5.panix.com>, > > Rich Alderson <n...(a)alderson.users.panix.com> wrote: > >> jmfbah...(a)aol.com writes: > >>> In article <et4hl0$1vl...(a)gal.iecc.com>, j...(a)iecc.com (John L) wrote: > >>>>> So what was missing in the PDP-10 architecture? > >>>> Address bits, the same thing that killed every other old architecture. > >>> Address bits with respect to what? I don't see the problem. > >>> I'm not a hardware type but a fetch for effective address > >>> calculations can be 36-bits wide. Can it not? > >> No, it cannot. The largest offset from an index base (the only way to go > >> beyond 18 bits of address) is 2^18, and there's no way to get around that. > > 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?" > > *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.) > > >> And there's only one of those per instruction, for most classes of > >> instruction. > > There are many free instruction number slots left. There are quite > > a few device codes left. > > There are a lot fewer than you think, and not nearly enough to have a general > instruction set that handles larger than 18 bits of address. > > > I don't see why the instuction set can't be "extended" (a term I > > am hesitant to use) to be 72-bits. The KI had already started > > tranforming from 36 to 72. > > I never understood why this one didn't continue. > > Are you talking about the double-word instructions? Yes, *data* can be 71 bits > long (you lose the sign bit in the second word), but that's got nothing to do > with *addresses*. > > If that's not what you are thinking of, please spell it out for me. > > > > >>> You don't have to change current instructions. You can > >>> add, or extend, existing instructions to manipulate greater > >>> than 18-bit addresses. > >>> For example, refer to the DECsystem-10 Reference Card, part number > >>> DEC-10XSRCA-B-D. Note that the blue print indicated the KI-10 > >>> only add-ons. > >>>> The DEC 20 extended addressing was a clever hack, but it was basically > >>>> 286 style segmented addresses which are a nightmare to program. > >>> Of course it was a hack. It was a way to provide computing service > >>> until the next architecture was in production. > >>> I'm not sure that we ever expected regular users to use it. > >> Since it is the only way to get a program with large data structures to fit > >> in more than 256KW of memory, and since large data structures are required > >> for a number of modern applications, regular users *have* to use it if thye > >> are going to program those applications on the PDP-10 architecture. > > By "use it", I meant code it. I was assuming that regular everyday > > users wouldn't be coding in machine language. > > Even if "regular everyday users" aren't going to be coding (at whatever level), > someone has to write the applications that they are going to use. And those > application programmers have to be able to get decent performance out of the > architecture, even if they write in "high-level" languages. If the only way to > simulate a large address space is to manipulate addresses in index registers > for every useful instruction, you don't have a chance in Hell of getting good > performance out of the application. > > This is not theoretical. I've been there on the PDP-10. Most of the modern > computing world has been there on the 80286. Segmented address spaces suck. > The 286's implementation of segmentation left something to be desired, to say the least, but I believe that at worst, this indicates the 286's implementation of segmentation sucks, not that segmentation (AKA banking) sucks in general. Personally, I like the Unisys 2200 XPA's implementation of segmentation/banking. Mr. Schroth has long pointed out to me that he thought that it was a mistake that the number of index register bits used in effective address calculations wasn't extended to something closer to 36-bits rather than just being extended from 18- to 24-bit bits as it was when extended mode first came out. Be that as it may, bank subsetting (i.e. loading a base register so that it describes only a portion of a bank) seems to keep 2200 XPA machines chugging along adequately even when only 18- or 24-bits of indexing are available. (Banks on a 2200 XPA can theoretically be up to 2**33 words and users can have up to 15 banks or bank subsets based at any instant in time. And yes, Mr. Schroth, I agree that it would have been nicer to have extended the number of indexing bits to something to 36-bits.) > -- > Rich Alderson | /"\ ASCII ribbon | > n...(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: Quadibloc on 14 Mar 2007 21:41
I wrote: > The S-1 also has an 18-bit floating-point type... beating out the > FOX-1 from Foxboro for the world's shortest floating-point type before > high-end graphics cards came along! But the floating-point formats for > the S-1 had a *hidden bit*, like the PDP-11, but very much *unlike* > the PDP-10. I found its floating point formats interesting enough that, just after revising my floating-point formats page to add the Univac 418 (as a dual group machine) I revised it again to add the S-1 as well (as the short float record holder, beating out the FOX-1). John Savard |