rjh@ihuxj.UUCP (Randolph J. Herber) (05/09/84)
>>Well, I don't know how dependent Unix really is on ASCII, but the folks >>at Amdahl probably thought it was dependent enough that they use ASCII, >>even though the underlying IBM-370 architecture is geared towards >>EBCDIC. >>-- >> Barry Margolin >> ARPA: barmar@MIT-Multics >> UUCP: ..!genrad!mit-eddie!barmar >This response should really be in net.arch, but I don't >agree that the IBM machine is really geared toward EBCDIC. >What is EBCDIC are the line printers, the card punches >and readers, and terminals, or, in other words, the >peripherals. If you could get your C compiler typed in in >ASCII and compiled, then the IBM compare instruction >works just fine on ASCII. Its all a big conspiracy >and a long chain of source text bootstrapping EBCDIC >along. > Joseph L. Wood, III > AT&T Information Systems > Laboratories, Holmdel > (201) 834-3759 > ariel!jlw >My recollection of the only 370 EBCDIC dependencies in the HARDWARE >are some instructions for converting strings to packed decimal internal >representation. Some floating point conversion algorithms may use >these instructions to good effect... > -- Alan Robertson > ihnp4!drutx!alanr > AT&T Information Systems > 11900 N Pecos > Denver, Colorado 80020 IAW GA22-6821 IBM System/360 Principles of Operation: "The sign and zone codes generated for all decimal arithmetic results differ for the extended binary-coded-decimal interchange code (EBCDIC) and the American Standard code for information (ASCII). The choice between the two codes is determined by bit 12 of the PSW. When bit 12 is zero the preferred EBCDIC codes are generated, which are plus, 1100; minus, 1101; and zone 1111. When bit 12 is one, the preferred ASCII codes are generated which are plus 1010; minus 1011; and zone 0101." IAW GA22-7000-8 IBM System/370 Principles of Operation: "COMPATIBILITY BETWEEN SYSTEM/360 AND SYSTEM/370" System/370 is forward-compatible from System/360. A program written for the System/360 will run on the System/370 provided that it:" "2. Does not use PSW bit 12 as an ASCII bit ...." BTW, PSW bit 12 is used in IBM System/370 to control the PSW format. When the bit is zero, the machine and PSW format is in Basic Control mode. When the bit is one, the machine and PSW format is in Extended Control mode. It is my understanding that the main reasons for using ASCII in Amdahl's UTS are efficiency and program reliability. Many programs are coded assuming the characteristics of the ASCII character set. Further details on this topic I do not have. Randolph J. Herber, Amdahl Senior Systems Engineer, ..!ihnp4!ihuxj!rjh, (312) 979-6554, or Cornet Indian Hill x6554, Amdahl Corp., Suite 250, 6400 Shafer, Rosemont, IL 60018, (312) 692-7520
koved@umcp-cs.UUCP (05/10/84)
There appear to be only 2 instructions which are EBCDIC dependent -
PACK and UNPACK. These are used to convert EBCDIC digits to packed
form which is used for arithmetic, or can be further converted to binary.
Conversion from EBCDIC to ASCII and back is trivial...use a translate
table (256 bytes) for each direction, and a single instruction (TRanslate)
to convert up to 256 bytes at a time.
BTW, ASCII terminals are frequently attached to IBM Mainframes.
Two methods are possible. The direct attach (or dial-up) is done,
and typically supports the IBM 3101 (an ASCII terminal) or other
types of TTY. The other method is to attach to an external box
(typically the IBM Series/1) which does the conversion between
character sets.
I hope this clears up some of the confusion.
P.S. The only devices which are character set dependent are the
display units (3270 type devices), and printers. Some are EBCDIC,
and some are not. Codes may be device dependent.
--
Spoken: Larry Koved
Arpa: koved.umcp-cs@CSNet-relay
Uucp:...{allegra,seismo}!umcp-cs!kovedguy@rlgvax.UUCP (Guy Harris) (05/19/84)
> "I don't agree that the IBM machine is really geared toward > EBCDIC." > A program running on an 370-architecture machine can convert a binary > number to an EBCDIC string in two instructions. There is no > corresponding conversion to ASCII, though there was an "ASCII mode" bit > in the Program Status Word on the 360 line, dropped in the 370 line. A binary number can, however, be converted to ASCII in three instructions on a 370-architecture machine; "CVD", "UNPACK" or "EDIT" or "EDMK", and "TR". This counts as a bit of a kludge in my book, though, because it requires an intermediate result (the EBCDIC string) which is thrown out after translation to ASCII; this wouldn't have been necessary with an ASCII mode. Somebody brought up the point (in one of these discussions) that "EDIT" and "EDMK" use three codes in the edit pattern string for special purposes, and that those codes correspond to ASCII space <SP> and two other printable characters. Anybody out there with a System/*360* Principles of Operation (I think we have a 370 PrincOps in house, but it wouldn't help) know what "EDIT" and "EDMK" did about this in ASCII mode? Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
eager@amd70.UUCP (Mike Eager) (05/22/84)
About attaching ASCII terminals to IBM S/370 systems: Most use an IBM 3704 or 3705. This is a terminal concentrator & frontend. It does many wonderful and magical things. Given the channel structure of the 370, I doubt that anyone has a direct connect. The 3705, by the way, is a IBM 360/50, in disguise, unless I've been lied to. Considering the LARGE number of ASCII constants embedded in C programs, I would be surprised if the UTS system used EBCDIC internally. I imagine that there would be code dependencies in many programs.
gam@proper.UUCP (Gordon Moffett) (05/22/84)
# Virtually ALL the application programs on UTS written in C assume that ASCII is the base character set. In fact, many of the programs you are familiar with on other architectures are just the same on UTS. (but -- see below about type ``char''). The ``virtually'' refers to two cases (that I know of) where EBCDIC is used: in device drivers for EBCDIC-based devices (like 3270's (ibm tubes)), and programs that read/write volume lables on tapes or disks. The drivers are doing EBCDIC <--> ASCII translations, and the volume labels are artifacts of an Amdahl-compatable environment. The applications (and for the most part systems) programmer need never be aware of EBCDIC on UTS. Oh, by the way, the type ``char'' is unsigned in UTS/370-architecture, so for all you people who've been writing: char c; while ((c = getc()) != EOF) ... ... you have frustrated my work very much .... UTS is a registered trademark of Amdahl Corporation.