bruce@cs.su.oz (Bruce Janson) (09/06/90)
Use of dis on large numbers of executables on our MIPSCo machines has revealed no instances of the instructions bltzal or bgezal. It was my understanding that instructions were included in the MIPS instruction set only if their addition could be justified on the basis of an X% performance increase (where X is some randomly chosen number like maybe 1). So, how do bltzal and bgezal increase performance without ever being executed? Cheers, bruce. Bruce Janson Basser Department of Computer Science University of Sydney Sydney, N.S.W., 2006 AUSTRALIA Internet: bruce@basser.cs.su.oz.au Telephone: +61-2-692-3264 Fax: +61-2-692-3838
meissner@osf.org (Michael Meissner) (09/06/90)
In article <1179@cluster.cs.su.oz> bruce@cs.su.oz (Bruce Janson) writes: | Use of dis on large numbers of executables on our MIPSCo | machines has revealed no instances of the instructions | bltzal or bgezal. | It was my understanding that instructions were included | in the MIPS instruction set only if their addition | could be justified on the basis of an X% performance | increase (where X is some randomly chosen number like maybe 1). | So, how do bltzal and bgezal increase performance without | ever being executed? | | Cheers, | bruce. I can't answer the question, but I recently found a use for bgezal. I'm doing pic support for GCC on OSF/1 (Decstation platform), and currently use bgezal $0,func to call functions within the same module that are within 128K rather than using the normal method of loading a pointer from the data table and doing a jalr on it. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?
appel@cs.Princeton.EDU (Andrew Appel) (09/07/90)
The "Standard ML of New Jersey" compiler generates position-independent code (useful, because code is moved around by the garbage collector). To do this, it is sometimes necessary to get the PC into a register. A failing bltzal (BLTZAL r0,anywhere) is a convenient way to do this. On the SPARC, which has no such instruction, we must stand on our heads to do it.
fy@lucid.com (Frank Yellin) (09/08/90)
In article <2509@rossignol.Princeton.EDU>, appel@cs.Princeton.EDU (Andrew Appel) writes: > The "Standard ML of New Jersey" compiler generates position-independent > code (useful, because code is moved around by the garbage collector). > To do this, it is sometimes necessary to get the PC into a register. > A failing bltzal (BLTZAL r0,anywhere) is a convenient way to do this. Lucid Common Lisp has a similar problem. To handle catch frames and unwind-protect code, we need to store the address of code on the stack. The easiest way to do this is bgezal %0, label ; always branch and link move %31, <stack location> <code to deal with unwind-protect or catch frame> label <continuation of normal code> It seems, though, that no one has yet come up with a case in which bgezal or bltzal is ever used with any register other than %0, so that the branch is either always taken or never taken, respectively. > On the SPARC, which has no such instruction, we must stand on our heads > to do it. Sure it does: my-address call label ;; go to label. Put address of my-address into %o7 <some delay slot instruction> ...... label Any place in the code can now be reached by jumping to an offset from %o7 There doesn't have to be any code between the delay slot instruction and the label. And unlike the MIPS, the delay slot instruction can even be a branch, since the preceding instruction is an unconditional branch. -- Frank Yellin fy@lucid.com ...!decwrl!edsel!fy ...!sun!edsel!fy -- -- Frank