usenet@nlm-mcs.arpa (usenet news poster) (05/07/90)
In article wipke@secs.ucsc.edu (W. Todd Wipke) writes: >William Silvert wrote that they had achieved high portability of >fortran. It would be useful if he could post a list of the experience >he has, ie. things to avoid, and also include a sample of his code. I have also worked with a large package which has been proted to a number of different machines including VAX/VMS, IBM/AIX, Convex, Apollo, Sun, and SGI. Basically our experience has been that if you stick to Fortran 77 it will port with minimal effort. The problem areas we ran into include: - VAX/VMS extensions particularly in OPEN statements are useful but not universally supported. Solution we have used is to encapsulate OPEN into a single routine which is called anywhere a file needs to be openned. This routine may need to be tweaked in a port. - Access to command line arguements and environment variables. Not part of the F77 standard and highly OS dependent. Again, we encapsulate it and may need to tweak the relevant routine. - System resource utilization tracking (CPU time, page faults etc.) Same issues as above, handled same way. - Dynamic memory allocation. Definitely not part of F77, but a useful tool when you can get it. We use a single, very machine dependent routine to get pointers to memory from the OS. The pointer is translated into an index to an array in common which is then accessed via regular Fortran (except for being massively out of the compile time array bounds). Sounds kludgey as hell, but it has been a surprisingly robust trick. - Path names for include files. Obviously site dependent. We handle it with a preprocessor that does the path translation and includes independent of the the Fortran compiler so we have more control over it. >Does he for example deal with bit masks, binary sets, packed information, >which sometimes get fouled by byte order differences? We use binary files extensively at a site, but we use straight ASCII to comunicate from site to site. Translating binary from site to site would be far to painful to contemplate (byte order, FP format, recognizing data entities automatically in heterogeneous files, etc). Internally we do some bit packing using integer arithmatic. Lots of Real*4/ Integer*4 equivalences are used to share memory (see dynamic memory above), but we do not to try interpret data through equivalences. >Does he rely on fortran for parsing input? Yes, we do straight ASCII input to character variables and parse in FORTRAN. >Putting out a prompt >and leaving the cursor at the end of the line on an IBM system? >The ability to see if a character has been typed without issuing a read, >for soft interrrupt capability--does he do that? We don't bother. Same with single keystroke/character input (ie. no CR). >There have been cases where versions of >fortran did not take error exits, they crashed. Our error handling/trapping is pretty primitive. David States