HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.lang.fortran
Subject: subroutine calls with loop index parameters
From: ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig)
Date: Tue, 18 Aug 1992 06:49:27 GMT
Organization: University of Auckland, New Zealand.

In a recent discussion on alt.folklore.computers, I read that some
compilers produce inefficient code when subroutines or functions
are called with loop indices as parameters, for example:

      REAL A(10,10)
      DO 10 J=1,10
	 DO 20 I=1,10
	    A(I,J) = FUNC(I,J)
   20    CONTINUE
   10 CONTINUE

The compiler in question (VAX/VMS, I believe) suddenly started
generating multiply instructions inside the inner loop, which it had not
done before. Introducing auxiliary variables, which were assigned the
values of the loop indices and used as function arguments, led to far
better code generation.

Unless I am quite mistaken, the FORTRAN standard specifies that it is
illegal to modify the value of an index variable inside the loop, so
any change which FUNC made to it would have been illegal; the compiler
could therefore safely assume it would not be made, and produce optimum
code the first time.

How widespread is this kind of behaviour? Should I always introduce
additional variables to get around situations like that?
-- 
Thomas Koenig, ecmtwhk@ccu1.aukuni.ac.nz, ib09@rz.uni-karlsruhe.de
The joy of engineering is to find a straight line on a double logarithmic
diagram.
Newsgroups: comp.lang.fortran
From: tholen@galileo.ifa.hawaii.edu (Dave Tholen)
Subject: Re: programming style question
Organization: University of Hawaii
Date: Sun, 16 Aug 1992 19:56:51 GMT

Claude LaPointe writes:

> Because the 77 standard didn't much consider the kinds of output
> capabilities now available, it didn't address standard error,
> so there is no choice but to use a unit number - however it should
> be done with the realization that porting may require a change in the
> value. That is, isolate its use as much as possible in a subprogram
> and define it with a parameter statement.

Actually, I do isolate its use.  I try to put as much system-dependent
stuff in a BLOCK DATA subprogram, so when I need to port a program from
the PC environment to a Sun workstation, for example, I just edit one
tiny block of code, namely the BLOCK DATA subprogram, and change unit
numbers and filenames as needed.  Unit numbers are rarely changed
nowadays, because my most commonly used platforms all associate 0 with
standard error, 5 with standard input, and 6 with standard output.  But
filenames are constantly changed, due to the 8.3 limitation of the FAT
file system on the PC, and the differences in the use of backslash and
forward slash.  Another change I make in my BLOCK DATA subprogram
depends on whether the system strips a carriage control character from
the standard output stream.  Some do, some don't.  The main program
and all the other subprograms, however, are written with portability
in mind.  But now I have this compiler that doesn't preconnect standard
error.  So I must decide whether to route error messages through the
standard output channel or explicitly open a separate unit.  The former
might mess up redirection, because many of my programs were written
with separate output streams for error messages and non-error-message
text specifically with the possibility of redirection in mind.  One
does not always want to redirect ALL output, hence the use of two
(or more) output streams.
Newsgroups: comp.lang.fortran
From: map@hal.maths.monash.edu.au (Michael Page)
Subject: Re: programming style question
Organization: Mathematics Department, Monash University, Australia
Date: Fri, 14 Aug 1992 00:25:38 GMT

pm@katz.cc.univie.ac.at (Peter Marksteiner) writes:
>ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig) writes: 
>
>>It's a real shame that Unix does not have standard way of attatching
>>FORTRAN units to file descriptors, that would make things much easier.
>>Does POSIX have anything to say about that?
>
>Try symbolic links. For example,
>
>    ln -s /whatever/pathname/you/want fort.3
>
>may not be as beautiful as
>
>//FT03F001  DD  DSN=REVOLTING.MVS.DATASET,DISP=NEW
>
>but it works almost as well. 

