Home > Archive > Fortran > March 2007 > Code Too Large for MS FORTRAN
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Code Too Large for MS FORTRAN
|
|
|
| Hello;
I'm trying to compile a relatively large Fortran 77 program
(prog1.for) with MS Fortran Compiler 5.15 with no success so far!
1. with the command:
>FL /4Nt /Fs /W2 /G2 /Gt /Lr /Nt /FPc87 prog1.for
it produced the error:
"fatal error F1050 : /FPC87 : code segment too large"
2. using the memory-model option /AH instead of the floating-point
option /FPc87 didn't fix the problem.
3. breaking the code into two: (progA.for) and (progB.for), and
compiling each (without linking):
>FL /c /4Nt /Fs /W2 /G2 /Lr /Gt /FPc87 progA.for
>FL /c /4Nt /Fs /W2 /G2 /Lr /Gt /FPc87 progB.for
and then linking the two object files:
>FL /Lr progA progA.obj progB.obj
produced the error:
"progA.obj(PROGA.FOR) : fatal error L1070 : PROGA_TEXT : segment size
exceeds 64K"
Your help would be greatly appreciated.
Monir
| |
| Michael Prager 2007-03-13, 7:10 pm |
| "monir" <monirg@mondenet.com> wrote:
> Hello;
>
> I'm trying to compile a relatively large Fortran 77 program
> (prog1.for) with MS Fortran Compiler 5.15 with no success so far!
> ...
> Your help would be greatly appreciated.
> Monir
As you probably know, MS Fortran is a discontinued DOS compiler
that is between 15 and 20 years old. If you are using Windows
(not DOS), the simplest approach might be to use a modern
compiler. These can access more memory and handle larger
programs.
For example, I have had good luck with g95, which is free.
http://www.g95.org/
--
Mike Prager, NOAA, Beaufort, NC
Address spam-trapped; remove color to reply.
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.
| |
| bandito 2007-03-13, 7:10 pm |
| monir wrote:
> Hello;
>
> I'm trying to compile a relatively large Fortran 77 program
> (prog1.for) with MS Fortran Compiler 5.15 with no success so far!
>
> 1. with the command:
> it produced the error:
> "fatal error F1050 : /FPC87 : code segment too large"
>
> 2. using the memory-model option /AH instead of the floating-point
> option /FPc87 didn't fix the problem.
>
> 3. breaking the code into two: (progA.for) and (progB.for), and
> compiling each (without linking):
> and then linking the two object files:
> produced the error:
> "progA.obj(PROGA.FOR) : fatal error L1070 : PROGA_TEXT : segment size
> exceeds 64K"
>
> Your help would be greatly appreciated.
> Monir
>
What happens if you try a /Gt3 option?
| |
| monir 2007-03-13, 10:08 pm |
| On Mar 13, 6:56 pm, "FX" <coud...@alussinan.org> wrote:
>
> For DJGPP, it seems it's not true anymore:
>
> [ fromhttp://www.delorie.com/djgpp/v2faq/faq2.html] "Starting from
> v2.0, DJGPP programs do not need a separate extender program"
>
> --
> FX
Hello;
1. Compiling (without linking) with the option /Gt3 produced the
error:
"progA.FOR(4165) : fatal error F1050 : code segment too large"
and thus would worsen the situation by not even creating the object
file.
2. Breaking the test.for code into 3 pieces (progA.for, progB.for,
progC.for), instead of 2, worked fine as far as compiling and linking
the object files are concerned, but the "program too big to fit in
memory". Will try on an advanced m/c.
3. Is the earlier error: "segment size exceeds 64K" related to the
individual *.obj files?
............progA....progB.....progC
.....*.for 121KB 47 234
.....*.obj 68 38 82
while the test.exe is 656 KB.
3. By the way, the reference MS Fortran documentaion is entitled
Version 5.1 (1991), though the compiler displays Version 5.15
4. The suggestion to migrate to a modern compiler is probably a more
realistic option than trying Win 3.1
Regards.
Monir
| |
| Terence 2007-03-14, 4:18 am |
| I sometimes see this problem. I still use bug-free MS 3.31 myself
(even though I have CVF 6.6c and Intel 9.1) Any MS compiler since
seems to have reported bugs.
First step is to see if some large matrices can be put into named
common.
(Blank common and each named common have individual 64k data space
limits.
Code normally has one 64 memory block, but you can overlay parts of
this if needed).
This takes them out of the single 64k memory space limit you seem to
have crossed.
I've never known this to fail; but once done, you STILL may have too
many named variables for the compiler, (the message will be "? out of
memory"), in which case you ensure that at least your MAIN program
will compile; so work on that first.
Afterwards, any other routines and functions can be compiled (FOR1 and
PAS2) and left as object modules.
You finally link in the compiled-and-pas2 main object module with any
others needed and any libraries of your often-used routines.
| |
|
| > I still use bug-free MS 3.31 myself
Ah, the famous bug-free software!
The only software that doesn't have bugs is the software that noone uses.
--
FX
| |
| Terence 2007-03-14, 8:08 am |
| There is a major difference between bug-free COMPILERS and bug-free
SOFTWARE in general.
Since the first is used to produce the latter, it makes sense for the
major effort to go into making a GENERATOR or COMPILER bug-free.
Since our company uses this same old 1985 compiler for our TABLE-
DRIVEN commercial software (no bugs that way), we haven't found an
exception to my claim. Normal programs under development, compiled
with a bug-free compiler will usually start off with bugs in them; but
at least you know to look in your own code first (and always).
I KNOW every well the feeling you get when a problem shows up that
makes you suspect the compiler messed something up, because in the
early days I went through that phase, but confidence in the compiler
will help you find the bug in the program under development.
And since we don't charge for updates (replacements with more
features) and we get no user problems reported that cannot be very
quickly identified as user bugs in their SOURCE text (remember, we
produce language-driven compilers, themsleves compiled with a 1985
FOrtran compiler), we have almost zero support costs. And Fortran is
very good for text processing and linked lists and of cose, final
report writing.
| |
| e p chandler 2007-03-14, 8:08 am |
| On Mar 14, 7:50 am, "Terence" <tbwri...@cantv.net> wrote:
> There is a major difference between bug-free COMPILERS and bug-free
> SOFTWARE in general.
> Since the first is used to produce the latter, it makes sense for the
> major effort to go into making a GENERATOR or COMPILER bug-free.
>
> Since our company uses this same old 1985 compiler for our TABLE-
> DRIVEN commercial software (no bugs that way), we haven't found an
> exception to my claim. Normal programs under development, compiled
> with a bug-free compiler will usually start off with bugs in them; but
> at least you know to look in your own code first (and always).
>
> I KNOW every well the feeling you get when a problem shows up that
> makes you suspect the compiler messed something up, because in the
> early days I went through that phase, but confidence in the compiler
> will help you find the bug in the program under development.
>
> And since we don't charge for updates (replacements with more
> features) and we get no user problems reported that cannot be very
> quickly identified as user bugs in their SOURCE text (remember, we
> produce language-driven compilers, themsleves compiled with a 1985
> FOrtran compiler), we have almost zero support costs. And Fortran is
> very good for text processing and linked lists and of cose, final
> report writing.
1. At least 3.31 did not delete source files unless they were listed
on the command line as did 3.20. FWIW 3.31 was written (as was much MS
software of the time) in Pascal.
2. Interesting to see what can be done in Fortran, even in FORTRAN.
See Kernigan & Plauger's "Software Tools". (This describes programming
with the RATFOR pre-processor.)
3. Someone in this NG joked about writing a compiler in COBOL.
MicroFocus did that with their MS-DOS/PC-DOS compilers. (Perhaps they
still do so today.)
Again there is something appealing about using a small sharp tool for
a job, bearing in mind the limitations of that tool. :-).
-- e-mail: epc8 at juno dot com
| |
|
|
| Kevin G. Rhoads 2007-03-14, 7:12 pm |
| >I still use bug-free MS 3.31 myself
However, MS 3.31 is only F77 subset with some extensions from full F77.
It is, however, quite useable. I keep a copy ready to run on both my work
and home systems, in addition to MS 5.1, FPS4, DVF5 and CVF6 and various
versions from Watcom/OpenWatcom: 10.6 & 11.0/OW1.3 and a few versions of
the RM Fortran.
I find that asking different compilers to critique my source code is useful ;-)
| |
| Kevin G. Rhoads 2007-03-14, 7:12 pm |
| >How about building as a Win 3.1 (QuickWin) application, or does the
>size increase only apply to data?
Total code and data size goes from <1MB to ~16MB w/ QuickWin apps.
However, there is still the limit that any one routine can be no
more than 64k.
| |
| Kevin G. Rhoads 2007-03-14, 7:12 pm |
| >4. The suggestion to migrate to a modern compiler is probably a more
>realistic option than trying Win 3.1
A more modern compiler is definitely better -- but compiling and linking
to a QuickWin app will get a Win3.0 EXE that will run just fine under
Win 3.x, Win9x, WinME, WinNT, Win2k, WinXP and OS/2 2.x or later with
Win3.x support installed.
You do NOT have to try to RUN Win3.1 to use a Win 3.x EXE anymore than
you need to run pure DOS to run most DOS EXEs.
| |
| Thomas Koenig 2007-03-14, 7:12 pm |
| FX <coudert@alussinan.org> wrote:
Hi FX,
>Ah, the famous bug-free software!
>The only software that doesn't have bugs is the software that noone uses.
Well, not quite...
There is a utility for MVS (IBM mainframe) systems called IEFBR14.
It doesn't actually do anything (i.e. it serves as a placeholder in
JCL when somebody needs a "program" to execute in order to do
something with DD statements).
When it was originally written, it contained only a single assembler
statement, BR 14 (branch to register 14), where register 14 contains
the return address. So far, so good.
First bug: The program failed to clear register 15, which contained the exit
code, which caused all kinds of failures through subsequent JCL steps
failing.
Second bug: The first attempt at fixing zeroed the wrong register.
This was then fixed.
Ever since, IEFBR14 is widely believed to be bug-free.
| |
|
|
"monir" <monirg@mondenet.com> wrote in message
news:1173803120.772956.216480@p10g2000cwp.googlegroups.com...
> Hello;
>
> I'm trying to compile a relatively large Fortran 77 program
> (prog1.for) with MS Fortran Compiler 5.15 with no success so far!
>
> 1. with the command:
> it produced the error:
> "fatal error F1050 : /FPC87 : code segment too large"
>
> 2. using the memory-model option /AH instead of the floating-point
> option /FPc87 didn't fix the problem.
>
> 3. breaking the code into two: (progA.for) and (progB.for), and
> compiling each (without linking):
> and then linking the two object files:
> produced the error:
> "progA.obj(PROGA.FOR) : fatal error L1070 : PROGA_TEXT : segment size
> exceeds 64K"
>
> Your help would be greatly appreciated.
> Monir
>
Like everybody else - switch to a more modern Fortran implementation.
If there are any reasons as to why not, then look through the documentation
for the following:
1. You must compile for Windows.
2. /AH pushes arrays into the heap. You need to look for the command that
decides at what size to push data from the stack onto the heap.
3. If a subroutine really does exceed 64K then you will need to break that
subroutine down into two or more routines - the linker/compiler map output
should help locate the offending subroutine. Remember that even if you are
just less than 64K this can cause problems, so you are advised to keep
smaller than ?60K? - better still, 32K. But that would be encouraged anyway,
in keeping modules small enough to comprehend.
I had this problem in 1997; the short-term solution was to get as much data
as possible onto the heap, where /AH handles it. The long-ternm solution was
to switch to Digital Fortran Version 5, which compiled at the first pass.
Even then I had to change a parameter realting to the size of stack, but
this was no longer needed by Version 6.
| |
| Beliavsky 2007-03-16, 4:31 am |
| On Mar 14, 7:29 am, "e p chandler" <e...@juno.com> wrote:
<snip>
> 2. Interesting to see what can be done in Fortran, even in FORTRAN.
> See Kernigan & Plauger's "SoftwareTools". (This describes programming
> with the RATFOR pre-processor.)
A more advanced book along the same lines, using Fortran 77, is
Fortran Tools for VAX/VMS and MS-DOS
by Russell K. Jones and Tracy Crabtree
Wiley (1988)
It's a unique Fortran book, with used copies available inexpensively
on Amazon.
| |
| Brooks Moses 2007-03-16, 4:31 am |
| Terence wrote:
> I KNOW every well the feeling you get when a problem shows up that
> makes you suspect the compiler messed something up, because in the
> early days I went through that phase, but confidence in the compiler
> will help you find the bug in the program under development.
Oddly enough, what I remember is the first time I came across a simple
bug that seemed to be the fault of the compiler, which was only a few
months after I first started learning Fortran. I went through the usual
binary search of finding the place where the bug was, and eventually
discovered that at one point in my program two was apparently equal to
three, and was completely baffled for rather a while.
I ended up looking through the CD of programming tools that the
university had provided to all of us freshmen in the introductory
engineering class I was taking, and discovering that as well as the
advertised Watcom (I think) Fortran compiler on it, somewhere hiding in
a subdirectory with some other things was a copy of a Microsoft Fortran
compiler of some version, and when I compiled the program with that, the
bug went away.
Unfortunately, I've long since lost the code in question, because when I
got some more experience I started wondering if maybe it really was my
fault and I was doing something with an array index out of bounds
somewhere or something like that.
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
| |
| Pierre Asselin 2007-03-16, 7:07 pm |
| Brooks Moses <bmoses-nospam@cits1.stanford.edu> wrote:
> I went through the usual
> binary search of finding the place where the bug was, and eventually
> discovered that at one point in my program two was apparently equal to
> three, and was completely baffled for rather a while.
Isn't that a classic Fortran programmer's bug ?
call set_me_to_three(2)
and now the constant 2 is equal to 3. It's not guaranteed to fail
in this way on all platforms, though, so don't rely on it :-)
Nowadays these errors can be caught by declaring the intent
of your subroutine arguments.
--
pa at panix dot com
|
|
|
|
|