MIPSpro

MIPS Pro is a commercial software compiler suite. It comprises of Fortran,C, C++ compilers and Pro Dev Workshop. It comprises a foundation CD, which contains base tools like assemblers and linkers and compiler CDs and overlay CDs. Last known released version 7.4.4.

Availability

• Purchase from SGI. Expect a huge shock at the price, which varies from country to country and is unrelated to any laws of Economics (or Time or Physics).
• Joining a SGI developer program. This is free. However, the process of acquiring a MIPS Pro license requires a corporate credit check to establish a "business relationship". This is easier with a company that has been operating for several years and demonstrated commercial products.
• Black areas (ebay, etc).. Software Piracy is not to be discussed or associated with the forum or nekochan site for various legal reasons.

Licenses

New Licenses are granted from Key-o-matic. There may also be licenses from other sources. Licenses are managed with the FLEXlm license manager.

An unlicensed copy of the compiler (from say a black area) will display a page of text on how and where to contact SGI to purchase a legitimate license when asked to compile each and every source file. Other than the annoying "nagging" the compiler will operate normally. For the record, the originator of this topic has a legitimate copy and license granted by SGI.

Pragmas

See Also

• MIPSpro C/C++ Pragmas (document number: 007-3587-005)

Porting

Notes on building Open Source software on IRIX

This is a draft document to help people build open source software on IRIX. It may be missing some items but having built literally hundreds of packages on IRIX over the years we're pretty confident that most of the pitfalls are covered. General

IRIX has a very comprehensive Unix API. Not only it is POSIX and POSIX-2 compliant, it is also compliant with XOPEN XPG/4, SVID (SystemV R4), BSD extensions, Unix 95 (Spec 1170) and more. Software that compiles on other UNIX'es (notably those with a smaller API, like Linux and Free/Open/Net BSD), should, almost with no exceptions, compile and run smoothly on IRIX. But read on...

Still there's way too much software out there that makes non-portable assumptions or is written improperly, which may cause problems. Here's an item list to save you time porting open source software to IRIX.

GNU configure and autoconf

GNU autoconf generates configure scripts that assume that if a library exists, it should be used. This is incorrect on IRIX, which keeps some old libraries around just for the sake of backward compatibility with very old programs. This alone breaks most of the GNU utilities on IRIX. To prevent this from happening, simply force GNU configure to explicitly ignore 'libsocket', 'libnsl', 'libgen' and 'libsun'. All these interfaces have their up-to-date entries in the standard C library libc.so on IRIX 6.x.

For example, when calling GNU configure you should use something like:

       ac_cv_lib_gen_getmntent=no \
       ac_cv_lib_sun=no \
       ac_cv_lib_sun_getpwnam=no \
       ac_cv_lib_sun_getmntent=no \
       ac_cv_lib_sun_yp_match=no \
       ac_cv_lib_socket=no \
       ac_cv_lib_socket_main=no \
               configure ...

Note that this is just an example. Make sure to look at your config.cache (or equivalent) file after configuration, and inspect it for any suspicious ac_cv_lib... entries that match one of the libraries mentioned above and force them to no (or equivalent).

Makefiles

Some open source programs assume GNU make in their Makefiles. You should probably use GNU make on IRIX too. Compatibility is good. With GNU make supporting parallel makes there's really no reason to use any IRIX specific make like smake, pmake, or make.

If you don't have GNU make for IRIX you can download it from http://freeware.sgi.com/ and not worry about Makefile portability anymore.

ranlib

This is a historical BSD thing that should have been done transparently by the linker. You don't need to run ranlib in IRIX. If your Makefile calls ranlib either delete this or define it to a no-op.

gmake RANLIB=: ...

Probably best to delete the dependency in the makefile, otherwise make it a command that doesn't do much like echo...

gmake RANLIB=echo

install

The Berkeley 'install' is incompatible with the SYSV version. Either upgrade to IRIX 6.5 (where the IRIX install has transparent BSD compatibility) or define:

gmake INSTALL=bsdinst ...

BSD

BSD programs that assume a BSD environment should compile on IRIX without change (at least in 95% of cases) by forcing BSD compatibility via CFLAGS, e.g:

gmake CFLAGS="-D_BSD_COMPAT ..." If you don't want full BSD compatibility, consider using one or more of:

	-D_BSD_TYPES
	-D_BSD_TIME
	-D_BSD_SIGNALS

Important: if your software is more "properly" written and uses POSIX signals (i.e. sigaction instead of signal) then you must not compile with -D_BSD_SIGNALS. Mixing signal models may cause unpredictable problems.

System types

