Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!inuxc!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP
Newsgroups: comp.arch
Subject: Re: Was the 360 badly-designed?  (was Re: Compatibility with EBCDIC)
Message-ID: <1044@bsu-cs.UUCP>
Date: Sun, 23-Aug-87 13:05:12 EDT
Article-I.D.: bsu-cs.1044
Posted: Sun Aug 23 13:05:12 1987
Date-Received: Mon, 24-Aug-87 00:08:11 EDT
References: <855@tjalk.cs.vu.nl> <2683@hoptoad.uucp> <916@haddock.ISC.COM> <1035@bsu-cs.UUCP> <26312@sun.uucp>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 61
Summary: Would love to be brief, but...

"Make every word count!" they say.  So I do, and now I have to clarify.
I wrote this about the IBM 360:

        No stack, small segments, nonstandard character set with holes.

guy%gorodish@Sun.COM (Guy Harris) writes:

>"No stack": what do you mean by "no stack"?  There are no "push" or "pop"
>instructions, and the procedure call instruction saves the return address in a
>register, but so what?  Nothing *prevents* you from implementing a stack.

Exactly.

>"Small segments": what do you mean by "segments"?  The original 360 didn't have
>any sort of memory mapping.  If you *really* mean "12-bit offsets", yes, that
>may be a nuisance, but it's not an insuperable problem, and it may have made
>sense given the design constraints of the day.

Yes, I did mean 12-bit offsets, and they can be a nuisance and not an
insuperable problem, and may (or may not) have made sense given the
design contraints of the day.  The same is often said of the 64-K
blocks of code and data imposed by the 8086 architecture, and I don't
think that that CPU deserves any awards for design excellence either.

>"Nonstandard character set": considering ASCII was relatively new at the time
>(I'm not even sure to what degree ASCII *existed* in 1963!), this is simply
>bogus.
>
>"with holes": well, ASCII has holes, too; why aren't "0-9" and "a-f" or "A-F"
>contiguous?

ASCII did exist then.

ASCII was designed quite logically.  It's convenient to have the digits
begin with a value that has four low-order zero bits, so one can simply
mask with binary 11110000 and get the numeric value of the digit
character.  It's convenient to have the alphabetic characters begin
with a value that has 0001 as the low-order bits, for one can mask with
binary 00011111 and get a number representing the position of the
character in the alphabet.  (E.g., 'Z' & 0x1f gives 26.)  Case
conversion is equally simple:  A single bit needs to be flipped.  One
can derive a neat subset alphabet by using only the low-order 6 bits.
One gets all the arithmetic operators, all the essential mathematical
symbols including (), <, =, and >, and all the digits--perfect for use
in a calculator.  The set of control characters neatly maps to the
alphabetic characters by flipping a single bit, allowing the logical
"control A", ^B, etc. notation to be used.  (There aren't enough
alphabetic characters to go around so you also have ^[ etc. but one
can't blame ASCII for that.)

There were a few other design thoughts that went into ASCII but I don't
remember them; I seem to faintly remember there was another way of
deriving a subset alphabet.  Certainly it wasn't put together
haphazardly like EBCDIC was.  It's hard to defend a character set in
which (x >= 'A' && x <= 'Z') doesn't assure us that x is alphabetic:
this is plainly a very undesirable property of EBCDIC.  On the other
hand, perhaps we should count our blessings and be thankful that IBM
chose to make the digits contiguous, so we don't have to use a lookup
table to evaluate a string of digits.
-- 
Rahul Dhesi         UUCP:  {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi