Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!think!ames!oliveb!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: <26940@sun.uucp>
Date: Tue, 1-Sep-87 03:18:21 EDT
Article-I.D.: sun.26940
Posted: Tue Sep  1 03:18:21 1987
Date-Received: Sat, 5-Sep-87 01:49:55 EDT
References: <855@tjalk.cs.vu.nl> <2683@hoptoad.uucp> <916@haddock.ISC.COM> <304@nuchat.UUCP>
Sender: news@sun.uucp
Lines: 50

> In response to your statement that ASCII has "holes", I agree that
> the separation of "0-9" from the alphabetic characters is in rare
> cases a nuisance, but I think it is far easier to check for numbers
> and the sets of upper and lower case letters in ASCII than to try
> the same thing in EBCDIC.

You may think that, but you're wrong.  In *either* code set, you can test
whether a given code is a digit by seeing whether its numerical value is
between that for '0' and '9'.  The EBCDIC chart from the TOPS-20 manual
indicates no characters in the gaps in the alphabetic characters; if there
really are no such gaps, you can test whether something is an upper-case or
lower-case alphabetic in the same fashion in EBCDIC as you do in ASCII.

Then again, all this is somewhat irrelevant; indexing into a 256-byte table of
character type codes is equally easy no matter *what* character set you use.

> Also, if you look at the binary encoding of ASCII, these "holes" make sense.
> The numerical difference between the upper and lower case versions of a
> letter is 32.  This is because lower case letters have bit 5 set, while upper
> case letters do not.  Given this convenient (although rarely used anymore)
> mechanism for differntiating upper and lower case letters,

Which, as I pointed out, is also present in EBCDIC (I presume you mean for
*converting* betwen upper and lower case letters; the value of bit 5 is not
interesting unless you've already determined that the character is a letter,
and as long as you're determining *that* you might as well determine the
character's case at the same time).

> To further simplify things, the numbers are contiguously located at 48-58.
> Thus, they can be decoded by AND-ing their ASCII values with 15.

As opposed to EBCDIC, where the numbers are contiguously located at hex F0 to
hex F9, where they can be decoded by AND-ing their EBCDIC values with 15.

What was the point you were trying to make with this?

> [BTW - The complaint about "no stack" was undoubtedly referring to
> the lack of a hardware stack or a set of instructions designed for
> efficiently implementing a stack.  You can implement a stack on almost
> any machine.  That doesn't change the fact that it would be useful to
> have one built in]

Umm, I don't know that I'd use the term "fact" here; that claim is very
questionable.  There are plenty of quite fast machines out there that don't
have whizzo instructions designed for "efficiently" implementing a stack.
Even die-hard assembler programmers can synthesize stack instructions with a
macro assembler.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com