🚀 go-pugleaf

In article <3100@ssc-vax.UUCP> housen@ssc-vax.UUCP (Kevin Housen) writes:
>In article <2906@dogie.macc.wisc.edu>, elabed@vms.macc.wisc.edu (Hani El-Abed, MIC at MACC) writes:
>> 
>> This is my personal opinion about MS FORTRAN and the Company They bought
>> it from (Absoft)...
>> 
>> I think these two compiler are pieces of Garb***e...
>> 
>> I had tons of problems with them...
I too had this experience. This was version 2.2.

The compiler generated truly awful code - the worst I have seen
since the word "optimizer" was first thought of, in when was it, 1962?
The only word for the generated code was "abysmal".

Examples - one program had about 20 kilobytes of static data, in 
a block data subprogram. This is a perfectly natural, normal,
garden variety Fortran thing to do. (It was machine generated code,
various tables.)

This subprogram should occupy 20 kilobytes in the executable file,
of course. In the Microsoft Fortran it occupied 120 kilobytes
- and this was CODE!!! The data was not in as data at all, but instead
it was put in-line as literals in CODE, which copies the data to
the data area. In the case of strings, a single byte of data
generated 7 bytes of code!!!!!

The statement
      if(i.eq.j .or. k.eq.l .or. m.eq.n) goto 1

was compiled abysmally. The obvious way is to compare i to j,
and jump to 1 if the condition is true. Then do that for k.eq.l,
then for m.eq.n. NO!! What it did was compare i to j, getting 
a flag byte for true or false in an accumulator. Then it converted
that to a word, then in another step to a doubleword. Repeat for
the other to comparisons, then and only then OR the three doublewords
together, compare that with zero, and jump on the result.

UGH!

Doug McDonald