The Perfect Computer - 36 bits?
|
From: jmfbahciv on 16 Mar 2007 08:04 In article <krKdnQSmUp5irGfYnZ2dnUVZ_ujinZ2d(a)comcast.com>, John Ahlstrom <AhlstromJK(a)comcast.net> wrote: >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. Oh, I assumed Eugene did a tupo. <snip question I can't answer> /BAH
From: Anne & Lynn Wheeler on 16 Mar 2007 08:47 re: http://www.garlic.com/~lynn/2007f.html#21 The Perfect Computer - 36 bits? then there was ROMP in the early 80s. It was 801/RISC running CP.r and PL.8 compiler. There was claim that ROMP had 40-bit addressing. The issue was that there was 32-bit addressing ... however, there was no protection domain. Virtual memory was inverted tables ... with segmented address space. Top 4 bits of 32-bit virtual address would index 16 "segment registers". A segment register was 12bits which was combined with the remaining 28-bits of the virtual address ... for 40-bit effective value for doing TLB lookup ... to find the real address. PL.8 supposedly would only generate correct code and CP.r would only load correct/valid PL.8 generated code for execution. As a result there was an assumption that applications could change a segment register value as easily as applications could change general registers used in addressing. The implication was that applications had complete control over general register values as part of addressing as well as complete control over segment register values for addressing. Therefor "applications" had full access to "40-bit" addressing (i.e. up to 4096 different "segments" that are 2**28 each). All of this was joint research/opd (office product division) project for follow-on to displaywriter. When that got killed, there was some investigation what could be done to avoid killing the whole operation. There was this "new" thing UNIX ... and lots of places were shipping hardware w/o having to invent/create an operating system from scratch (which was getting to be more expensive that creating the hardware). The idea was to retarget ROMP to the unix workstation market ... hiring the company that had done the unix port for pc/ix to do one for ROMP. The issue now was that UNIX paradigm had protection domain between the kernel and applications ... and applications weren't allowed to directly change virtual memory segment values. This effectively restricted unix romp application paradigm to straight 32-bit addressing. For RIOS (power/rs6000), the segment register size was doubled to 24bits. Early rs6000 technology documents continued to talk about the "52-bit" addressing (as continuation of the ROMP 40-bit addressing) .... even tho system paradigm had long changed from CP.r to UNIX. misc. "old" email mentioning 801, iliad, romp, etc http://www.garlic.com/~lynn/lhwemail.html#801 including these mentioning figuring out how to simulate a larger number of "small" shared segments (rather than being restricted to sixteen 28-bit segments). http://www.garlic.com/~lynn/2006y.html#email841114c http://www.garlic.com/~lynn/2006y.html#email841127 and any past posts happening to mention 801, iliad, romp, rios, somerset, power/pc, etc http://www.garlic.com/~lynn/subtopic.html#801
From: jmfbahciv on 16 Mar 2007 08:39 In article <Cc6dnfNo65ghlmfYnZ2dnUVZ_tKjnZ2d(a)comcast.com>, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: >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. You do both. > Old programs run >with the mode bit off, and so run as before. I don't like this one...it smells. We did a similar thing (mode bit on) when converting from the old date format to the DATE75 format. I have to think about this one some more. > >One complication is the indirect and index registers in old addresses. >Do these go away? No. They can't. Just from the top of my head, I'd left justify the indirect bit to be bit 0 of the sencond word pair (assuming a half-word is 36bits). But now I'm implementing ahead of designing. > If they stay, there are still 13 unused bits. >What do those 13 bits do now? Which 13? /BHA
From: Anne & Lynn Wheeler on 16 Mar 2007 09:05 jmfbahciv(a)aol.com writes: > 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". DEC > customers had always been severely allergic to this kind of > treatment; this allergy was why they bought DEC instead > of IBM in the first place. don't apologize to me ... circa '90 and early 90s, picking up a bunch of former middle managers ... was about when there were a significant number of middle managers were let go as part of trying to "flatten" the organizations. also the larger bureaucracy, the more you might have individuals afflicted with Boyd's characterization about rigid, top/down command and control ... recent posts http://www.garlic.com/~lynn/2007e.html#45 time spent/day on a computer http://www.garlic.com/~lynn/2007e.html#55 time spent/day on a computer and as i've previously mentioned, there were quite a few that I might not have been particularly partial to ... misc. references http://www.garlic.com/~lynn/2007.html#22 MS to world: Stop sending money, we have enough http://www.garlic.com/~lynn/2007.html#26 MS to world: Stop sending money, we have enough http://www.garlic.com/~lynn/2007b.html#29 How many 36-bit Unix ports in the old days http://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer
From: krw on 16 Mar 2007 09:24
In article <m3d539fie5.fsf(a)garlic.com>, lynn(a)garlic.com says... > jmfbahciv(a)aol.com writes: > > 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". DEC > > customers had always been severely allergic to this kind of > > treatment; this allergy was why they bought DEC instead > > of IBM in the first place. > > don't apologize to me ... circa '90 and early 90s, picking up a bunch > of former middle managers ... was about when there were a significant > number of middle managers were let go as part of trying to "flatten" > the organizations. ....and those managers (in the early '90s) were exactly the ones who most needed flattening. DEC couldn't have done any worse with the entire senior management team. They almost took IBM under. <snip> -- Keith |