Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!sundc!texsun!sun!gorodish!guy From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: comp.arch Subject: Re: Was the 360 badly-designed? (was Re: Compatibility with EBCDIC) Message-ID: <26390@sun.uucp> Date: Mon, 24-Aug-87 15:13:07 EDT Article-I.D.: sun.26390 Posted: Mon Aug 24 15:13:07 1987 Date-Received: Tue, 25-Aug-87 07:17:07 EDT References: <855@tjalk.cs.vu.nl> <2683@hoptoad.uucp> <916@haddock.ISC.COM> <1044@bsu-cs.UUCP> Sender: news@sun.uucp Lines: 87 > >"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. I.e., your only complaint is that they didn't wrap a pretty ribbon around a nicely packaged stack construct? Sorry, that alone does not a bad design make. There are many cases where a machine that doesn't provide something as a neatly packaged construct can nevertheless implement that something more efficiently (by execution time, at least, and maybe even by code size) than a machine that does. > 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. Well, there is one difference; *pointers* are 24 bits long on the 360 and successors (except in XA mode, where pointers are 31 bits long). You can use a pointer simply by loading it into a general register and indexing off it; if you want to use a long pointer on an 8086 (other than the 386) you have to monkey with segment registers as well. If you don't like machines with limited offset sizes, you'll really hate MIPS chips or SPARC chips. The MIPS architecture's loads and stores have 16-bit offsets; you have to glue two instructions with 16-bit offsets together to load up a 32-bit address directly. The SPARC architecture's loads and stores have 13-bit offsets; you have to stick a SETHI instruction in front to load the upper 19 bits into a register (SETHI actually loads 22 bits, because that's how many fit into the instruction format). In fact, if you don't like machines that don't give you nice gift-wrapped primitives, you're probably not going to like RISC machines, period. I'm willing to give up a fair bit of gift-wrapping in exchange for performance, and I'm sure a lot of other people are as well. > 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. Yup. EBCDIC certainly is convenient, since '0' is hex F0 and '9' is hex F9, at least according to the EBCDIC-to-ASCII table in the back of the TOPS-20 Monitor Calls manual. > 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.) Well, that doesn't work with EBCDIC, even though alphabetic characters *do* begin with a value that has 0001 as the low-order bits; then again, 256 bytes of translation table can't be too bad. > Case conversion is equally simple: A single bit needs to be flipped. Yup. 'a' = hex 81, 'A' = hex C1. The same pattern holds true for all other alphabetics. Boy, that EBCDIC sure is convenient! > 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. I presume this is intended as a point in favor of SIXBIT, not of ASCII, since EBCDIC has them all as well. Why is the ability to pack characters into 6 bits so wonderful for this application - especially on an 8-bit-byte machine like a 360? > 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. And ASCII as well; the code for 'a' is not between 'A' and 'Z', but 'a' is definitely alphabetic. This is also a property of ISO Latin #1; given that it's based on ASCII, it has to be, since there's no place to put the accented characters that's contiguous with the regular alphabetics. Give a look at the UNIX sometime; all the "is this alphabetic"-type predicates, except for "isascii", are implemented by table lookup - including "isalpha". What's so terrible about table lookup? Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com