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>
From: Anne & Lynn Wheeler on 16 Mar 2007 08:47
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
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
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
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
including these mentioning figuring out how to simulate a larger
number of "small" shared segments (rather than being restricted to
sixteen 28-bit segments).
and any past posts happening to mention 801, iliad, romp, rios,
somerset, power/pc, etc
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
>> OK, I like that. That's doable. A lot less schratzing around with
>> 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?
From: Anne & Lynn Wheeler on 16 Mar 2007 09:05
> 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"
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.