FORTRAN Question

[Calvin H. Vu]

In article <8906081116.aa29217 at SMOKE.BRL.MIL>, XBR2D96D at DDATHD21.BITNET (Knobi der Rechnerschrat) writes:
> Hallo everybody,
> 
> my friend has the following Fortran code
> 
>         PROGRAM TEST
>         WRITE(*,*) 'Test Test'
>         END
> 
>  When compiling this code with several debug/optimize switches you get the
> following sizes for the executable image files:
> 
>                  cc -xxx t.f -o t        f77 -xxx t.f -o t
> xxx=g              220472 byte             292984 byte
> xxx=O1             220388 byte             292900 byte
> xxx=O2                          same as O1
> xxx=O3                          same as O1
> 
>The same program compiled on a VAX (I'm definitely not a great VAX friend) with
>the most unfavourable switches (/DEBUG=ALL/NOOPT on compile and /DEBUG/NOSYSSHR
> on link) gives a maximum size of 25000 byte (4000 byte using the shared libs).

	The large size of the executabes is due partly to the way libI77
	is written (generic UNIX system problem ?) and partly to the addition
	of the ISAM library to the Fortran package.    Roughly, the 290K bytes
	produced by the compiler/linker are picked up from:

	- 130K from libmpc.a  (60K if you use libc.a.  This accounts for
			the difference in size between using cc and f77)
	- 140K from libisam.a
	- 19K  from other libraries
	- 1K   from the program itself 

	That's why it doesn't matter much whether you use -g or -O3 to
	optimize your program since the problem is in the packaging of 
	the runtime I/O libraries and not in the code generated from the
	user source (the .o files is less than 1K for the test above).
> 
> I know that RISC code is larger than CISC code, but I didn't know that the
> difference is that large.
	The difference would be small if the same runtime I/O libraries 
	were used.

> What I also don't understand is the difference
>between cc and f77. I thought if cc detects a fortran file it would just do the
> same as f77.
	When you use f77 the multiprocessing libc (libmpc.a) is used
	instead of libc.a.

> As a last question, is SGI (or MIPS if thats the right target for
> this problem) thinking about shareable libraries beside libgl_s.a ? I think
> that would greatly reduce link time and disk usage.
> 
	I plan to rewrite the runtime I/O libraries so that the ISAM routines
	will only be linked into the executable with a compilation flag. That
	will reduce the size by at least 100K.   libc_s.a can also be used
	as an option to reduce the size by a further 50K.    That would
	make the size of the executable for the test above about 80K.   Of 
	course, if libI77.a is also changed upside down so that only routines 
	which are actually used will be linked then the size could be even 
	less, maybe <40K, but ... :-(.    And of course, the initial runtime
	I/O overhead of ~200K would become less of an annoyance if your 
	program is large.

> Regards
> Martin Knoblach
> <xbr2d96d at ddathd21.bitnet>

Calvin Vu