Usenet 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / misc / volume20 / cfortran / part01 / cfortran.doc < prev

Wrap

Text File | 1991-06-26 | 26.9 KB | 647 lines

/* cfortran.doc */ /* Burkhard Burow, burow@vxdesy.desy.de, U. of Toronto, 1991. */ CFORTRAN 1.2 for UNIX Machines and for VAX VMS History: - 1.0 for VAX VMS using C 3.1 and FORTRAN 5.4. Oct. '90. - 1.0 for Silicon Graphics using Mips Computer System 2.0 f77 and cc. Feb. '91. [Port of C calls FORTRAN half only.] - 1.1 for Mips Computer System 2.0 f77 and cc. Mar. '91. [Runs on at least: Silicon Graphics IRIX 3.3.1 DECstations with Ultrix V4.1] - 1.2 Internals are simpler, smaller, faster, stronger. May '91. Mips version works on IBM RS/6000, this is now called the unix version. - 1.3 UNIX and VAX VMS versions are merged into a single cfortran.h. June '91. C can manipulate (arrays of) strings in FORTRAN common blocks. I Introduction -------------- CFORTRAN is an easy-to-use powerful bridge between C and FORTRAN. It provides a completely transparent, machine independant, interface between C and FORTRAN routines (= subroutines and/or functions). The complete CFORTRAN package consists of 4 files. They are this introduction, cfortran.doc, the engine in cfortran.h, examples in cfortest.c and cfortex.f/or. [cfortex.for under VMS, cfortex.f under UNIX.] To run the example do the following: RS/6000> cc -Drs6000 -c cfortest.c && xlf -o cfortest cfortest.o cfortex.f RS/6000> cfortest or MIPS> cc -o cfortest cfortest.c cfortex.f -lI77 -lU77 -lF77 MIPS> cfortest or VMS> define lnk$library sys$library:vaxcrtl VMS> cc cfortest.c VMS> fortran cfortex.for VMS> link/exec=cfortest cfortest,cfortex VMS> run cfortest By changing the SELECTion ifdef of cfortest.c and recompiling you can try out a dozen different few-line examples. The benefits of using CFORTRAN include: 1. Machine independant applications. 2. Identical (within syntax) calls across languages, e.g. C FORTRAN CALL HBOOK1(1,'pT spectrum of pi+',100,0.,5.,0.) /* C*/ HBOOK1(1,"pT spectrum of pi+",100,0.,5.,0.); 3. Each routine need ony be set up once in its lifetime. e.g. /* Setting up a FORTRAN routine to be called by C. Note that ID,...,VMX are merely the names of arguments. These tags must be unique w.r.t. each other but are arbitrary. */ PROTOCCALLSFSUB6(hbook1,INT,STRING,INT,FLOAT,FLOAT,FLOAT) #define HBOOK1(ID,CHTITLE,NX,XMI,XMA,VMX) \ CCALLSFSUB6(hbook1,INT,STRING,INT,FLOAT,FLOAT,FLOAT, \ ID,CHTITLE,NX,XMI,XMA,VMX) 4. Routines, and the code calling them, can be coded naturally in the language of choice. C routines may be coded with the natural assumption that they'll only be called by C code. CFORTRAN does all the required work for FORTRAN code to call C routines. Similarly CFORTRAN does all the work required for C to call FORTRAN routines. Therefore: - C programmers need not imbed FORTRAN argument passing mechanisms into their code. - FORTRAN code need not be converted into C code. i.e. The honed and timehonored FORTRAN routines are called by C, not some new translation from FORTRAN into C. 5. CFORTRAN is contained within a single C include file, cfortran.h, weighing in at ~1100 lines. cfortran.h currently supports VAX VMS, the IBM RS/6000 and machines using the MIPS RISC compilers. It should be portable to many other platforms. 6. STRINGS and VECTORS of STRINGS along with the usual simple arguments to routines are supported as are functions returning STRINGS or numbers. 7. CFORTRAN requires each routine to be exported to be explicitly set up. While this need usually only be done once in a header file it would be best if applications were required to do no work at all in order to cross languages. CFORTRAN's simple syntax could be a convinient back-end for a program which would export FORTRAN or C routines directly from the source code. ----- Example 1 - CFORTRAN has been used to make the C header file hbook.h, which then gives any C programmer, e.g. example.c, full and completely transparent access to CERN's HBOOK library of routines. Each HBOOK routine required about 3 lines of simple code in hbook.h. The example also demonstrates how FORTRAN common blocks are defined and used. /* hbook.h */ #include "cfortran.h" : PROTOCCALLSFSUB6(hbook1,INT,STRING,INT,FLOAT,FLOAT,FLOAT) #define HBOOK1(ID,CHTITLE,NX,XMI,XMA,VMX) \ CCALLSFSUB6(hbook1,INT,STRING,INT,FLOAT,FLOAT,FLOAT, \ ID,CHTITLE,NX,XMI,XMA,VMX) : /* end hbook.h */ /* example.c */ #include "hbook.h" : typedef struct { int lines; int status[SIZE]; float p[SIZE]; /* momentum */ } FAKE_DEF; #define FAKE COMMON_BLOCK(fake) extern FAKE_DEF FAKE; : main () { : HBOOK1(1,"pT spectrum of pi+",100,0.,5.,0.); /* c.f. the call in FORTRAN: CALL HBOOK1(1,'pT spectrum of pi+',100,0.,5.,0.) */ : FAKE.p[7]=1.0; : } N.B. i) The routine is language independant. ii) hbook.h is machine independant. iii) Applications using CFORTRAN'd routines are machine independant. ----- Example 2 - Many VMS System calls are most easily called from FORTRAN, but CFORTRAN now gives you that ease in C. #include "cfortran.h" PROTOCCALLSFSUB3(lib$spawn, STRING,STRING,STRING) #define LIB$SPAWN(command,input_file,output_file) \ CCALLSFSUB3(lib$spawn, STRING,STRING,STRING, \ command,input_file,output_file) main () { LIB$SPAWN("set term/width=132","",""); } Obviously the 2 CFORTRAN lines above should be put into a header file along with the description of the other system calls, but as this example shows it's not much hassle to set up CFORTRAN for even a single call. ----- Example 3 - CFORTRAN and the source cstring.c create the cstring.obj library which gives FORTRAN access to all the functions in C's system library described by the system's C header file string.h. C EXAMPLE.FOR PROGRAM EXAMPLE DIMENSION I(20), J(30) : CMEMCPY(I,J,7) : END /* cstring.c */ #include <string.h> #include "cfortran.h" #undef fcallsc #define fcallsc(NAME) C/**/NAME : FCALLSCSUB3(memcpy, PVOID, PVOID, INT) : N.B. Other than a possible redefinition of fcallsc, cstring.c is machine independant. Unfortunately the names of C routines called by FORTRAN may differ from the name of the original C routine, e.g. cmemcpy vs. the original memcpy. This need never be the case if one has: i) the original C source code for the routine. OR ii)a FORTRAN compiler, e.g. f77, which 'renames' routines. OR iii) a case sensitive linker. If all the above fail, CFORTRAN, through fcallsc, makes it easy to ensure that names of C routines called by FORTRAN are modified from the original only when absolutely neccessary, and if they are modified, that it is done consistently for any given FORTRAN compiler. [More details below in Section VI.] ----- II Using CFORTRAN ----------------- The user is asked to look at the source files CFORTEX.C and CFORTEX.FOR for clarification by example. Note: CFORTRAN (ab)uses the null comment, /**/, kludge for the ANSI C preprocessor concatenation, ##, operator. In MIPS C this kludge is sensitive to blanks prepending arguments to macros. THEREFORE IN THE FOLLOWING MACRO DEFINITIONS YOU MAY NOT PREPEND argtype_i NOR routine_type WITH BLANK, ' ', CHARACTERS. Note: On the RS/6000, currently the only machine supporting ##, a global replace of /**/ by ## makes cfortran.h ANSI compliant. Note: On the RS/6000, if you use "xlf -qextname ...", which appends an underscore, '_', to all FORTRAN external references, then you must use, "cc -Dextname ..." so that cfortran.h also generates these underscores. Note: The calls to FORTRAN subroutines are expanded to code inside {....}. This has some undesirable side effects, e.g. if (a==b) A_FORTRAN_SUBROUTINE(1,"Hello") /* <-- No ';' allowed here. */ else A_FORTRAN_SUBROUTINE(1,"Hello") Unfortunately there is no fix in sight. (gcc extensions to C would offer a fix.) Note: At the moment only vectors of fixed length strings are supported in C. I know how and hope to support vectors of pointers to strings in the near future. Note: For those who wish to use CFORTRAN in large applications. This release is intended to make it easy to get applications up and running. This implies that applications are not as efficient as they could be: - The current mechanism is inefficient if a single header file is used to describe a large library of FORTRAN functions. Code for a static wrapper fn. is generated in each piece of C source code for each FORTRAN function specified with the CCALLSFFUNn statement, irrespective of whether or not the function is ever called. I have several ideas for how code for these wrappers could be created, compiled and linked only once instead of once for each piece of source code. - Code for several static utility routines internal to CFORTRAN is placed into any source code which #include's cfortran.h. These routines should be in a library. - The FORTRAN calls C half of the package could be split from the C calls FORTRAN half. i) Calling FORTRAN routines from C: -------------------------------- FORTRAN routines are prototyped by the following two macros. PROTOCCALLSFSUBn(routine_name, argtype_1, ..., argtype_n) or PROTOCCALLSFFUNn(routine_type, routine_name, argtype_1, ..., argtype_n) and are defined respectively by the following two macro usages. #define ROUTINE_NAME(argname_1,...,argname_n) \ CCALLSFSUBn(routine_name, argtype_1,...,argtype_n, \ argname_1,...,argname_n) #define ROUTINE_NAME(argname_1,...,argname_n) \ CCALLSFFUNn(routine_name, argtype_1,...,argtype_n, \ argname_1,...,argname_n) Where: 'n' = 0->7 (easily expanded in CFORTRAN.H to >7) stands for the number of arguments to the routine. ROUTINE_NAME = the C name of the routine (IN UPPERCASE LETTERS). routine_name = the FORTRAN name of the routine (IN lowercase LETTERS). routine_type = the type of argument returned by FORTRAN functions. = DOUBLE, FLOAT, INT, LOGICAL, LONG, STRING. argtype_i = the type of argument passed to the FORTRAN routine and must be consistent in the definition and prototyping of the routine s.a. = DOUBLE, FLOAT, INT, LOGICAL, LONG, STRING. For vectors, i.e. 1 dim. arrays use = DOUBLEV, FLOATV, INTV, LOGICALV, LONGV. For vectors of vectors, 2 dim. arrays use = DOUBLEVV, FLOATVV, INTVV, LOGICALVV, LONGVV, STRINGV. For n-dim. arrays use = DOUBLEV..nV's..V, FLOATV..V, INTV..V, LOGICALV..V, LONGV..V. N.B. Array dimensions and types are checked by the C compiler. For routines changing the values of an argument, the keyword is prepended by a 'P'. = PDOUBLE, PFLOAT, PINT, PLOGICAL, PLONG, PSTRING, PSTRINGV. For exceptional arguments which require no massaging to fit the argument passing mechanisms use: = PVOID. This is most useful for passing functions as arguments. But note that although PVOID could be used to describe all array arguments on most (all?) machines , it shouldn't be because the C compiler can no longer check the type and dimension of the array. argname_i = any valid unique C tag, but must be consistent in the definition as shown. Some notes on (P)STRING(V): STRING - If the argument is a fixed length character array, e.g. char ar[8];, the string is blank, ' ', padded on the right to fill out the array before being passed to the FORTRAN routine. The useful size of the string is the same in both languages, e.g. we pass ar[8] as character*7. If the argument is a pointer, we cannot blank pad, and pass the length as strlen(argument). On return from the FORTRAN routine, pointer arguments are not disturbed, arrays have the terminating '\0' replaced to its original position. i.e. The padding blanks are never visible to the C code. PSTRING - The argument is massaged as with STRING before being passed to the FORTRAN routine. On return, the argument has all trailing blanks removed, regardless of whether the argument was a pointer or an array. N.B. Only char arrays are supported for (P)STRINGV. e.g. char bb[6][8]; STRINGV - The elements of the argument are copied into space malloc'd, and each element is padded with blanks. The useful size of each element is the same in both languages. Therefore char bb[6][8]; is equivalent to character*7 bb(6). On return from the routine the malloc'd space is simply released. PSTRINGV - Since FORTRAN has no trailing '\0', elements in an array of strings are contiguous. Therefore we pad each element of the C array with blanks and strip out C's trailing '\0'. After returning from the routine, we reinsert the trailing '\0' and kill the trailing blanks in each element. Summary: STRING(V) arguments are blank padded during the call to the FORTRAN routine, but remain original in the C code. (P)STRINGV arguments are blank padded for the FORTRAN call, and after returning from FORTRAN trailing blanks are stripped off. PVOID, as noted above, is used to declare that a function will be passed as an argument. In order to perform the call, CFORTRAN must know the language of the function to be passed, therefore the when passing C functions to FORTRAN routines use: FORTRAN_ROUTINE( ...., C_FUNCTION(some_function), ...) and similarly when passing a FORTRAN routine: FORTRAN_ROUTINE( ...., FORTRAN_FUNCTION(some_function), ...) This list of argument types is not neccessarily complete. CFORTRAN may be expanded to handle a new type not among the above. N.B. The FORTRAN routines are called using macro expansions, therefore the usual caveats for expressions in arguments apply. The expressions to the routines may be evaluated more than once, leading to lower performance and in the worst case bizzare bugs. ii) Calling C routines from FORTRAN: -------------------------------- Note that each of the following two statements to export a C routine to FORTRAN create FORTRAN 'wrappers', written in C, which must be compiled and linked along with the original C routines and with the FORTRAN calling code. VAX VMS user's will have to redefine the one of the macros fcallsc or ccallsc. See the examples or existing applications for details and information. FCALLSCSUBn(routine_name, argtype_1, ..., argtype_n) or FCALLSCFUNn(routine_type, routine_name, argtype_1, ..., argtype_n) Where: 'n' = 0->7 (easily expanded to >7) stands for the number of arguments to the routine. routine_name = the FORTRAN name of the routine (IN lowercase LETTERS). routine_type = the type of argument returned by C functions. = DOUBLE, FLOAT, INT, LOGICAL, LONG, STRING. argtype_i = the type of argument passed to the FORTRAN routine and must be consistent in the definition and prototyping of the routine = DOUBLE, FLOAT, INT, LOGICAL, LONG, STRING, STRINGV. For arrays or for routines changing the values of any of their arguments; the C routines expect pointers to these arguments, so the keywords are prepended by a 'P'. = PDOUBLE, PFLOAT, PINT, PLOGICAL, PLONG, PSTRING, PSTRINGV, PVOID. The keyword PVOID is a generic form of the nonSTRING types. STRINGV refers to vector of strings. (P)STRING arguments have any trailing blanks removed before being passed to C, the same holds true for each element in (P)STRINGV. Space is malloc'd in all cases big enough to hold the original string (elements) as well as C's terminatinng '\0'. i.e. The useful size of the string (elements) is the same in both languages. PSTRING(V) => the string (elements) will be copied from the malloc'd space back into the FORTRAN bytes. THE FOLLOWING APPLIES TO THE UNIX COMPILERS ONLY: ---- (P)STRINGV for UNIX only: CFORTRAN cannot convert the FORTRAN vector of STRINGS to the required C vector of STRINGS without explicitly knowing the number of elements in the vector. The application must do one of the following for each (P)STRINGV argument in a routine before that routine's FCALLSCFUNn/SUBn is called: #define routine_name_STRV_Ai NUM_ELEMS(j) or #define routine_name_STRV_Ai NUM_ELEM_ARG(k) or #define routine_name_STRV_Ai TERM_CHARS(l,m) where: routine_name is as above. i [i=1->n.] specifies the argument number of a STRING VECTOR. j would specify a fixed number of elements. k [k=1->n. k!=i] would specify an integer argument which specifies the number of elements. l [char] the terminating character at the beginning of an element, indicating to cfortran that the preceeding elements in the vector are the valid ones. m [m=1-...] the number of terminating characters required to appear at the beginning of the terminating string element. Note that the terminating element is NOT possed on to the C routine. e.g. CFORTRAN will pass on all elements, in the 1st and only argument to the C routine ce, of the STRING VECTOR until, but not including, the first string element beginning with 2 blank, ' ', characters. #define ce_STRV_A1 TERM_CHARS(' ',2) FCALLSCSUB1(ce,STRINGV) Again the lists of types are not neccessarily complete. CFORTRAN may be expanded to handle a new type not among the above. iii) Using C to manipulate FORTRAN COMMON BLOCKS: ------------------------------------------------------- FORTRAN common blocks are set up with the following construct: #define COMMON_BLOCK_NAME COMMON_BLOCK(common_block_name) where common_block_name is given in the case shown. This construct exists to ensure that C code accessing the common block is machine independant. C programs can place a string (or a multidimensional array of strings) into a FORTRAN common block using the following call: C2FCBSTR( CSTR, FSTR, DIMENSIONS); where: CSTR is a pointer to the first element of C's copy of the string (array). The C code must use a duplicate of, not the original, common block string, because the FORTRAN common block does not allocate space for C strings' terminating '\0'. FSTR is a pointer to the first element of the string (array) in the common block. DIMENSIONS is the number of dimensions of string array. e.g. char a[10] has DIMENSIONS=0. char aa[10][17] has DIMENSIONS=1. etc... C2FCBSTR will copy the string (array) from CSTR to FSTR, padding with blanks, ' ', the trailing characters as required. C2FCBSTR uses DIMENSIONS and FSTR to determine the lengths of the individual string elements and the total number of elements in the string array. Note that: - the number of string elements in CSTR and FSTR are identical. - for arrays of strings, the useful lengths of strings in CSTR and FSTR must be the same. i.e. CSTR elements each have 1 extra character to accomodate the terminating '\0'. FCB2CSTR( FSTR, CSTR, DIMENSIONS) is the inverse of C2FCBSTR, and shares the same arguments and caveats. Note that FCB2CSTR copies each string element of FSTR to CSTR, minus FORTRAN strings' trailing blanks. CFORTRAN USERS ARE STRONGLY URGED TO EXAMINE THE COMMON BLOCK EXAMPLES IN CFORTEST.C AND CFORTEX.FOR. The use of strings in common blocks is demonstrated, along with a suggested way for C to imitate FORTRAN EQUIVALENCE'd variables. ===> USER'S OF CFORTRAN NEED READ NO FURTHER <=== III Some Details of and Comments on CFORTRAN -------------------------------------------- The following notes should be useful to those wishing to port CFORTRAN to new types of machines. CFORTRAN.H consist of about 1000 lines of source code. Only about 300 lines of CFORTRAN.H are interesting, the rest are slightly modified 'repeats'. Porting CFORTRAN applications, e.g. the hbook.h and cstring.c mentioned above, to other machines is trivial. hbook.h is machine independant, and cstring.c will at most need to have the 'fcallsc' macro redefined. Porting CFORTRAN itself requires a solid knowledge of the new machines C preprocessor, and its FORTRAN argument passing mechanisms. Logically CFORTRAN exists as two halves, a "C CALLS FORTRAN" and a "FORTRAN CALLS C" utility. In some cases it may be perfectly reasonable to port only 'one half' of CFORTRAN onto a new system. CFORTRAN is simple enough to be used by the most basic of applications, i.e. making a single C/FORTRAN routine available to the FORTRAN/C programmers. Yet CFORTRAN is powerful enough to easily make entire C/FORTRAN libraries available to FORTRAN/C programmers. CFORTRAN is the ideal tool for FORTRAN libraries which are being rewritten in C. It allows the routines to be written in 'natural C', without having to consider the FORTRAN argument passing mechanisms of any machine. It also allows C code accessing these rewritten routines, to use the C entry point. Without CFORTRAN one could fall into the perverse practice of C code calling a C function using FORTRAN argument passing mechanisms! Perhap the philosophy and mechanisms of CFORTRAN could be used and extended to create other language bridges such as ADAFORTRAN, CPASCAL, COCCAM, etc. IV Pros, Cons and Improvements to CFORTRAN ------------------------------------------ The C calls FORTRAN half is all pro. A list would include: i) Machine independant and C or FORTRAN independant calls to FORTRAN code. e.g. C : hbook1(1,"pT spectrum of pi+",100,0.,5.,0.); FORTRAN: call hbook1(1,'pT spectrum of pi+',100,0.,5.,0.) ii) Non-STRING(V) arguments have no, or at most one assignment as overhead. iii) 'Input only' arguments are protected by using an intermediate value. iv) I don't think STRING(V)'s can be handled much faster, even in individually tuned routines. The FORTRAN calls C half has the fundamental inelegancy of using an intermediate function. Perhaps a preprocessor and those %DEF (?) FORTRAN extensions could help. I don't know, I'm just a C programmer who wants to use routines written in FORTRAN. It might make sense to have separate CFORTRAN and FORTRANC utilities, but I've left them tied together for the moment. Using FCALLSCFUNn and CCALLSFFUNn for a function in the same source code, i.e. creating the FORTRAN entry to a C function and then allowing C to call this FORTRAN entry, obviously serves only test purposes. Note that the order given above is a must, and that a compiler warning is generated because the FORTRAN function prototype generated by CCALLSFFUNn does not match the entry point created by FCALLSCFUNn. This might be fixable, see CFORTRAN.H, but since these combo.'s are used in tests only, I don't think it's worth it. I say might because I'm not sure one can satisfy the case sensitive compiler here. V Machine Dependancies of CFORTRAN ---------------------------------- I leave it to the lucky programmer porting CFORTRAN to a new machine, to discover the FORTRAN argument passing mechanisms. A safe starting point is to assume that variables and arrays are simply passed by reference as they are in VAX VMS and UNIX, but I make no guarantees. Strings, and n-dimensional arrays of strings are a different story. I doubt that any systems do it quite like VAX VMS does it, so that the UNIX version may provide an easier starting point. CFORTRAN uses and abuses the ## operator. Although the ## operator proper does not exist in VAX VMS nor in MIPS C, a kludge does; /**/ with no space allowed between the slashes, '/', and the macros or tags one wishes to concatenate. e.g. #define concat(a,b) a/**/b /* works*/ main() { concat(pri,ntf)("hello"); /* e.g. */ } N.B. I have learnt of an alternate kludge to /**/ which could replace ##. On some compilers without ##, /**/ may also not work, this new kludge may be a way out. For more info., porters of CFORTRAN should contact me. VI Machine Dependancies of CFORTRAN Applications ------------------------------------------------ The only machine dependancy of CFORTRAN Applications I know of are the names of routines written in C to be called by FORTRAN. This problem arises under VAX VMS because the 'interpreter' routine, written in C and called by the FORTRAN code, needs an object code name for itself different from that of the original C routine it will try to invoke. This problem does not exist with some FORTRAN compilers. E.g. MIPS' f77 appends each FORTRAN module name with a single underscore, '_', character. Hence, if all C interpreter routines are prepended with this '_', all is well. A similar solution may exist when a case sensitive linker is available. For other compilers, which leave the FORTRAN name as the module name, there exist only two situations. i) If the C source code for the routines is NOT available, the calls to the C routine from FORTRAN must use a different name. In fortran.h the 'fcallsc' [f-calls-c] macro exists to modify the names of the interpreter routines in a consistent manner. ii) If the C source code does exist, a decision for one of the two following possible resolutions has to be made. a) The source code is left alone and an identical approach to i) above is taken. This might be preferable for smaller applications, where the C expertise doesn't exist or has better things to do. b) This is the better method in that it maintains absolute transparency at the user level, unfortunately it is more complicated, but with care it is just as robust at the user level. In short, the objects compiled from the original C modules are renamed. This is done in the header file prototyping the original C routines code. Unfortunately this translation also has to be done when C code calls the C routine. Since the name modification is done in the routines header file, it's hidden from the C user, unless they carefully examines the libraries and/or object code. In CFORTRAN.H the 'ccallsc' [c-calls-c] macro exists to modify the names of the original routines in a consistent manner. THIS SOFTWARE IS PUBLIC DOMAIN. IT MAY BE FREELY COPIED AND USED EVERYWHERE. IT MAY BE DISTRIBUTED WITH NON-COMMERCIAL PRODUCTS, ASSUMING PROPER CREDIT TO THE AUTHOR IS GIVEN, BUT IT SHOULD NOT BE RESOLD. IF YOU WANT TO DISTRIBUTE THE SOFTWARE WITH A COMMERCIAL PRODUCT, CONTACT THE AUTHOR. THIS SOFTWARE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE SOFTWARE IS WITH YOU. SHOULD THE SOFTWARE PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. VAX VMS, Silicon Graphics (SGI), DECstations, Mips RISC and IBM RS/6000 are registered trademarks. /* end: cfortran.doc */