From: John Ahlstrom on 16 Mar 2007 01:58
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.
Did VAX Virtual Machine ever get into a product?
From: John Ahlstrom on 16 Mar 2007 02:01
Rich Alderson wrote:
-- snip snip
> 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.)
-- snip snip
IBM had been getting 2**24 bit memory and 24 bit addresses
with 12 bit displacements in instructions since 1964 (announcement)
or 1965 (delivery). Granted they had a base register as well
as an index register in their effective address calculation,
but that could always have been done in a previous instruction
in a 10-like machine with 35-bit addresses and 18 bit displacements.
From: Anne & Lynn Wheeler on 16 Mar 2007 04:17
John Ahlstrom <AhlstromJK(a)comcast.net> writes:
> IBM had been getting 2**24 bit memory and 24 bit addresses
> with 12 bit displacements in instructions since 1964 (announcement)
> or 1965 (delivery). Granted they had a base register as well
> as an index register in their effective address calculation,
> but that could always have been done in a previous instruction
> in a 10-like machine with 35-bit addresses and 18 bit displacements.
360/67 ... had two virtual memory modes ... one was 24-bit addressing
and the other was 32-bit addressing.
360/67 functional characteristics (dated 1967, from bitsavers):
in transition to 370 virtual memory, only 24-bit addressing was
370-xa re-introduced virtual addressing larger than 24-bits ... but it
was only 31-bits (instead of 32-bits) ... and operating system had to
support 24-bit applications, 31-bit applications, and mixed-mode
applications. things got a lot more complicated when 64-bit addressing
was introduced ... and having to support three different addressing
recent principles of operations
from above ... 1.1.5 Trimodel Addressing
From: jmfbahciv on 16 Mar 2007 07:51
In article <etbs49$1ki8$1(a)si05.rsvl.unisys.com>,
David W Schroth <David.Schroth(a)unisys.com> wrote:
>> In article <45f875eb$0$27065$4c368faf(a)roadrunner.com>,
>> Peter Flass <Peter_Flass(a)Yahoo.com> wrote:
>>>>In article <45f730c0$0$16659$4c368faf(a)roadrunner.com>,
>>>> Peter Flass <Peter_Flass(a)Yahoo.com> wrote:
>>>>>>In article <et4hl0$1vlg$1(a)gal.iecc.com>, johnl(a)iecc.com (John L) wrote:
>> Is a 64GW indexing range too small?
>Back then, no.
>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.
I have made no assumption about difficulty other than it exists.
> Especially when one has to maintain backward
>compatibility (something we've been doing for longer than DEC ever had to).
No,no. YOu don't ever maintain backwards compatibility. That's the
mistake that the industry is always making; it is usual fatal.
What you do is not break it unless you clearly state that no
software, other than what ships, will work. If you do this,
you have to state it from the first day when the first sentence
of the project is written; and you have have to make it public
so that the people who would buy your gear can plan. This will
take minimmally three years; I've heard that the product cycles
are six months. Thus this last one can never be an option, IMO.
From: jmfbahciv on 16 Mar 2007 07:58
In article <etbjul$b66$1(a)gal.iecc.com>, johnl(a)iecc.com (John L) wrote:
>>>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
>I was there. It was a different instruction set.
I also was there. The "-20" also was also on the "-10".
The same microcode was shipped to both OS customers.
>>> 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,
This is the key. When you recompiled you used the newer tools
that had the new support. The rule has to be that, once you
rebuild a program, there is no going back to the "old way". That
is how you gently herd your customer base into the corrals
that use the new gear. The ones who stay with the old gear are
not broken; and the ones who buy the new gear slowly adjust
by attrition of their software evolutions.
And I don't know how to reword this last one to make it more
> 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.
I don't understand. Why did you have to change code to run on
a -20 when the backplane was installed? There was nothing, other
than your local requirements, that forced you to change code.