Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!network!sdcsvax!ucsdhub!hp-sdd!hplabs!hpda!hpcuhb!hpcllla!hpclisp!hpclscu!shankar From: shankar@hpclscu.HP.COM (Shankar Unni) Newsgroups: comp.arch Subject: Re: Re: VAX bashing and language specificity of processors (Was: Memory utilization & inter-process contention) Message-ID: <650012@hpclscu.HP.COM> Date: 28 Aug 89 20:43:47 GMT References: Organization: Hewlett-Packard Calif. Language Lab Lines: 28 Henry Spencer writes: > the fine points is still desirable.) Compiler designers today understand > that it may be better to convert COBOL numbers to binary for arithmetic > than to mess up the hardware with decimal instructions, for example. > COBOL programs are seldom arithmetic-bound anyway. A minor point (I agree with everything else you said on this topic): It is *not* generally OK for COBOL numbers to be converted to binary for arithmetic. COBOL programmers work in exact fixed point fractions. Converting to floating point, while taking care of the magnitude, leaves much to be desired in terms of precision. Integer arithmetic has the opposite problem: precision is fine, magnitude is not. Usually, the programmer determines what numbers may be stored in binary form, and what in BCD (the "USAGE COMP(n)" phrase determines what representation is used). What we (HP) do for COBOL on HP Precision Architecture is to use finely-tuned BCD libraries for doing BCD operations. There are a couple of instructions (like DCOR - Decimal CORrect) for low-level decimal operations on packed BCD, so these libraries are generally quite fast. Besides, as you pointed out, COBOL programs are rarely arithmetic-bound. ----- Shankar Unni E-Mail: Hewlett-Packard California Language Lab. Internet: shankar@hpda.hp.com Phone : (408) 447-5797 UUCP: ...!hplabs!hpda!shankar