Path: utzoo!attcan!uunet!spool2.mu.edu!samsung!cs.utexas.edu!yale!venus!tang
From: tang@venus.ycc.yale.edu
Newsgroups: comp.lang.fortran
Subject: Re: Array dilemma
Message-ID: <765.279eeee9@venus.ycc.yale.edu>
Date: 24 Jan 91 19:27:51 GMT
Organization: Yale Computer Center (YCC)
Lines: 83

>I am currently on a project for surveyors and recently attempted to port
>the code from our Sun workstation to a PC.  Unfortunately, the original
>code needed double precision arrays of the order of 50000 elements or
>higher.
> 
>We believe that the current version of Microsoft Fortran falls down
>because it could not handle such code so I pushed the department to go
>for the Lahey Fortran F77L compiler.  However, I now believe that the
>F77L compiler will not solve this problem either.
> 
I normally use a MICROVAX II to develop programs, but occasionally I 
also use a PC for that purpose.  The type of work that I do requires
several double-precision arrays of sizes on the order of (100 by 100 by 10). 
But I have to reduce the size to (10 by 10 by 10) on PC because the program
code section took up about 400KB.  The compilers I use are Microsoft
Fortran and Ryan McFarland Fortran (old, v1 ?).  Either one meets
my needs, but I perfer RM Fortran because, apparently, it comforms more
closely to VAX Fortran.  However, they have the inherent problem of 
program (code and data) size restriction (640kb DOS limit).  MS Fortran
has various memory models which you can choose.  These models impose
various restrictions on the size of code and/or data.


>Cause of problem      DOUBLE PRECISION BIG(3,50000)
>Synopsis of problem   compiler won't compile code for BIG is size 3x50000.
>
The size of BIG in this case is > 1MB.  This program clearly cannot run
or compile with MS Fortran (not RM Fortran either).


>Synopsis 2            PC won't load executable when BIG is size 3x4000.
>
The size of BIG is ~94KB.  

>Synopsis 3            Seems to runs ok, when BIG is size 3x3000.
>Current Size of EXE   About 150K (for both Synopsis 2 and 3).
>
The size of BIG is ~71KB.  

Based on the size of EXE, I have the following suggestions.  Do a CHKDSK
to find out the available amount of memory.  Check the results obtained
from this array size (3000).  I think you might not have the right answer. 
Because of DOS, there is a 64KB segment limitation on code and data
size.  Since the size of BIG is larger than 64KB, there might be a
problem here.  Try compiling the program with the \AH qualifier which
removes the 64KB restriction.  The penalty is execution efficiency.  


>Question 1            Will F77L handle this problem?
>
Not clear, because of the origin of the problem.  Do try to compile the
program with the \AH qualifier.  (Most conventional compilers are
more-or-less the same.)


>Question 2            Does F77L allocated space for arrays in the EXE?
>                      - Will I get a larger EXE file? (somewhat 600K?).
>Question 3            Is there a compiler that would solve this problem?
>
>There is little chance that I can push the department to get an F77L/EM,
>but I would be interested if that or any other compiler would solve my
>problem.  If all fails, I probably replaced the array with random 
>accessing a large file instead.
>
I don't have an answer for Q2.  The only sure answer are those compilers
that support DOS Extenders (e.g. F77L/EM). 

Another suggestion is to split up large program segments into 
smaller ones.  I once had a problem which sounds stupid.  It was a
canned routine which has many comments (comments/exe.statements = 1). 
Both MS and RM compilers refused to compile.  I had to remove all of the
comments before they compiled it successfully.  Apparently, they keep
everything, including comments, in memory.  Once a 64KB segment is
filled, an compiler error is generated.  The idea here is to split up
subroutines so that each one can fit  into a 64KB segment.  


>--
>Stephen Quan,
>University of Tasmania.
>
Tang Wong
Yale University