mash@mips.COM (John Mashey) (08/28/89)
NOTE: this discussion is a generic one, not a comp.sys.mips one..... In article <1989Aug26.232710.27174@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: ....... >The same is true of the architectural tweaks on many modern machines. For >example, according to John Mashey, the MIPS machines make a considerable >effort to do precise exceptions because the OS people got quite upset about >the alternative. The difference is that modern OS people don't see any need >to reinvent the square wheel, so the issue is how to *support* the system, >not what it should look like. Well, actually, it was more a combination of people worried about IEEE FP (where precise exceptions are not necessary, but certainly help), and the OS folks. > >>...To a certain extent, language design is >>approaching the same point: Support C and figure you are done..... >Might one ask how many RISC designs you are acquainted with? The SPARC, >the MIPS architecture, and the HP Precision Architecture, to name three, >were all designed with considerable attention to multi-language support. >The fact is, supporting C well is very nearly enough to support the other >"conventional" languages well. (Note, "very nearly" -- some attention to >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. Actually, it turns out that HP PA has a few instructions that specifically aimed at decimal arithmetic, although they are RISC-decimal arithmetic, not CISC-decimal arithmetic; and the unaligned instructions in MIPS happen to be helpful also. I don't know offhand the language set on HP PA, but it's likely extensive. SPARC has lots of languages, although more heavily oriented to A/I and university research areas. MIPS supports, directly: C, FORTRAN, PASCAL, ADA, COBOL, and PL/1 As third-party packages (i.e., product stuff you can buy today), you can get: 3 BASICs: NKR, BBX Business Basic, Pick Basic (VMARK) 3 more COBOLs: MicroFocus COBOL/2, ACUCOBOL-85, Visual COBOL/85 (mbp) 2 LISPs: Franz Allegro Common, IBUKI Common 2 Prologs: Edinbrugh, IF/Prolog 1 MUMPS: MIMPS-ON-UNIX, Plus-Five 1 RPG II: UNIBOL/RPG II, Software Ireland As one interesting example, we hear that MicroFocus COBOL runs, on an M/2000, at close to Amdhal 5860 speed, which is about what it does on other kind of programs [this is vague; try "close" == (+/- 20%)]. Somewhere, there was a fine article written by someone at HP on the HP PA design methodology, including a few paragraphs on the rationale for dealing with COBOL as they did, with numbers. Wherever it was, it's at least 2 years old. Maybe somebody from HP remembers where it is and would kindly cite the reference, or maybe even quote the parts relevant to COBOL. Finally, as usual, SOFTWARE IKS HARDER THAN HARDWARE. For example, a FAR WORSE problem than the instruction set is making sure that object file formats can express all of the necessary data types [most UNIX symbol tables can't, for example], and that languages that ought to be linkable and source-debuggable together do, etc. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
daryl@hpcldko.HP.COM (Daryl Odnert) (09/12/89)
John Mashey writes: > Somewhere, there was a fine article written by someone at HP on the > HP PA design methodology, including a few paragraphs on the rationale > for dealing with COBOL as they did, with numbers. Wherever it was, > it's at least 2 years old. Maybe somebody from HP remembers where it > is and would kindly cite the reference, or maybe even quote the > parts relevant to COBOL. I believe the article John is talking about is "Hewlett-Packard Precision Architecture Compiler Performance" by Karl W. Pettis and William B. Buzbee, Hewlett-Packard Journal, Vol. 38, No. 3, March 1987, pgs 29-35. A couple of quotes from the article: "There are two instructions, DCOR (decimal correct) and IDCOR (intermediate decimal correct), that provide invaluable assistance for decimal arithmetic. One of the criticisms often leveled at typical RISC architectures is that they provide insufficient support for decimal operations, [...]. Using a biasing scheme and the DCOR and IDCOR instructions, compilers for HP Precision Architecture systems can implement decimal additions and subtractions with the ordinary ADD and SUB instructions and minimal extra instructions." "HP Precision Architecture machines running the most popular COBOL processor benchmarks outperform their CISC counterparts by a factor of 1.3 to 4.2, above and beyond differences in the the machines' respective MIPS rates. Furthermore, this performance is achieved using 15% to 30% fewer inline instructions." Daryl Odnert daryl%hpcllla@hplabs.hp.com Hewlett-Packard ...!hplabs!hpcllla!daryl California Languages Lab
mash@mips.COM (John Mashey) (09/13/89)
In article <650013@hpcldko.HP.COM> daryl@hpcldko.HP.COM (Daryl Odnert) writes: >John Mashey writes: >> Somewhere, there was a fine article written by someone at HP on the >> HP PA design methodology, including a few paragraphs on the rationale >> for dealing with COBOL as they did, with numbers. Wherever it was, >> it's at least 2 years old. Maybe somebody from HP remembers where it >> is and would kindly cite the reference, or maybe even quote the >> parts relevant to COBOL. >I believe the article John is talking about is "Hewlett-Packard >Precision Architecture Compiler Performance" by Karl W. Pettis and >William B. Buzbee, Hewlett-Packard Journal, Vol. 38, No. 3, March 1987, >pgs 29-35. I've managed to lose my copy of that somewhere. What I was looking for was the details about the analysis of the operations spent in a COBOL environment actually doing decimal operations, i.e., with a rationale likeothe following, and based (I think) on HP3000 numbers: W % of the operations are spent in the OS X % of the operations are spent in I/O handlers, ISAM, etc, if not inside the OS Y % of the operations are actually spent inside the COBOL program. Of the Y %, much of the time is spent doing moves, branches, leaving Z% actually doing decimal arithmetic, where Z% is (unless my memory fails me) on the order of 1%. From there the main task is to make sure that there is just enough support in the hardware to make sure that a small operations-percentage doesn't turn into large cycle-count-percentage by a complete lack of support. I.e., if most operations were about 1 cycle, but the decimal ones took 100 cycles to implement, then about 50% of the time would actually be consumed. Hence, if there is modest help for the problem that would, say keep the decimal work down to a few cycles per operation, they would be reasonable to have (which is, of course, the conclusion HP came to, for its job mix). Anyway, that is my recollection. My accurate quotes would be good to hear. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086