Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!dimacs.rutgers.edu!seismo!uunet!wuarchive!sdd.hp.com!hp-pcd!hpfcso!mjs From: mjs@hpfcso.HP.COM (Marc Sabatella) Newsgroups: comp.sys.hp Subject: Re: HP9000 performance Message-ID: <7370306@hpfcso.HP.COM> Date: 6 Feb 91 16:29:21 GMT References: <13092@sunquest.UUCP> Organization: Hewlett-Packard, Fort Collins, CO, USA Lines: 64 > I could see someone thinking of this, as an aid to portability, as > long as there was some good way to distinguish between machines so > that I didn't try to use "7.0 executables" on an "S200 or Model 310". > I expected that the "good way" was with the series of > /bin/hp9000s[2358]00 programs > ... > Does this mean that programs are binary-compatible to the point of not > using features of a math coprocessor that wern't present in the > 68010-generation version? Exactly what is going on here? The /bin/hp9000* programs are not all that useful for your purposes, as you have noticed. Programs are "upward compatible" in that s200 programs should work on a 300, 68010 programs should work on a 68020/30, etc. But not "backwards compatible" - a program compiled for a 68020/30 will not be likely to run on a 68010, since it may use addressing modes and math functions not supported on that processor. As explained below, we do take (almost) full advantage of the 68040, but since there are no new addressing modes, and only one useful new instruction, 7.40 and later code is optimized for the 68040, but will still run on 68020/68030. The "version" field also reported by "file" on a 200/300/400 can be of some help here. "version 0" means compiled before 6.5, but unfortunately there is no way to tell if it uses any 68020-isms or 68881-isms that won't work on a 68010. Starting at 6.5, version numbers were assigned meaning: 1 means requires only a 68010, 2 means requires a 68020/68030, and 3 means, well, that the program depends on the >= 6.5 floating point save/restore conventions. Prior to 6.5, all floating point registers were considered scratch; at 6.5, when we added the global optimizer, routines were expected to save and restore all but %fp0 and %fp1. "version 3" then has meaning for an object file, mainly - it tells the linker that the code within the module expects all routines it calls to save and restore floating point registers, which all compiled routines starting at 6.5 do. But the linker can then warn if you try to mix "version 3" with "version 0", which don't save and restore any floating point registers. Starting at 7.0, the compilers no longer generate code that will run on a 68010, since 7.0 itself is not supported on 310's. Thus everything now is either version 2 or 3. What all this means: anything with a non-zero version will not run on a plain 68000. Anything with version >1 will not run on a 68010. There is no way to tell with a program with a version of zero; it must have been compiled before 6.5, so it is at least possible it will run on a 68010. By the way, as Mike McNelly points out, there are almost no worthwhile opcode improvements from 68000 to 68040; most improvements were addressing modes (like the indexed modes on the 68020/68030). For the 68040, those particular addressing modes are slow. The 68040 is very RISC-like if you do RISC-like things, but complex addressing modes and instructions delay the pipeline. So it turns out that the best code for the 68040 is often code that will run on a 68010. The one exception is the new move16 instruction, which is good, but not so good that we wanted to have to go back to supporting two compile paths (one for the 68040, one for 68020/68030). However, several library routines have been handcoded in assembly language and use the instruction after checking to see if it is running on an '040. Regarding the FPA: there is no way to tell if a program requires it. Good idea though; I'll submit this as an enhancement request. -------------- Marc Sabatella HP Colorado Language Lab (CoLL) marc@hpmonk