Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.arch
Subject: Re: Re: IBM and those upper 8 bits
Message-ID: <5294@utzoo.UUCP>
Date: Mon, 18-Mar-85 19:25:58 EST
Article-I.D.: utzoo.5294
Posted: Mon Mar 18 19:25:58 1985
Date-Received: Mon, 18-Mar-85 19:25:58 EST
References: <511@ima.UUCP>
Organization: U of Toronto Zoology
Lines: 73

> terak!doug thoughtfully came to IBM's defense saying that in 1964 a 24-bit 
> address space seemed entirely adequate for the projected life of the 360.  
> I think you can make a pretty persuasive case that even at the time they were 
> shortsighted.  

It depends on which IBMers you are looking at.  If you ignore the software
(groan) then the only place where the 360 architecture is really tied to
24 bits is that its i/o channel architecture is limited to 24 bits.  The cpu
proper doesn't interfere (much) with the idea of leaving the top 8 bits
for future address expansion, but the i/o data structures don't have room.
Gene Amdahl has said that this was a deliberate tradeoff, not just a
matter of shortsightedness.  They recognized the potential future problem,
but short-term economic considerations in the i/o hardware were compelling.

> There was also an article on the addressing scheme, in which it looked to me 
> like they sincerely believed that their base-displacement addressing scheme 
> would get them the advantages of virtual memory without the cost of building a 
> DAT box.  ...
> ...  But then it appears 
> that they thought that they could get the effect of dynamic relocation by 
> merely changing the base values in the registers.  Well, that's true, sort of, 
> except that there's no way to tell which registers contain pointers and which 
> don't, since the registers are all the same, and in any event any real program 
> has lots of pointers stored away which will later be loaded into registers and 
> dereferenced.  Whoops again.  I think again it's the case of proof by lack of 
> imagination ("I can't imagine why anybody would want to do that...  .") 

Again, it depends on *which* IBM people you listen to.  Some of them
knew all along that this wouldn't work, and why, and said so.  The issue
of Annals of Computing a while ago that reprinted IBM's internal SPREAD
report also had a panel discussion among a bunch of the original 360
designers.  This issue, among others, came up.

> Finally, you can ask why the software wasn't written to be upgradable to 32 
> bit addresses so at least it might run on the 67.  I hear that as the OS/360 
> project ran along, people got increasingly upset about how large it was 
> getting and programmers got brownie points depending on how small their stuff 
> was.  Data structures in the user space rather than system space didn't count, 
> which is why practically every data structure is indeed in the user space and 
> it's up to you to allocate it, initialize it, and be careful not to clobber 
> it.  Furthermore, the bureaucracy was so big and huge that it apparently took 
> six months to get a new data structure approved by the data structure 
> committee so that programmers took to whispering in the halls and agreeing to 
> put a few bits they needed to communicate into some otherwise unused hole in 
> an existing data structure so they could continue working.  Under those 
> conditions, it's no surprise that the high-order byte of practically every 
> address in every data structure in the entire system was stuffed full of bits, 
> and that IBM now has a major mess on their hands going to 32 bit addressing.  

Fred Brooks's book The Mythical Man-Month discusses these problems in
some detail.  (Brooks was one of the people at the top during the OS/360
development.)  You've got the outlines right, but the details are a
bit different.  One of the big mistakes was that core budgets for the
various modules were fixed before the detailed functionality was pinned
down.  So any time a programmer ran short, he looked for something he
could push out into user space, or into somebody else's module.  Or he
added an overlay, since there was no overlaying-rate budget; Brooks
mentions that there was a lot of unhappiness when the first OS/360
performance simulations came in.  It's probably true that some of these
things aggravated the use-those-spare-bits problem.

Ghod, I sound like I'm defending IBM...  They'll throw me out of the
Unix guru's union...  I guess what I'm saying is that one should not
assume that everyone at IBM was so stupid that they couldn't see these
things coming.  Most of these problems were anticipated to some degree.
Internal politics and short-term gain sometimes got in the way.  Even
when they didn't, nobody knew for sure how to run something like this,
so nobody recognized that some early management decisions were mistakes
with far-reaching consequences.  And the "army of ants" implementation
method sure didn't help.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry