Environment   

<<< Interface Changes Chapters

Contents

[back to top]

8.1 Introduction

This chapter contains information on the platform specific operating systems and compiler options used to build the Parasolid library.

Floating Point Underflow Traps

 

Warning: Because Parasolid relies on 'quiet underflow of denormals to zero' it is important that you do not, should the option be available, enable floating point underflow traps.

[back to top]

8.2 Intel NT

Parasolid was compiled, linked and tested on Windows NT version 4.0 with Service Pack 5.

It will run under Windows NT version 4.0 or Windows 2000 on an Intel 80486, Pentium, Pentium Pro, Pentium II, Pentium III, or AMD Athlon processor. At least 32 Mbytes of RAM are recommended.

Windows 95 and 98 are not officially supported, but Parasolid-based products have been successfully created for them.

The C compiler used was Microsoft Visual C++ version 6.0 with Service Pack 4, with the following options:

/MD /DWIN32 /Gs /QIfdiv- /O2 /Oy- /G6 /DNDEBUG

where:

 

/O2

Optimize for speed

 
/Gs

Disable stack checking code

 
/MD

Link with MSVCRT.LIB

 
/Oy-

Use a stack frame

 
/G6

Optimize for Pentium Pro/Pentium II/Pentium III. Parasolid will still run on a Pentium or 80486.

 
/QIfdiv

Prevents checking of parameters to floating point calculations for values that trigger the 'Pentium bug'.

Early versions of the Pentium processor had a fault which produced incorrect results on some floating point calculations. Modern Pentiums and all Pentium Pros/II/IIIs are free of this error. Checking for the critical parameter values allows code to run on the obsolete processors, but reduces Parasolid performance significantly.

To improve performance, Parasolid for Intel has not been compiled with the /Op option (Improve floating-point consistency). Applications that use 64-bit precision (i.e. 80-bit real numbers) may therefore suffer from inconsistent results; therefore we recommend the use of 53-bit precision (64-bit real numbers).

Also for performance reasons, Parasolid uses Visual C++'s default structure packing (equivalent to the /Zp8 compiler option). Do not use the /Zp n compiler option with any value of n except 8; if wrongly-packed structures are passed to Parasolid, it will crash.

 

Note: See also Section 8.9, "Linking NT run-time libraries".

The Pentium 4 version of Parasolid was built with the Intel C/C++ compiler, version 5.0.1, using the following options: 

/MD /DWIN32 /DNDEBUG /Gs /QIfdiv- /O2 /Oy- /G7 /QxW /Qfp_port-

The options that differ from the Microsoft-compiled version are:

 

Option

Description

 
/G7

Optimize for the Pentium 4.

 
/QxW

Compile for the Pentium 4 and compatible NetBurst? processors. The resulting code will not run on older Intel or AMD processors. 

/Qfp_port-

Modify handling of conversions between double and float. Parasolid does not perform these conversions, so dispensing with the default handling has a small performance benefit. You should not use this option in code which actually does such conversions.

Running this version of Parasolid requires the Intel math library DLL libmmd.dll .

Attempting to run this version of Parasolid on a Pentium III, AMD Athlon, or other processor that does not support the Pentium 4 instruction set will produce an Illegal Instruction exception. The Parasolid DLL has additional version information, allowing you to check that you are using the Pentium 4 version via Windows Explorer (right-click the DLL file and choose Properties from the shortcut menu).

You may find that your application requires more stack space when using the Parasolid DLL. You can use the /stack parameter with the Microsoft linker to increase the stack size from the default. Using a larger stack space does not affect performance on P3 or earlier processors.

 

Note: The FCS release of the Pentium 4 version of Parasolid was compiled using a beta-quality compiler, and is therefore a beta release.

[back to top]

8.3 Linux

Parasolid was compiled, linked and tested on Red Hat Linux 6.0.

Currently, there is no shared library under Linux: only an archive library is available.

The C compiler used was gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release), with the following options:

-O -fPIC

where:

 

-O

optimization on

 
-fPIC

generate position-independent code

[back to top]

8.4 HPPA HPUX

Parasolid was made using the operating system HP-UX 11.0 and C compiler A.11.01. The compiler options used were:

+O3 +Olibcalls +Onolimit +Onomoveflops +Onoinitcheck +DA1.1 +DS2.0a +Oentrysched +Z -Ae +w2 +ESlit

where:

 

+O<option>

optimization options

 
+DA1.1

use PA_RISC 1.1 architecture instruction set

 
+DS2.0a

instruction scheduling optimized for PA2.0 architecture

 
+Z

produce position independent object code

 
+ESlit

place string literals in read-only memory

 
-Ae

Extended ANSI mode

 

Note: On HP: we recommend that the -z parameter is used when linking, so that null pointer accesses are detected.

The 64-bit version of Parasolid is built with the same options, substituting +DD64 - which tells the compiler to produce 64-bit code - for +DA1.1 +DS2.0a .

To use the 64-bit version of Parasolid, all parts of your application code must be compiled for 64-bit.

[back to top]

8.5 SPARC Solaris

Parasolid is supplied for both 32-bit and 64-bit versions of SPARC Solaris. Parasolid was made using the operating system Solaris 5.7. The C compiler used was Sun Workshop C 5.0 with the following options:

-xtarget=ultra -xdepend -x04 -xlibmil -K PIC -xstrconst
-D_POSIX_SOURCE -dalign -mt -Xa

For the 64-bit version, the following option is also used:

-xarch=v9

 

Note: The -xarch option must come after the -xtarget option.

The options used have the following meaning:

 

-xdepend

do dependency analysis and restructuring of loops

 
-x04

optimization level 4

 
-xlibmil

inline some library routines for performance

 
-K PIC

generate position-independent code

 
-xstrconst

