From: glen herrmannsfeldt on
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.

> 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: glen herrmannsfeldt on
Rich Alderson wrote:

> jmfbahciv(a)aol.com writes:

(snip)

>>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?"

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.

-- glen

From: Rob Warnock on
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.


-Rob

-----
Rob Warnock <rpw3(a)rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

From: jmfbahciv on
In article <MeSdnVgMNdXQ5mXYnZ2dnUVZ_rvinZ2d(a)comcast.com>,
pechter(a)pechter.dyndns.org (William Pechter) wrote:
>In article <45f83264$1(a)darkstar>, Eugene Miya <eugene(a)cse.ucsc.edu> wrote:
>>>>backward compatibility
>>
>>In article <et8lva$8qk_003(a)s787.apx1.sbo.ma.dialup.rcn.com>,
>> <jmfbahciv(a)aol.com> wrote:
>>>The people I worked with were very, very,very, very,very,
>>>very good at figuring out backwards compatibility. If you
>>>want to solve those kinds of problems, you get a group
>>>of people who have had extensive experience doing that kind
>>>of thing. At DEC they were the TOPS-10 people who worked
>>>during the 70s, no later. It's not hard to do but does
>>>require a lot of thinking _first_.
>>
>>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.
>
>VAX/VMS was somewhere around '79 or so.
>It was in the 2.5 varient by '82.

And it didn't do backwards compatibility very efficiently.


/BAH
From: jmfbahciv on
In article <45f87561$0$27065$4c368faf(a)roadrunner.com>,
Peter Flass <Peter_Flass(a)Yahoo.com> wrote:
>jmfbahciv(a)aol.com wrote:
>
>> 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?
>
>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.

Sanity check. Now take your design and pretend that it has to
be extended to double that bit width. That is always the key
part to any design. The constraint is that old code doesn't
"know" that fields have been widened.

How much extra work of each extending project is required to
allow old code to execute successfully and consistently?
Note that consistently is more important than getting correct
answers.

/BAH