Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!gatech!hubcap!ncrcae!ncr-sd!hp-sdd!hplabs!pyramid!prls!mips!larry
From: larry@mips.UUCP (Larry Weber)
Newsgroups: comp.arch
Subject: Re: Was the 360 badly-designed?  (was Re: Compatibility with EBCDIC)
Message-ID: <625@gumby.UUCP>
Date: Wed, 26-Aug-87 10:43:12 EDT
Article-I.D.: gumby.625
Posted: Wed Aug 26 10:43:12 1987
Date-Received: Fri, 28-Aug-87 06:43:06 EDT
References: <855@tjalk.cs.vu.nl> <2683@hoptoad.uucp> <916@haddock.ISC.COM> <1044@bsu-cs.UUCP> <26390@sun.uucp> <3345@ptsfa.UUCP>
Reply-To: larry@gumby.UUCP (Larry Weber)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 59

Getting into this mess may be a mistake, but here it goes...

In article <8471@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>> I repeat my statement: one needs VERY good arguments to claim that the 360
>> architecture was badly-designed.  Anyone care to provide them or refute them?
>
>Ask any 360 compiler implementer about base registers.  Wear your asbestos
>suit.

I never did a 360 compiler but I had a hand in some 370 compilers including
PLS (IBM's internal systems language) and Pascal/VS.  Yes, the small span base
registers are a pain. For data you have to treat memory as if there were lots
of base registers creating each when when an if needed, each pointing
to the next 4KB of data.  If you are lucky enough to have an 
optimizer (even a local common sub-expressions) you can common
references to data items in the same 4K.  But honestly data isn't a 
problem,  if you have more than 4KB it is likely to be in an array, 
and then array references techniques are used.

Code references are a different story, it is easy to exceed 4KB of code and
you need a way to handle this case.  A simple solution is to allocate 2
registers for this purpose and be sympathetic when people call to complain.
The real solution requires dividing the code into blocks and load base
registers appropriately on entry into the block - a real messy problem.  Another
way is to never use base/displacment branches unless you know its span
will be less than 4KB, when you don't know, you generate a branch that 
uses a load first to get the address into a reg then do an indirect branch. 
Other solutions, you could compile, and then recompile when you run out
of branch span and use one of the previous tricks in that case.

Now that we've shown that 360's have an ugly problem in adrressing, can we
conclude that it was badly-designed.  I don't think so!  Whether you agree
depends on how much weight you give to all those arguments already
advanced; it will forever by a matter of opinion.  But for me, and despite
all the ugly features that I DON'T LIKE: it has aged well and been extended
in may ways not anticipated by the original designers.  Lots of people
build fast versions of them, and I doubt that DEC just isn't interested in
building fast VAXEN - its harder to do.  EBCDIC has its problems, but it
is designed for international charater sets (if only they could have
gotten [] right), and it was designed to be closely related to BCD. 

The operating systems are NOT works of art. Memory management is abysmal and
IO is messy (kinda like VMS).  They are quite usable, especially with SPF
for MVS, I always felt SPF was a step back for VM/CMS.  

This whole topic sounds like another "the big guy is bad". There are lots to be
learned from 360/370, some are good ideas, like lots of registers that are
the same.  Lots of bad ideas like small dispalcements.  There are many on
new architectures lately, many seem pretty good, but time will tell.

Here's a toast to use at your next party:
  May you favorite architecture be as healthy as the 360/370 in 25 years!

Larry

-- 
UUCP: 	decwrl!mips!larry
DDD:  	408-720-1700
USPS: 	MIPS Computer Systems, 930 Arques Avenue,  Sunnyvale, CA 94086