|
|
|
|
| Xserve Cluster Setup |
|
|
|
SeisUP is supported on a number of Unix platforms including 64-bit IRIX, Solaris, HP-UX, and 32-bit and 64-bit Linux. We also support a number of hardware architectures the cover the range of 64-bit and 32-bit computing, and big endian and little endian byte orders. Because of the wide hardware and operating support we did not expect any major difficulties in porting SeisUP to Mac OS X running on the PowerPC G5. Indeed the modifications needed to build SeisUP for Mac OS X were few. This page provides some notes about the challenges faced in the port.
Compiling Fortran
A great deal of the source code in SeisUP is written in Fortran. Indeed, much of the high-performance code is written in Fortran, so we needed a high-performance compiler to build our software. We choose IBM's XL Fortran 8.1 compiler for Mac OS X. Porting our existing Fortran code to compile under XLF was a simple matter of choosing the right flags. The flags we used:
|
|
|
Option
|
Description
|
|
-F:xlf_r
|
Configure for building threaded programs
|
|
-qfixed=132
|
Increase max line length to 132 columns
|
|
-qsuffix=cpp=f
|
Preprocess .f files with the cpp
|
|
-qextname
|
Append an underscore to global function names
|
|
-qarch=auto
|
|
|
-qtune=auto
|
|
|
-qcache=auto
|
|
|
-qmaxmem=-1
|
|
|
|
|
The three compiler options -qfixed=132, -qsuffix=cpp=f, -qextname were the options needed for compatability with our other fortran compilers. The last four options lists above are optimization settings, and -F:xlf_r simply lets us build a program that uses threading.
No POSIX Semaphores?
One problem we came across when porting was that Mac OS X 10.3 has no support for POSIX semaphores, which we use for other our Unix platforms. To solve this problem we had to use the Mac OS X-only semaphore routines found in Carbon's Multiprocessing API. Fortunately SeisUP has wrapper functions for many OS-level functions such as thread synchronization with semaphores, so we could simply use an #if defined(__APPLE__) preprocessor macro to incorporate the calls to the MP APIs to our wrapper functions. Hopefully Mac OS X 10.4 due out in mid-2005 will provide support for POSIX semaphores, thus allowing us to simplify our code in that respect.
The following table shows the mappings between the POSIX semaphore APIs and Carbon's Multiprocessing services API.
|
|
|
POSIX
|
Carbon Multiprocessing
|
|
sem_init()
|
MPCreateSemaphore()
|
|
sem_wait()
|
MPWaitOnSemaphore( *sem, kDurationForever )
|
|
sem_trywait()
|
MPWaitOnSemaphore( *sem, kDurationImmediate )
|
|
sem_post()
|
MPSignalSemaphore()
|
|
sem_destroy()
|
MPDeleteSemaphore()
|
|
|
|
sigset() vs. signal()
Mac OS X does not provide the sigset() function for installing signal handlers. While the ideal situation from a portability standpoint would be to use the POSIX standard sigaction(), a few programs use sigset() to install signal handlers. To get this code to build on Mac OS X we defined a macro that mapped sigset() to the signal() function. The macro was nothing more than:
|
|
|
#ifdef __APPLE__
#ifndef sigset
#define sigset(A,B) signal((A),(B))
#endif /* sigset */
#endif /* __APPLE__ */
|
|
|
|
|
|
At some point in the future we would like to convert our code that uses sigset() to use sigaction() instead.
|
|
| Next -> Downloads |
|
|
|
|
|
|
|
|
|