Path: utzoo!mnetor!uunet!husc6!bbn!uwmcsd1!ig!agate!ucbvax!hplabs!sdcrdcf!csun!csuna!aeusesef From: aeusesef@csuna.UUCP (sean fagan) Newsgroups: comp.arch Subject: Re: More than 32 bits needed where? Message-ID: <1046@csuna.UUCP> Date: 7 Feb 88 01:07:33 GMT References: <235@unicom.UUCP> <28200089@ccvaxa> <3104@watcgl.waterloo.edu> <19667@bu-cs.BU.EDU> <625@cresswell.quintus.UUCP> <4947@pyr.gatech.EDU> Reply-To: aeusesef@csuna.UUCP (Sean Eric Fagan) Organization: California State University, Northridge Lines: 67 Keywords: Cybers 170/180 Power waste?! In article <4947@pyr.gatech.EDU> kludge@pyr.UUCP (Scott Dorsey) writes: > I routinely code on the CDC 170 machines (60 bit word, 6 bit character) >and the CDC 180 machines (64 bit word, real ASCII). Overall, the character >handling capability of the long word architecture is pretty good. Character handling is strange on these machines (for those of you who are unfortunate enough to never have worked on one): CDC normally uses a 6-bit character set, allowing 10 characters per word. (This is, by the way, why the linker, compilers, etc. usually allow only 7 character identifiers: it words out to 7 characters, plut 18 bits leftover for the address [only an 18-bit address].) You can also use 8 bit ASCII, or a modified version which uses up 12 bits per word. To get any individual character, you need to form a mask, load the desired mask, do an AND, shift, and, bingo, you're done. Since you can't use a memory location for the source or destination, you have to use up a register for each operation (true, you can overlap, but that slows the bigger models down). Compared to other machines, it's horrendous. However, since it is such a fast machine, it tends to go MUCH faster than most others. (this is a partial plug for equipment CDC no longer manufactures 8-)) Oh, you could also get a Compare Move Unit for most (or at least some) of the models, which could move any arbitray 6-bit string to any other 6-bit string (that way, you could get a 6-bit character out of one word into another in about 3 clock-cycles [plus memory access times]). >The 180's >provide nice conversion routines, and block off 8 character conversions and >string searches with a minimum of bus cycles. Actually, the byte-accessibility is handled by the hardware (actually by the microcode; it does allow byte addressing, however, for data fetches), and the string searces are also handled by the microcode. Since the slowest machine in this line I've worked with has a 20-MHZ clock, yes, it does tend to do things rather quickly. 180 state machines also (with one exception) have 170 state emulation; and, since some customers wanted it, they added the CMU to the 170 microcode. Also of interest, a 180/830 has up to 16 states it can run (i.e., it can have 16 different microcodes running at the same time [like multi-tasking]; sadly, they never did anything with this, and later models only had 2 states [and their really low end mainframe, the 180/930 [aka the washing machine because of its size and shape] only has 1: it doesn't run NOS, just NOS/VE [Networked Operating System/Virtual Enviornment]). > Overall, though, it's not worth it. These machines are excellent number >crunchers (having a 64-bit real is a spectacular thing... Double Precision >is 128 bits!), but most of the power is wasted. What?! Power is never wasted. We (at CSU) have, at times, up to 120 students on a 170/750 AT THE SAME TIME! Without the power it provides, it would take *minutes* to compile a 5-line FORTRAN program. As it is, it can do it in under 1 minute! It's also the only machine I've been on where I can compile a 10,000 line FORTRAN program in under 3 minutes (conservative estimate, somewhat). I will admit, most people don't use the Double Precision, but, when you need it, you *really* need it. Well, sorry for lecturing about it. Since I started working for a living on the machines, my respect for the hardware has grown incredibly. The OS, on the other hand... >Scott Dorsey Kaptain_Kludge >SnailMail: ICS Programming Lab, Georgia Tech, Box 36681, Atlanta, Georgia 30332 ----- Sean Eric Fagan Office of Computing/Communications Resources (213) 852 5742 Suite 2600 1GTLSEF@CALSTATE.BITNET 5670 Wilshire Boulevard Los Angeles, CA 90036 {litvax, rdlvax, psivax, hplabs, ihnp4}!csun!csuna!aeusesef