🚀 go-pugleaf

In article <c1165d5b-1d41-4f6b...@googlegroups.com>,
Quadibloc  <jsa...@ecn.ab.ca> wrote:
>On Thursday, August 9, 2018 at 3:54:51 PM UTC-6, Bob Eager wrote:
>> On Thu, 09 Aug 2018 17:36:24 -0400, Peter Flass wrote:
>
>> > System/360.
>
>> All that base register stuff...
>
>But surely that's unavoidable, if you want to have more than 64 K of memory?

The issue was that they wanted to have a single architecture that was
usable on a 16K 360/30 and a 4MB 360/70.  So it needed large addresses
in the architecture (should have been 32 bits but they wimped out and
limited it to 24 which was clearly a mistake), but they needed small
addresses in the instructions to make the instruction density high
enough.

Base+displacement addressing was a reasonable approach, but they made
two mistakes.  One is that code addressing should have been PC
relative rather than base relative so the RX and RS branch
instructions should have had 16 bit branch offsets.  This would have
allowed branches 64K in either direction (instructions are halfword
aligned so don't store the low zero bit) which is a lot of code.  They
fixed this much later by adding relative addressing to s/390.

The other was that they thought that base addressing gave them
position independent code, from what they said in the architecture
articles in the IBM SJ.  Branch addressing with BALR to set the base
register is position independent, but pointers stored in memory are
not.  This could have been addressed by disciplined programming (as it
was in TSS/360) but instructions like "load pointer and add base
register" would have given people a hint of how things were supposed
to work.

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly