isabel@uw-june (Isabel Domenech) (04/04/86)
Does anybody know how to patch the Microsoft FORTRAN compiler v. 3.2, or the
resulting executable files, so that the presence of a 287 math co-processor is
properly checked at run time?
The check works well on a PC, but on an AT it seems the code always decides
that there is a 287, even when one is not present. As a result the machine
hangs, waiting for the 287 to respond.
I bought the current version (3.31) because it has fixed the problem, but it
is unusable to me right now because Microsoft has decided to change the memory
model and my programs will no longer work.
I wrote a finite element analysis package, which requires big arrays. To avoid
having to create different versions for machines with different memory sizes
(512K, 640K, ...) the programs check the available amount of memory in the
machine at runtime and use it if needed.
This is possible because in version 3.2 the named COMMON blocks are allocated
after everything else and, therefore, the last one may be expanded to the top
of the memory very easily.
But now the last thing allocated is the stack, with the named COMMON blocks
buried somewhere in the middle. Of course, to expand the stack is now a piece
of cake, but what good does it do in FORTRAN?
I suspect that Microsoft wants us to use FORTRAN the same way we would use C,
which in my opinion is not the way to go. Their compiler still has many things
missing from the 77 standard but they seem more interested in adding
non-standard features (C strings, INTERFACE, Attributes (ALIAS, NEAR, HUGE...))
than in supporting the full ANSI standard. What a joke!
Another thing that irks me is that their documentation still shows the old
memory model (Section 10.3.2) and you don't discover the problems until you
either look at the map provided by the linker or notice that a table in one
of the appendices (A.11) contradicts the information presented in much more
detail in the main text.
In summary, I am most unhappy with this product and with the unprofessional
attitude of Microsoft. Anybody looking for a FORTRAN 77 compiler should try
to look elsewhere because Microsoft efforts to support the language do not seem
very serious.
Thanks in advance to anybody that may help me fixing the 287 bug.
Fernando G. Loygorri (isabel@uw-june)steve@jplgodo.UUCP (Steve Schlaifer x3171 156/224) (04/14/86)
In the reference, the author complains (bitterly :-)) about the microsoft MSDOS Fortran compiler. After looking at what was available, we chose the Lahey Fortran compiler for our use in porting a set of large libraries from our mainframes to micros. The main reason we chose Lahey was that it supported the full F77 ANSI standard not just the subset. We have since found fewer bugs in the compiler than the people around here who chose the Microsoft compiler and what we feel is a much more professional attitude toward the user. Take a look and I think you will like it. -- ...smeagol\ Steve Schlaifer ......wlbr->!jplgodo!steve Advance Projects Group, Jet Propulsion Labs ....group3/ 4800 Oak Grove Drive, M/S 156/204 Pasadena, California, 91109 +1 818 354 3171