mike@BRL.MIL (Mike Muuss) (02/26/89)
I had heard a rumor that IRIX 3.1 was supposed to produce binary executable programs that would run unchanged on all the different kinds of 4D machines (assuming that the program was adroit enough to avoid hardware-specific routines on machines that could not do them). Is this true in all cases? Is this true only when using the "shared" versions of the libraries? Or is my understanding in error? In my particular case, I compiled a program on a GTX, and tried to run the binary that worked fine on the GTX on a Personal Iris (via NFS). I got the message: Unable to map GM DRAM: No such device Clearly, the Personal Iris does not have a GM, so something odd is happening. Anyone care to share some clues? Best, -Mike
blbates@AERO4.LARC.NASA.GOV (Bates TAD/HRNAB ms294 x2601) (02/28/89)
Someone here had a similar problem. They took an executable from a 4D/60?, and ftp'ed it to a 4D/20 and it didn't work. The SGI sales rep. said it should have, also the SGI hotline said it should have. SGI is looking into it. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
jmb@patton.SGI.COM (Jim Barton) (03/01/89)
In article <8902260158.aa09669@SPARK.BRL.MIL>, mike@BRL.MIL (Mike Muuss) writes: > I had heard a rumor that IRIX 3.1 was supposed to produce binary executable > programs that would run unchanged on all the different kinds of 4D machines > (assuming that the program was adroit enough to avoid hardware-specific > routines on machines that could not do them). > > Is this true in all cases? Is this true only when using the "shared" versions > of the libraries? Or is my understanding in error? > > In my particular case, I compiled a program on a GTX, and tried to run > the binary that worked fine on the GTX on a Personal Iris (via NFS). > I got the message: > > Unable to map GM DRAM: No such device > > Clearly, the Personal Iris does not have a GM, so something odd is happening. > Anyone care to share some clues? > Best, > -Mike Binary compatibility for graphics is only supported using the shared library interface. This can be done by linking with libgl_s, as in -lgl_s. The font manager is machine specific as well, and can be linked as -lfm_s. The actual graphics harware implementations are radically different between Personal IRIS, GT and GTX. This has to be reflected to the user program because it needs direct access to the hardware for speed. Thus, using shared libraries gets you both the speed and the compatibility. For everything else, the machines really are binary compatible. In fact, UMIPS binaries will run on SGI hardware if they stay away from special functions. -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb "I used to be disgusted, now I'm just amused." - Elvis Costello, 'Red Shoes' --
brendan@illyria.SGI.COM (Brendan Eich) (03/01/89)
The bug arose because Sun's xdr_float.c routines are conditionally compiled
to do no conversion #if mc68000, and to do IEEE-to-DEC conversion otherwise.
Alas, when the code was ported to the 3000 (68xxx-based machines as you no
doubt know), mc68000 was assumed to be defined. It isn't; m68000 is (sigh).
Lack of heterogeneous testing allowed both the 3.5 and 3.6 releases to ship
with xdr_float and xdr_double converting the 3000's native floating point
representations to DEC format on the wire, and back again. Of course it
doesn't work so well with other vendor's machines.
The fix is to write your own xdr_float and xdr_double:
bool_t
xdr_float(xdrs, fp)
XDR *xdrs;
float *fp;
{
return xdr_long(xdrs, (long *)fp);
}
bool_t
xdr_double(xdrs, dp)
XDR *xdrs;
double *dp;
{
return xdr_opaque(xdrs, (caddr_t)dp, sizeof *dp);
}
Put the above functions with the necessary includes in xdr_float.c, compile
to xdr_float.o, and utter
ar rv /usr/lib/libsun.a xdr_float.o; ranlib /usr/lib/libsun.a
to install the fix. (These functions could be optimized to use XDR_PUTLONG
and XDR_GETLONG.)
Brendan Eich
Silicon Graphics, Inc.
brendan@sgi.commike@BRL.MIL (Mike Muuss) (03/01/89)
Jim - Thanks for confirming my suspicions. The reason that I stopped using the shared libraries is because PIXIE does not work on programs that have been linked with a shared library. This is a drag. It is not at all clear to me that the choice you made w.r.t. the GL interface was at all necessary. I'm quite certain that you could have carried support for all your different machines around in all versions of the libraries. I believe this could have been implemented in such a way as to only require a single extra memory load (indirection) per subroutine call, a small price to pay. Negative comment: different SGI models are entirely too different, inside. All the work that the GL has to do to hide the differences is unfortunate, and bothersome. Positive comment: "IRIX" version 3.1, for the first time, actually does a pretty good job of doing things. But I still seem to waste a lot of my time trying to accomplish things that should have been simple. -Mike
msc@ramoth.SGI.COM (Mark Callow) (03/03/89)
If you want your GL program to have binary compatibility across all 4D products you *must* link with the shared GL as well as avoiding any hardware (such as alpha planes) that only exists on certain models. You also must only use the exported (i.e. public) entry points of the shared GL. -- -Mark
sch@tachyon.UUCP (Steve Holzworth) (03/11/89)
In article <8902282220.aa21482@SEM.BRL.MIL>, mike@BRL.MIL (Mike Muuss) writes: > Jim - > stuff deleted > It is not at all clear to me that the choice you made w.r.t. the GL > interface was at all necessary. I'm quite certain that you could have > carried support for all your different machines around in all versions > of the libraries. I believe this could have been implemented in such a > way as to only require a single extra memory load (indirection) per > subroutine call, a small price to pay. > Small Price!? I used to work for Ikonas Graphics Systems, writing microcode. I would go to >>extreme<< lengths to pull a Single instruction out of the code. Maybe your application doesn't require "balls to the wall" speed that mine typically do. If so, fine, but for some people, an extra indirection for each graphics call would be foolish when the current scheme of using shared libraries works quite well. > Negative comment: different SGI models are entirely too different, > inside. All the work that the GL has to do to hide the differences > is unfortunate, and bothersome. We are a VAR for SGI products. We sell a high-end CAD system for civil engineering and land planning. We ported from the 3000 series to a 4D70GT in about two weeks. When I went to SGI in August to port onto the Personal IRIS, it took all of a half hour to do. Everything worked, and I assure you, we push every bit of the hardware capabilities. > Positive comment: "IRIX" version 3.1, for the first time, actually > does a pretty good job of doing things. But I still seem to waste > a lot of my time trying to accomplish things that should have been simple. > > -Mike I agree with David Rogers. Every computer system I've ever worked with has had a few quirks. I have no complaints about SGI. Steve Holzworth Stephen Dedalus Incorporated