Path: utzoo!attcan!sobmips!uunet!zephyr.ens.tek.com!tekcrl!terryl From: terryl@tekcrl.LABS.TEK.COM Newsgroups: comp.sys.m88k Subject: Re: Info about the 88open Consortium and standards Message-ID: <5063@tekcrl.LABS.TEK.COM> Date: 15 Nov 89 19:12:16 GMT References: <1948@psueea.UUCP> <1989Nov14.175806.23483@paris.ics.uci.edu> Reply-To: terryl@tekcrl.LABS.TEK.COM Organization: Tektronix, Inc., Beaverton, OR. Lines: 73 In article <1989Nov14.175806.23483@paris.ics.uci.edu> Ron Guilmette writes: +In article <1948@psueea.UUCP> bruceco@jove.cs.pdx.edu (Bruce Coorpender) writes: +>The 88open Consortium was mentioned in a recent article. It is +> +>Binary Compatability Standard (BCS) +>Object Compatability Standard (OCS) + +I have a technical question about the BCS and the OCS. + +I was unhappy to see that these two standards have mandated (for those who +choose to adhere to them) what I believe is a somewhat sub-optimal function +calling sequence. While it is true that the abundance of registers on the +88k does significantly improve the efficiency of parameter passing in the +great majority of cases, I have been distressed to see that (a) you +are limited to passing at most 8 words worth of actual parameters in +registers (which seems an unnecessary and artificial limit to me) and +(b) more significantly, there seems to have been a major departure from +the common practice in the good ol' CICS days when callers could assume +that almost all registers (except for the one which got the return value) +were *preserved* across a "standard" call. + +It seems to me that (b) effectively ties the hands of many otherwise very +sophisticated modern optimizers (with nice graph-coloring register allocators +of course). Actually, there is a very good reason it was done this way: in many functions, the caller has intimate knowledge of which registers it knows are "alive", and which registers it knows are "dead". "alive" registers must be preserved across procedure calls, and "dead" registers don't. The called function may or may not have as much intimate knowledge of the needs of the caller's register set. +Am I right that this is an artificial "man-made" performance barrier? If +so, what was the motivation? Well, IMHO, you're wrong. It is NOT an artificial "man-made" performance barrier; as with almost all decisions, it was the traditional time/space per- formance trade offs. What has actually happened is that the register set was divided into FOUR sets: the first set is the parameter passing set (which is eight words worth of parameters, as Mr. Guilmette has noted, but there are additional registers used for structure return, etc.), a temporary register set (which are NOT preserved across procedure calls), and a permanent register set (which are preserved across procedure calls). The fourth register set is re- served for linker use; they are used to access global data more efficiently (read the BCS for further info on this). The traditional time/space performance trade offs come into play when a compiler decides to put a variable into either the temporary register set or the permanent register set; I'm no compiler person, but it seems reasonable to me that a compiler can make a better distinction when compiling a procedure to know whether a register should be preserved across a call or not, instead of preserving ALL of the registers (or just the registers the called procedure uses, as in most current C compilers). The rationale behind this is that if the called procedure were to save all registers (or even just the ones it used), it might be doing some unneeded saving and restoring of registers. But the opposite (where NO registers are saved across procedure calls; it is the responsibility of the calling procedure to save whichever registers it will need later) is probably too restrictive; it puts too much burden on the compiler writer (not to mention all the assembler writers, but it's not a pretty sight to program this beasty in assembler!!! (-:). So, a compromise was struck: a temporary register set, and a permanent register set. Now, one can argue that one set should be larger than the other, but that's where one's personal religious beliefs set in, and we all know what that means!!! (-: Just one person's religious beliefs Terry Laskodi of Tektronix