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