Unfortunately `almost' is important here.  One of the nice features of
VMS (gargle) was the ability to use:

$ define/user_mode 'P1'.dat for005
$ define/user_mode 'P1'.out for006
$ run myprog

in a command procedure.  The advantage here is that you can have that
program running on at least two different sets of data in the same directory
at the same time.  The only way you can do this with symbolic links is to 
place the data files in different directories.  A royal pain if you are 
doing a lot of batch processing, which I suspect applies to most serious 
FORTRAN users.  A very bad design decision from a supposedly flexible 
operating system.

I, and probably many others, get around the problem by passing the 
argument (P1, above) into the program using getarg, doing some string
handling to create the file names and using open explicitly.  Messy.

--
+------------------------------------------------------------------------------+
 Michael Page, Maths Dept, Monash University, Clayton, Victoria, AUSTRALIA 3168
  email: map@hal.maths.monash.edu.au phone: +61 3 565 4486 FAX: +61 3 565 4403
+------------------------------------------------------------------------------+
From: morgan@reg.triumf.ca (BURKE, MORGAN)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran subroutine in C main (2)
Date: 20 Aug 92 22:21:00 GMT
Distribution: comp.lang.fortran
Organization: TRIUMF: Tri-University Meson Facility
News-Software: VAX/VMS VNEWS 1.41

In article <JAAKSI.92Aug18192406@korppi.cs.tut.fi>, jaaksi@cs.tut.fi (Jaaksi Ari) writes...
>How to use Fortran subroutines called from C main. Everything
>else seems to be OK except when some IO -routines occur in
>Fortran subroutines.

Your problem is that f77 [fc] links in various support routines when you
compile a Fortran main program, but not if you simply link Fortran 
objects to a C main program.  The obvious solution is to use a Fortran 
main routine instead of C, and compile with f77 [fc].

If you do not need use of argc and argv in your C main(), then this is 
easy:

main.f:
	PROGRAM MAIN
C  all Fortran support code will be linked automatically
	CALL C_MAIN
	END
main.c:
	void c_main_()   /* trailing underscore required on some 
			    platforms;  check your documentation */
	{
	  /* this is your original C main() routine */
	}

If you _do_ need to use argc and argv, then things are more complex.
You must re-create argc and argv yourself from the Fortran environment.
This is commonly done with the IARGC and GETARG calls (this is not
standard, so check your docs).  Then you simply call your original
(but renamed) main() routine with the aritificial argc and argv.
On an SGI, the following code works (thanks to Scott Townsend of 
Sverdrup Technology Inc.  NASA Lewis Research Center Group):

extern int  iargc_ (void);
extern void getarg_ (int *i, char *c, int c_len);
extern int  svp_main(int argc, char *argv[]);

#define MAX_ARGS        20
#define MAX_ARG_LENGTH  100

int     _argc;
char    *_argv[MAX_ARGS],
        _args[MAX_ARGS][MAX_ARG_LENGTH];

void c_main_()
{
  int i,j;

  strcpy(_args[0], "your_program_name");
  _argv[0] = _args[0];
  _argc = iargc_ () + 1;
  for (i = 1 ; i < _argc ; ++i) {
    getarg_ (&i, _args[i], MAX_ARG_LENGTH - 1);
    _argv[i] = _args[i];
    for (j = MAX_ARG_LENGTH - 2 ; j > 0 ; --j) {
      if (_args[i][j] == ' ')
        _args[i][j] = 0;
      else
        break;
    }
  }
  actual_c_main(_argc, _argv);
}

void actual_c_main(argc,argv)
	unsigned int argc;
	char **argv;
{
  /* this is your original main() routine */
}

................................................... Morgan Burke
						     morgan@reg.triumf.ca
Newsgroups: comp.lang.fortran
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: C versus FORTRAN debate
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 20 Aug 1992 21:40:33 GMT

jac@moonshine.llnl.gov (James A. Crotinger) writes:

>jsvrc@rc.rit.edu (J A Stephen Viggiano) writes:
>> >Continuing to compare F77 to languages like C is a bit silly.  
>> As is comparing FORTRAN 90 to languages like C. (Sorry, no ":-)".)
>
>  I fail to see why this is silly. I think it is perfectly reasonable
>to compare C++ (a language "like C") and Fortran 90. ...

Yes, but C != C++.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature VIRUS is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: blom@cs.chalmers.se (Katarina Blom)
Newsgroups: comp.lang.fortran
Subject: Requesting books in fortran 90
Date: 13 Aug 92 14:46:08 GMT
Organization: Dept. of CS, Chalmers, Sweden

Chalmers University of Technology will give several courses in 
Fortran 90 in the near future.
The courses will be given for beginners, so I am looking for
an introductory book in Fortran 90, preferably including
programming techniques.
I have seen the book 'Fortran 90 explained' by Michael Metcalf
and John Reid, but I find that to complicated for beginners.
Suggestions for books that exist now or will exist in a near future
are very welcome (Books has to be in English or Swedish)

        Thanking you for helping
                --Katarina
                e-mail: blom@cs.chalmers.se
From: ags@seaman.cc.purdue.edu (Dave Seaman)
Newsgroups: comp.lang.fortran
Subject: Re: imsl subroutine ggubs
Date: 14 Aug 92 19:25:15 GMT

In article <1992Aug14.140728.22892@porthos.cc.bellcore.com>  
chh2@rigel.uucp (22352-halevi) writes:
> So, anyone out there know what ggubs is, or if its just a short piece of
> code could you send it to me (in either fortran or C incarnations).

GGUBS is an obsolete IMSL routine (superseded in the current IMSL library)  
for generating uniform random numbers. Its calling sequence was

	CALL GGUBS (DSEED,NR,R)

where DSEED in a double precision input/output variable assigned an  
integer value, NR is the number of deviates to be generated (input), and R  
is the vector of length NR containing the uniform (0,1) deviates (output).

--
Dave Seaman
ags@seaman.cc.purdue.edu
Newsgroups: comp.lang.fortran
From: davem@ee.ubc.ca (david michelson)
Subject: Re: programming style question
Organization: University of BC, Electrical Engineering
Date: Mon, 17 Aug 1992 17:45:16 GMT

With the keyword "SAVE" in hand, I rechecked some of my Fortran and
numerical computing books.  This quote from "Numerical Recipes: The Art
of Scientific Computing" caught my eye:
 
"The Fortran 77 standard provides that variables internal to a subroutine
are *not* guaranteed to be saved between successive calls to that 
subroutine unless the variable is declared global in a SAVE statement.
(This allows stack-oriented implementations.)
 
If this part of the standard were "enforced", a large fraction of all 
programs written by all living programmers would immediately cease to
function.  Only a few compilers *dare* to implement this part of the
standard, therefore."

[...followed by notes about the *correct* way of handling things -- 
according to the ANSI standard...]


(pp 13--14) "Some habits and departures from ANSI Standard"

Dave Michelson   "davem@ee.ubc.ca"
From: HBO043@DJUKFA11.BITNET (Dr. Christoph van Wuellen)
Newsgroups: comp.lang.fortran
Subject: Re: C versus FORTRAN debate (WAS: Re: Welcome to HPFF
Date: 18 Aug 92 13:52:36 GMT
 <1992Aug14.224112.19348@sol.UVic.CA> <1992Aug15.172219.2138@ibr.cs.tu-bs.de>
Organization: KFA  Forschungszentrum Juelich

Sometimes there are very trivial reasons to prefer FORTRAN:

On a Siemens/Fujitsu vector computer where I have access to (a nice
machine with 5 Giga-FLOPS), there only is a FORTRAN compiler, no
assembler, no C, no PASCAL, only FORTRAN.

C.v.W.

P.S. I have not yet seen a 100,000 lines C program, whereas I work with
several FORTRAN programs which are larger than this.
From: fox@rudolf.nscl.msu.edu (Ron Fox)
Newsgroups: comp.lang.fortran
Subject: Re: Unix ARGC,ARGV in Fortran 77
Date: 20 Aug 92 12:06:08 GMT
Reply-To: fox@rudolf.nscl.msu.edu (Ron Fox)
Organization: National Superconducting Cyclotron Lab.

--

>marshall@marshall.cs.unc.edu (Jonathan A. Marshall) writes:
>: I need to write a Fortran program that will accept command-line
>arguments.
>: I'm running Ultrix f77 on a DECstation 5000.  In C, command-line
>arguments
>: can be passed with argc and argv.
>: 

  According to pf 3-3 of the 
_DEC_FORTRAN_FOR_ULTRIX_RISC_SYSTEMS_USER_MANUAL_ 
for version 3.0, the routines getarg() returns command line arguments.
my version of the manual pages does have a man 3f getarg. So you
can get the details there.  Although in summary:


   nargs = iargc()     ! Returns the number of arguments.
   call getarg(k, arg) ! Returns the k'th argument into arg.


Ron Fox                     | FOX@MSUNSCL.BITNET      | Where the name 
NSCL                        | FOX@RUDOLF.NSCL.MSU.EDU | goes on before
Michigan State University   | MSUHEP::RUDOLF::FOX     | the quality
East Lansing, MI 48824-1321 |                         | goes in.
USA
Newsgroups: comp.lang.fortran
From: boucher@ug.cs.dal.ca (Darren B. Boucher)
Subject: Fortran for the PC
Organization: Math, Stats & CS, Dalhousie University, Halifax, NS, Canada
Date: Fri, 14 Aug 1992 21:16:20 GMT

 If there is is a Fortran compiler in Public Domain or Shareware around
could someone please leave me a message how to get one, preferably an
FTP site. thanks.

 boucher@ug.cs.dal.ca

Xref: sparky comp.lang.fortran:3072 general:104
From: marshall@marshall.cs.unc.edu (Jonathan A. Marshall)
Newsgroups: comp.lang.fortran,general,help
Subject: Unix ARGC,ARGV in Fortran 77
Date: 18 Aug 92 01:39:07 GMT
Followup-To: comp.lang.fortran
Organization: The University of North Carolina at Chapel Hill

I need to write a Fortran program that will accept command-line arguments.
I'm running Ultrix f77 on a DECstation 5000.  In C, command-line arguments
can be passed with argc and argv.

How is this done in f77?  There's got to be a way, right?

Thanks!

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
=                                                                       =
=   Jonathan A. Marshall                          marshall@cs.unc.edu   =
=   Department of Computer Science                                      =
=   CB 3175, Sitterson Hall                                             =
=   University of North Carolina                  Office 919-962-1887   =
=   Chapel Hill, NC 27599-3175, U.S.A.               Fax 919-962-1799   =
=                                                                       =
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
From: sandee@Think.COM (Daan Sandee)
Newsgroups: comp.lang.fortran
Subject: Re: programming style question
Date: 12 Aug 1992 20:13:25 GMT
Organization: TMC
NNTP-Posting-Host: telecaster.think.com

In article <1992Aug12.193739.23817@news.Hawaii.Edu>, tholen@galileo.ifa.hawaii.edu (Dave Tholen) writes:
|> If OPENing standard output, what good is trapping an ERR= condition,
|> because there is no output device to which an error message can be
|> written?  Of course, one could use the STOP 'Error message here'
|> construct to get around this problem.  

In some implementations, a STOP statement is written to stdout *and* stderr.
Hopefully, an error on preconnecting stdout and stderr will be handled
gracefully by the system. But I wouldn't advise a STOP message if you find
a problem on stdout.

You can write an error message to any file (stderr is the obvious first
choice). Normally, this would occur if stdout is redirected to a file and
(a) the file is write protected or (b) the device is full (or something).
More interesting is when you get an error on writing to stderr. Then there
is no obvious solution.

Daan Sandee                                           sandee@think.com
Thinking Machines Corporation
Cambridge, Mass 02142                                 (617) 234-5044
From: lapoint@adios.brl.mil (Claude LaPointe )
Newsgroups: comp.lang.fortran
Subject: RE: programming style question
Date: 14 Aug 92 12:25:59 GMT


tholen@galileo.ifa.hawaii.edu (Dave Tholen) writes:


  >  A question about programming style:  How many of you explicitly OPEN
  >  preconnected units, which nowadays usually mean standard input, standard
  >  output, and sometimes standard error (typically units 5, 6, and 0)?  In
  >  the old days, 5 and 6 were often card reader and printer.  I haven't
  >  been doing so myself, but the question came up recently because I've
  >  ...


Given that 0,1,2,5,6 and probably others are highly non-portable
ways of addressing standard in, out, and error. It is better not to
use them.

Because the 77 standard didn't much consider the kinds of output
capabilities now available, it didn't address standard error,
so there is no choice but to use a unit number - however it should
be done with the realization that porting may require a change in the
value. That is, isolate its use as much as possible in a subprogram
and define it with a parameter statement.

With respect to standard in & out use "*" which must not appear in
OPEN and CLOSE statements.

Some time ago, an objection was raised to this on the basis that the
"*" must be present at compile time, and so cannot be passed as an
argument. Actually, it can, but clumsily. When the intent is to write
to standard out, set the calling argument not to "*" but to some
negative integer. Similarly for input.


      subroutine out (unit)
      integer unit
      ...
      if (unit.lt.0) then
         write (*,...
      else
         write (unit,...
      endif
      ...
From: sow@cad.luth.se (Sven-Ove Westberg)
Newsgroups: comp.lang.fortran
Subject: CASE tools for re-enginering.
Date: 20 Aug 92 11:03:27 GMT
Reply-To: Sven-Ove Westberg <sow@cad.luth.se>
Organization: University of Lulea, Sweden


Hi all.

I am interested in CASE tools that can do good static analysis of
old fortran programs. Such as call trees, where variables can be
used and set (also for the case where the variables in the common
block have diffrent names in diffrent routines)

I am intrested in any information on this kind of softare both commersial
and publicdomain.


Sven-Ove Westberg, CAD, University of Lulea, S-951 87 Lulea, Sweden.
Tel:     +46-920-91677  (work)                 +46-920-48390  (home)
From: dcuddihy@nmt.edu (David Cuddihy)
Newsgroups: comp.lang.fortran
Subject: Ultrix Fortran alternatives?
Date: 11 Aug 92 21:01:01 GMT
Organization: New Mexico Tech


	We are currently running with the Fortran that came with the Ultrix 4.2
release and we have had troubles with inconsistencies, for example code that
runs on our Suns, miscellaneous workstations at other sites, supercomputer
machines, etc... don't compile or have slightly different functionality on
the Ultrix f77(and occasionally vice-versa).
	Since we are trying to write generic code, we aren't too interested in
how to get it to run on the Ultrix(and hence not on all of the other machines)
Instead we were wondering what other Fortran compilers there are out there...
(If there was something public domain that could be imported via ftp, that'd
be ideal!)


				Thanks in advance,
					-Dave
Xref: sparky comp.lang.fortran:2997 comp.lang.c:12229
From: robichau@lambda.msfc.nasa.gov (Paul Robichaux)
Newsgroups: comp.lang.fortran,comp.lang.c
Subject: Moving from FORTRAN to C: supporting or porting?
Date: 12 Aug 92 18:58:59 GMT
Reply-To: robichau@lambda.msfc.nasa.gov
Organization: New Technology, Inc.

The system I'm helping to develop here at Marshall includes a facility for
letting scientists/principal investigators (our users) build
C-language computations that ingest spacecraft telemetry, do some type
of calculations, and do something with the result.

Our system is a workstation & POSIX-based follow-on to the current VAX
VMS implementation. The current system allows user comps to be written
(naturally) in FORTRAN.

The problem is this: our requirements document specifically requires
C, and it also requires grandfathering _all_ capabilities of the
current system.

We have two options: make all the current users port their stuff once,
and disallow further use of FORTRAN, or support both languages. Each
approach has its advantages and disadvantages, not all of which we've
though of.

I'm looking for {success | horror | war} stories about this sort of
problem. We _have_ to support both languages, but no one's defined
what "support" means in this context.

Please reply via posting; replies via e-mail will be summarized.

Thanks,
-Paul

-- 
Paul Robichaux, KD4JZG          | I shouldn't bitch / I shouldn't cry
robichau@lambda.msfc.nasa.gov   | I'd start a revolution but I don't have time.
Newsgroups: comp.lang.fortran
From: lindquiste@wl.aecl.ca
Subject: RE: Fortran to C conversion.
Organization: AECL RESEARCH
Date: Mon, 17 Aug 1992 19:33:55 GMT

There seems to be an increasing number of people wanting to go from Fortran
to C, as I do. As it seems you have found such a utility I was wondering if you would send the address from which I might be able to down load the f2c utility.

As I am not terribly familiar with this NEWS E-mail Utility any extra help you
might be able to send along would be appreciated, even comments on how the
conversions have gone....

Thanks

edl
Erik Dean Lindquist
AECL - Whiteshell Labs

Have a Great Day!
Newsgroups: comp.lang.fortran,slac.lang.fortran
From: cflatter@nrao.edu (Chris Flatters)
Subject: Re: What is the name of the latest Fortran stan
Reply-To: cflatter@nrao.edu
Organization: NRAO
Date: Fri, 14 Aug 1992 16:02:17 GMT

In article 21922@bnr.ca, davisonj@bnr.ca (John Davison) writes:
>
>        I am sitting here with Draft S8, Version 112 of S8 (X3.9-198x), also
>known as X3J3/S8.112, and I am wondering if this document actually represents
>the new Fortran.  (I doubt it, since it appears that this is an "8x" thing and
>not a "90" thing, but I don't know a whole lot about the last few years'
>evolution of the proposed Fortran standards.)
>
>        Would some nice person tell me whether this document was adopted
>without revision by ANSI and ISO, or if this document is useless, or something
>like that?

S8.112 was the last but one draft that went out for public review.  The last
version to be publically distibuted before approval was S8.115 with several
pages of changes (Document X3J3/S9).  S8.115 was adopted with minor changes.
Apart from the fact the S8.115 contains more explanatory material there
is little substantive change between S8.112 and S8.115.

	Chris Flatters
	cflatter@nrao.edu

Newsgroups: comp.lang.fortran
From: pm@katz.cc.univie.ac.at (Peter Marksteiner)
Subject: Re: programming style question
Organization: Vienna University Computer Center
X-Newsreader: Tin 1.1 PL4
Date: Thu, 13 Aug 1992 08:10:49 GMT

ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig) writes: 


>It's a real shame that Unix does not have standard way of attatching
>FORTRAN units to file descriptors, that would make things much easier.
>Does POSIX have anything to say about that?

Try symbolic links. For example,

    ln -s /whatever/pathname/you/want fort.3

may not be as beautiful as

//FT03F001  DD  DSN=REVOLTING.MVS.DATASET,DISP=NEW

but it works almost as well. (Unless you have one of those rare Unix
machines where the default names of undeclared Fortran files are not 
fort.1, fort.2, ...)

                     Peter Marksteiner
                     pm@katz.cc.univie.ac.at
                     Vienna University Computer Center
Newsgroups: comp.lang.fortran