The Perfect Computer - 36 bits?
|
From: jmfbahciv on 15 Mar 2007 08:36 In article <ZZSdnehq8aemKGXYnZ2dnUVZ_oKnnZ2d(a)comcast.com>, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: >Peter Flass wrote: > >(someone wrote) > >>> 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? > >Well, it would not be backwards compatible as the indirect bit >and index register are already in those bits, but it could be done >with new instructions. You keep assuming that the old code doing a MOVE T1,@FOO will "know" that the bit is no longer 13. That doesn't have to be true. You can do a hardware mapping from new addressing to old or you can have an emulator do this for you. There are all kinds of ways to keep this support. It's a matter of getting all the ideas and weighing the goals, non-goals, constraints, extensibility and costs. You do have to have, as part of your hardware design, a paper stating how to extend the field widths in the future. Be very specific of how to do this. This is important so people have an opportunity to plan. I'll answer Mr. Fuld's post to talk this some more. Again, note that I don't know the hardware development biz at all. It's up to those hardware guyt to figure out how to do the miracles :-). > >> This would work. It makes the architecture effectively >> base-displacement, with the 36-bit index registers now base registers, >> and the address field in the instruction the displacement. Like 360, >> but with *much* larger amounts of data addressable from one base register. > >The S/360 instruction set has been extended a few times by now. >Instructions with 20 bit displacement are now available. Since most >of the new instructions use 16 bit opcodes there tends to be an extra >eight bits available. The old 12 bit displacement instructions are >still available. > >-- glen >
From: jmfbahciv on 15 Mar 2007 08:45 In article <86Odndpa__EEl2TYnZ2dnUVZ_vDinZ2d(a)speakeasy.net>, rpw3(a)rpw3.org (Rob Warnock) wrote: >Peter Flass <Peter_Flass(a)Yahoo.com> wrote: >+--------------- >| jmfbahciv(a)aol.com wrote: >| > Rich Alderson <news(a)alderson.users.panix.com> wrote: >| >>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? >| >| This would work. It makes the architecture effectively >| base-displacement, with the 36-bit index registers now base registers, >| and the address field in the instruction the displacement. Like 360, >| but with *much* larger amounts of data addressable from one base register. >+--------------- > >But it completely destroys those many instructions which used >a count (or negative count) in the left half of a register and >an address in the right half. You know, "unimportant" instructions >like AOBJxx, SOBJxx, PUSH, PUSHJ, POP, POPJ -- the ones the entire >stack architecture was based on. Why? I don't how it destroys it. The hardware does the AOBJN with its double field. How did our heardware guys create a DMOVE which picked up a double word out of memory? They just put in more wiring that did a double fetch. As long as the "old" instructions deal with n-bit words where the left (or do I want right?) n-36 bits can't be "seen" by the program, I don't see a problem. Don't give me this wastage of a 36bits/word (I'll assume a 72-bit word for now) in this day and age of bloat. Old EXEs built for 36-bit machines will still work. A recompilation of the code, will produce a D-EXE which has the machine instructions that can handle the double-size word. A MOVE will still do a MOVE and MOVEM will still do a MOVEM. When a new system reference card is published, there will be blue instructions for each instruction class. YOu can even expand the instruction field to 18bits if you want. I don't know if people need that many for future new instruction definitions. /BAH
From: jmfbahciv on 15 Mar 2007 09:14 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: >>>> >>>> >>>>>>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? >>>>You don't have to change current instructions. You can >>>>add, or extend, existing instructions to manipulate greater >>>>than 18-bit addresses. >>> >>>If I'm doing the math right, this is 64 Giga-*Words*, or 256 Gigabytes >>>assuming you pick 9-bit bytes. Should be enough. If you need more, >>>change the page-table format (paging makes it a -20, right?) >> >> >> Wrong. You want to be able to "extend" it without any changes. >> Changes imply that something of old would no longer work. > >Only the OS would see this. That is a bad assumption. Dedicated machines don't have OSes working on them. > >> >> >> >>> One adress >>>space could still only map 64GW, but you could have lots of address spaces. >> >> >> You are thinking grom the app up POV. YOu need to also think >> from the OS down POV. >> >> For instance why does an app need to know the physical number of >> the maximum? YOu have the OS give a number if it thinks it needs >> one. > >64GW is 2**36, if I exponentiated right. This is the physical limit of >a 36-bit address. Is a 64GW indexing range too small? /BAH
From: jmfbahciv on 15 Mar 2007 09:23 In article <et9dj2$232c$1(a)gal.iecc.com>, johnl(a)iecc.com (John L) wrote: >>Why does everybody keep assuming that PDP-10s have to be limited >>to 18-bit addressing? Isn't it simply a small matter of wiring >>to fetch more than 18bits for effective address calculations? > >The 6/10 instruction set had 18 bit address fields and 18 bit address >calculation rules. All the software assumed that was how the >addressing worked. The only software that has to assume this is MACRO-10 and its attendants. A new MACRO-10 (or its equivalent) would have to be produced. I am NOT proposing that the old MACRO.EXE with a creation date of 22-Jun-1994 know about the new instructions. Code that has the new "double-word" instructions would never used the 1994 MACRO-10. It would use the new MACRO-10 that came with the new CPU hardware. > >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. > If you were >going to have to change all your programs anyway, NO! NO! NO! NO!! This is exactly wrong. The whole point of backwards compatibility is so no programs' EXEs have to change just because the nether regions of the hard/software architecture changed. TOPS-10 could still run *.SAV files long after we stopped "supporting" them. Changing the executable format is a similar design problem. You should study how we herded customers from using the *.SAV file format to the *.EXE format. > it made more sense >to switch to something with a larger flat address space than the >segmented -20 addresses. With the KL architecture, the only was to go was sections. We were not starting from scratch and had a large existing installed customer base. You don't have that constraint within this project unless you put it in. /BAH
From: John L on 15 Mar 2007 10:07
>>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. >> 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, 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. R's, John |