Some programs assume system types, in particular 'off_t', are 32 bit (i.e. that files don't exceed 4GB in size) These programs are making bad assumptions, but this problem can be overcome by compiling in the o32 (cc -32) ABI:

gmake CC="cc -32 ..."

varargs

Some programs do not comply with the ANSI varargs syntax and conventions (i.e. include <stdarg.h> and use ellipsis in the argument list) Again, if those don't work they may start working by compiling using the o32 ABI:

gmake CC="cc -32 ..."

Catching other problems

The SGI cc is verbose and pedantic. The problem is that when you get way too many warnings you start ignoring the real ones.

To make the SGI compiler more like gcc in terms of warnings you may use something like:

       NOWARN = -woff 1009,1014,1110,1116,1185,1188,1204,1230,1233 \
                -Wl,-woff,85,-woff,84
       $(CC) $(NOWARN) ...

In your Makefiles SGI cc While the SGI cc may look too pedantic, it can catch a lot of real source code bugs. Consider compiling with:

CC="cc -fullwarn ..." and really clean your source of type mismatches.

Multiple other problems (too many to list here) Over the years IRIX got thousands of bug fixes. As expected, problems on IRIX 4.0.x are much more numerous than problems on IRIX 6.5. If you can upgrade, please do. Life is way easier with IRIX 6.5.

Build vs. target env

Virtually all open source packages assume that the building environment is the same as the target environment. In fact every Makefile with a 'make install' that directly installs into system directories probably makes this assumption. IRIX supports a much more elegant model of 'inst'able packages that can be built anywhere and installed anywhere else.

It would be nice if there was a UNIX-wide standard for this. Red Hat RPM and other Linux installers are getting there, which is great.

We usually build open source software with an IRIX 6.5 ROOT (i.e. get include files and libraries from a backward compatible 6.5 mounted directory). Assuming this directory is called /6.5_root this can be done by:

cc -nostdinc -I. -I/6.5_root/usr/include ... (compiling) cc -nostdlib -L/6.5_root/usr/lib32 ... (linking) The packaging itself is an art form. At SGI we use a specialized 'install' perl script to intercept calls from 'make install'. This install adds the appropriate lines to the 'idb' file instead of actually installing files. Later, this idb file is used by 'gendist' to create the packages. Unfortunately, far too many open source packages call mv, cp, tar, etc. to install, so they bypass this mechanism. We have considered but not yet implemented other solutions, such as trapping system calls or running in a chroot directory. If you find (or implement!) a better solution please let us know.

gcc vs. cc

Code that runs fine when compiled with SGI cc and doesn't run when compiled with gcc might be calling functions compiled with MIPSpro C that get passed or return structs that are smaller than 16 bytes but not 8 bytes long. gcc and SGI cc are incompatible in the way they pass these structs so compiling with gcc and linking with a shared library that was compiled with the SGI cc) can cause these problems. There are very few such library functions, but inet_ntoa, inet_lnaof, inet_netof, inet_makeaddr and semctl are all examples. Work-arounds for these particular routines have been built into libgcc.a, but that is not a general fix. If you find more instances in IRIX libraries please report them. Often a small wrapper procedure that realigns the problematic arguments will avoid the problem.

portable types

Occasionally code that works on other platforms will compile fine on IRIX, but will misbehave when run. These problems can be difficult to track down, but one thing to check for is assumptions about whether char is signed or unsigned. IRIX compilers default to unsigned -- if it matters your code should be explicit!

Setting up parallel debugging sessions and stepping through the working and non-working code simultaneously to find where they diverge is often helpful.

setenv() missing in IRIX

There is putenv()...

/* setenv is missing on win32, solaris, IRIX and HPUX */
static void setenv(const char *name, const char *val, int _xx)
{
    int len  = strlen(name) + strlen(val) + 2;
    char *env = malloc(len);

    if (env != NULL) 
    {
      strcpy(env, name);
      strcat(env, "=");
      strcat(env, val);
      putenv(env);

      /* free( env );  */ 
    }

}

When porting, put this code inline with code that is looking for a setenv() function.

getopt_long() missing in IRIX

google around for the example code to implement this.... relevant forum discussion here: http://forums.nekochan.net/viewtopic.php?f=15&t=16726751

Getting rid of GCC-isms

GCC, The GNU Compiler Collection does an excellent job of providing compilers for an extremely wide variety of platforms and multitude languages. In trying to be all things in all cases it falls down in most cases. Most commercial vendor specific compilers are designed for one and only one language and generate code for only one machine architecture. MIPS Pro produces much better optimized code for the MIPS architecture [1]. GCC has had some non standard language features added to it ("GCC-isms"). Porting Open source projects developed solely on Linux often requires removal of GCC-isms. The MIPS Pro Compiler is far more strict in making sure the input code adheres to the official standard than GCC and a lot of other compilers.

Here is a resource that documents equivalent features under a range of compilers, including GCC and MIPSpro https://www.cs.indiana.edu/~chiuk/misc_tech_notes/index.html

Predefined macros on different compilers:

+ http://sourceforge.net/apps/mediawiki/predef/index.php?title=Compilers#MIPSpro
+ http://wiki.apache.org/stdcxx/Compilers#SGI_MIPSpro

Variable attributes

__attribute__(( XXX ));

__attribute__((something)) is a GCC extension, that has to go or #defined away

If you want to make sure that struct is packed, have a look at the MIPSpro pragma guide.

GCC Variable Attributes

offsetof(..)

There seems to be problems with offsetof(..) in IRIX.. There are questions in Postgres forums and elsewhere about offsetof() in IRIX. To get swi-prolog to build put a #undef offsetof in the code just before where it is defined.

Zero length and variable length arrays

int xyz[0];

Arrays of zero length are a GNU extension: http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Zero-Length.html

Try using a pointer:

int *xyz;

Variable length arrays require a code rewrite.

General Retardedness

puts( "abc" "def" );

gcc actually accepts this.. It concatenates two strings. Its not actual C syntax but what the hey. GCC will accept any old garbage.

Various ways around this.

puts( "abcdef" );

or

char buff[ 255 ];
bzero( buff, 0, 255);
strcat( buff, "abc" );
strcat( buff, "def" );

Label Value Operator, Computed Goto Statement and Abysmal Programming

Goto are not considered good programming technique (See Dijstraka paper published around 1967, "Gotos considered harmful") . Computed gotos have to be even more problematic.

    void *lbl = &&label;

    goto *lbl;
    printf("skip me\n");
 label:
    printf("label\n");

See also: IBM description

Solution: code rewrite.

GNU CC NOTES

     The following table lists some of the GNU compiler command line
     options and the closest corresponding SGI C++ compiler command line
     options.  Note that the correspondence is close but may not be exact
     and different versions of either compiler may have slight variations
     in the meaning of arguments to the options.

     SGI                   GNU

     o32, 32               mabi=32

     n32                   mabi=n32

     64                    mabi=64

     ansiW                 pedantic

     TARG                  b

     The following list summarizes some of the major differences between
     the GNU cc compiler and the MIPSpro C compiler.  The wording gcc
     allows or g++ allows in the following paragraphs indicates that the
     GNU compiler is providing more flexible constructs beyond what is
     allowed in the standard.  The MIPSpro compilers adhere more closely to
     standards requirements.

     * The gcc compiler allows variadic macros; the MIPSpro 7.4 compilers
       support these macros in c99 mode.  If you have code that uses
       ellipses (...) as part of a macro definition and you are not
       compiling with c99, you will need to rewrite the macro. Two possible
       approaches are to replace the macro with a new variadic function, or
       to create a family of macros, each taking different (fixed) numbers
       of arguments.

     * When processing modules on the command line, the IRIX loader (ld)
       requires that at least one reference to an unresolved symbol appear
       before inclusion of the library that resolves that reference. gcc
       uses a multi-pass algorithm to resolve undefined symbols, and so
       lets you specify libraries in an arbitrary order.

     * The gcc compiler does not correctly pass/return structures that are
       smaller than 16 bytes and which are not 8 bytes.  gcc is consistent
       with itself, but not consistent with the MIPSpro C compiler, so the
       only failures that can happen are when mixing code compiled with the
       two compilers.  Recent releases of libgcc have special wrapper
       procedures that contain the known instances of these functions in
       libc. Note that this may not be true for all ABIs; this may vary
       between gcc versions. Consult the release notes with the product for
       details.

     * The ANSI specification leaves the determination of valid line
       terminators to the compiler implementors.  MIPSpro allows '^J',
       while gcc allows both '^J' and '^M'.  The to_unix command will
       convert files containing DOS-style '^M' line terminators to the UNIX
       standard '^J' form.

     * The MIPSpro compilers use 16 byte long doubles, while gcc uses 8
       bytes.

     * gcc allows the non-standard __FUNCTION__ and __PRETTY_FUNCTION__
       pseudo-macros.  These are not true macros, so you must use _GNUC__
       to test for them. As of IRIX 6.5.18, the c99 func macro is
       available, which expands to a function name.

     * By default gcc allows C++ style double slash (//) comments in C
       code.  To obtain this behavior with the MIPSpro C compilers you must
       specify the -Xcpluscomm command line option or use c99, which
       defines a double slash (//) to be a comment.

     * The gcc compiler treats extern inline functions as being extern,
       while the MIPSpro compilers treat them as inline.  To get equivalent
       behavior, remove the inline keyword.

     * The gcc compiler is more lax about accepting non-static
       initializers, extra parentheses, and the use of non-compile-time
       constants.  The MIPSpro compilers adhere more closely to the ANSI
       standard.

     * The gcc compiler allows pointer arithmetic on void pointers. For
       example, gcc allows

          void *foo;
          foo += 5;

       When using MIPSpro, you must cast the pointer to a type with a size:

          void *foo;
          foo = (char*)foo + 5;

     * gcc allows the use of casts as lvalues. For example:

          void *foo;
          (char*)foo += 5;

       When using MIPSpro compilers you cannot assign to casts:

          void *foo;
          foo = (char*)foo + 5;

     * gcc allows block expressions, such as ({x++});.  When using MIPspro
       compilers, remove the extra parentheses.

     The following list summarizes the differences between the g++ compiler
     and the MIPSpro C++ compiler:

     * There are name mangling and run-time differences

     * g++ allows non-constant constants.  For example, the following is
       allowed with g++:

          char tmp[argc];

       Use the following with the MIPSpro C++ compiler:

          char *tmp=alloca(argc);

     * g++ allows redefinition of default arguments

     #ifdef _GNUC_ tests if gcc is being used; if you wish to use
     compiler-specific extensions, you should write conditional code for it.

Mixing MIPS Pro and GCC

ShadeOfBlue in forum topic... http://forums.nekochan.net/viewtopic.php?f=15&t=16727728#p7360473

• MIPSpro C program + GCC C libraries = ok
• MIPSpro C++ program + GCC C libraries = ok
• GCC C++ program + MIPSpro C libraries = ok
• MIPSPro C++ program + GCC C++ libraries = not ok
• GCC C++ program + MIPSpro C++ libraries = not ok

This is because MIPSpro and GCC use different function naming for C++ code, but the naming of C functions is the same.

The optimizer in GCC 4.7.1 is at least as good as the one in MIPSpro (and actually substantially better on some numerical code I tried it on, YMMV), so there's really nothing bad about compiling a C library with GCC anymore

There were incompatibilities with passing structures smaller than 16 bytes, but that was in GCC 3.3, which is ancient. I haven't experienced this problem with 4.7.1.

References

• 1. quad-precision benchmark (Scroll down to where it says 30 times slower)

Quirks

Patches

• SG0003659: MIPSpro 7.3 C++ Support Fix and Continue in Workshop (included on MIPSpro PDS 7.3 CD, replaces /usr/lib32/cmplrs/fecc)
• SG0005329: 7.4 Compiler Header Files for Unix98, C99 and ANSI C++ namespace std #2 (included with MIPSpro 7.4.4?)
• SG0005401: Modules MIPSpro drive update 2 (included with MIPSpro 7.4.4?)
• IRIX Patch 7188: MIPSpro 7.4.4m C/C++ Front-end #1 02-Oct-2007 Requires Support Program to Access

Discontinued but reborn as PathScale

As discussed in this nekochan forum topic .

See Also

• TechPubs link

• MIPSpro 64-Bit Porting and Transition Guide (document number: 007-2391-006)

• MIPSpro Assembly Language Programmer's Guide (document number: 007-2418-006)

• MIPSpro Auto-Parallelizing Option Programmer's Guide (document number: 007-3572-002)

• MIPSpro Compiler Letter (document number: 007-3639-003)

• MIPSpro C/C++ Pragmas (document number: 007-3587-005)

• MIPSpro Fortran 77 Language Reference Manual (document number: 007-2362-005)

• MIPSpro Fortran 77 Programmer's Guide (document number: 007-2361-009)

• MIPSpro Fortran 90 Commands and Directives Reference Manual (document number: 007-3696-005)

• MIPSpro Fortran 90 Programmer's I/O Guide (document number: 007-3695-006)

• MIPSpro Fortran Language Reference Manual, Volume 1 (document number: 007-3692-006)

• MIPSpro Fortran Language Reference Manual, Volume 2 (document number: 007-3693-007)

• MIPSpro Fortran Language Reference Manual, Volume 3 (document number: 007-3694-006)

• MIPSpro N32 ABI Handbook (document number: 007-2816-005)

• MIPSpro N32/64 Compiling and Performance Tuning Guide (document number: 007-2360-010)

PathScale

• Path scale nekochan forum topic

• Pathscale announcement

• Path scale on github

• PathScale debugger on github

• PathScale corporate site

Application Programming Interface