put string literals in read-only memory

 
-dalign

assume double data aligned appropriately for double word load/store instructions

 
-mt

required for multi-threading code

 
-Xa

ANSI C plus K&R C compatibility extensions

 
-xarch

Setting this to v9 builds a 64-bit version, rather than a 32-bit verson.

The xtarget=ultra option generates code optimized for SPARC V8 machines and uses the timing properties of the UltraSPARC chip. This may mean that code will run slightly slower on the older SuperSPARC architecture. The Parasolid libraries and KID, supplied with this release, were generated with this option. These files will also run on pre- SPARC V8 machines, such as SPARC2, but with a significant degradation in performance.

The 64-bit version does not run on pre-UltraSPARC machines, and requires the 64-bit Solaris kernel, which only runs as the default on UltraSPARC II and later machines.

 

Note: To use this Parasolid library, all parts of your application code must be compiled for 64-bit.

[back to top]

8.6 AXP OSF

Parasolid was made using the operating system OSF1 4.0 (the original name of Tru64). The C compiler used was the Compaq C compiler V5.6-071 with the options:

-migrate -O2 -G 0 -FASTMATH

where:

 

-migrate

set default compiler options as for pre-v4.0 compiler

 
-O2

optimization level 2

 
-FASTMATH

use faster versions of some math library routines

[back to top]

8.7 RS6000 AIX

Parasolid was made on an IBM RS/6000 workstation under the AIX 4.3 operating system. The AIX compiler version 3.6.6.0 options used were:

-O -qlanglvl=ansi -qcheck=all:nobounds
-D_POSIX_SOURCE -qro -qtune=604

where:

 

-O

optimization on

 
-qlanglvl=ansi

ansi mode (not IBM RT compatibility mode)

 
-qcheck

trap run-time exceptions except array bound checking

 
-D_POSIX_SOURCE

use Posix standard headers

 
-qro

put string literals in read only memory

 
-qtune=604

optimize for Power PC 604 processor

The shared libraries provided are .so files, rather than old-style .a files. You may need to add the -brtl option to your link command line, to tell the linker to look for .so libraries.

[back to top]

8.8 R4000 IRIX

Parasolid was compiled on the IRIX 6.5 operating system, using version 721 of the IRIX C compiler. The compiler options used were:

-n32 -mips3 -O2 -KPIC -G 0 -LANG:vla=off

where:

 

-n32

use newer 32 bit ABI (Application Binary Interface)

 
-mips3

use MIPS R4000 instruction set

 
-KPIC

generate position-independent code

 
-O2

optimization level 2

If you have an earlier version of the IRIX C compiler, we recommend that you upgrade to version 720 or later for work with n32 Parasolid.

 

Note: All parts of a program must be compiled with the same ABI, i.e. the application code must also be compiled with -n32 to use this Parasolid library.

Parasolid is capable of using large amounts of virtual memory. This means that the default configuration normally supplied with a Silicon Graphics workstation, (which allows any process to take the whole of this allocated virtual memory), is dangerous. Therefore, use the systune utility to examine and adjust the system parameters rlimit_data_cur and rlimit_stack_cur , and possibly rlimit_data_max and rlimit_stack_max , to ensure that any given process cannot allocate all available virtual memory.

[back to top]

8.9 Linking NT run-time libraries

Microsoft Visual C++ provides several different versions of the C run-time library. Unfortunately, the library to be used has to be selected before any code is compiled, which restricts the freedom of library manufacturers and application developers somewhat.

Parasolid is compiled with the /MD option, to use the dynamically-loaded version of the C runtime library. It must be linked with the interface library msvcrt.lib , and the run-time library DLL, msvcrt.dll must be available at run time.

The recommended method of building an NT application with Parasolid is to compile the application code with /MD , and to link it with either pskernel.lib or pscommunicator.lib (depending on whether you want the full Parasolid DLL, or the cut-down Parasolid Communicator DLL) and msvcrt.lib . This will use the DLL versions of Parasolid and the C run-time library.

You can link Parasolid statically to your application if you prefer: compile with /MD and link with pskernel_archive.lib and msvcrt.lib . This produces a single very large executable (Parasolid is more than 10Mb), which will require msvcrt.dll to be available.

If your application absolutely has to be statically linked to the C run-time library, then you could compile it with /ML and link with either pskernel.lib or pscommunicator.lib (depending on whether you want the full Parasolid DLL, or the cut-down Parasolid Communicator DLL) and libc.lib . Your application will use the appropriate DLL version of Parasolid and the statically linked version of the C library. msvcrt.dll must still be available at run-time, since the Parasolid DLL will require it. While this method has worked in tests, we do not recommend it, since it involves having two copies of the C run-time library in use simultaneously. This wastes memory and could confuse the library code. So far, Parasolid's frustrum architecture seems to have allowed this problem to be evaded, but it is very poor practice to risk it.

It is not possible to link Parasolid statically to a LIBC-based application; this would require all of Parasolid to be compiled with /ML . Overriding the library to be used by Parasolid with the /NODEFAULTLIBRARY link parameter will not work; some of the functions in the C run-time library have different names in the static and dynamic versions. Linking with only LIBC produces missing symbols, while linking with both produces duplicate symbols.

It is inadvisable to statically link an application compiled with /MDd to Parasolid. This option tells the linker to use the debug version of the C run-time library. This is not required for normal debug compilations; it is only needed for source-level debugging of the run-time library itself. Under these circumstances, the link will work, but running the program will produce assertion failures and access violations. It seems to be necessary to compile an entire program with /MDd , if any of it is compiled that way. Statically linking debug-compiled code without /MDd to Parasolid works without problems; using /MDd code with a DLL Parasolid also works.

 

[back to top]

<<< Interface Changes Chapters