HDTenEightyP/NetNews huggingface dataset:
From: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Subject: Re: Compiler groups working on real apps?
Reply-To: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Organization: MRL - UIUC
Date: Tue, 26 Jan 1993 04:51:00 GMT

In article <1993Jan25.171227.10633@news.eng.convex.com> Patrick F. McGehearty (patrick@convex.COM)
writes:
|>[...] I understand the Perfect Group is actively seeking such benchmarks.
|>If they adopt a benchmark and put it in their suite, it will gain instant
|>credibility with a number of vendors.  For contact info on the Perfect
|>Group, see the FAQ in comp.benchmarks.

In article <1993Jan25.171544.14680@craycos.com>, jrbd@craycos.com (James Davies) writes:
|>[...]  For what it's worth, the
|>Perfect Club suite is a collection of application programs that was supposed
|>to avoid compiler cheating, and also help advance compiler technology by
|>encouraging sharing of techniques, but since the results don't boil down to a
|>single number that can be easily quoted by marketroids most everyone basically
|>ignores it.  Perfect includes one code that is a molecular-dynamics
|>simulation (MDG).

Ach! Another thing to look at!!!  :-) 

--
furio ercolessi    <furio@uiuc.edu>*    <furio@sissa.it>+
* materials research lab, uni illinois at urbana-champaign
+ intl school for advanced studies, trieste, italy   

"Change nothing and continue with immaculate consistency"
                                      [ Brian Eno, "Oblique Strategies" ]
Organization: Queen's University at Kingston
Date: Thu, 21 Jan 1993 23:40:38 EST
From: <MATOVICM@QUCDN.QueensU.CA>
Newsgroups: comp.lang.fortran
Subject: Re: Gaussian Elimination

Try research.att.com site, in the netlib directory. Also, check by archie
where else you can find netlib. It's fairly large collection of math
LIBRARIES! (all in source code). I guess 50+ Mb of code! Enjoy.

Darko
From: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Newsgroups: comp.lang.fortran
Subject: Re: compiling FORTRAN IV on Unix f77
Date: 27 Jan 93 21:17:22 GMT
Reply-To: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Organization: MRL - UIUC

In article <1k6e6cINNmqo@bigboote.WPI.EDU>, bugsy@yoyodyne.WPI.EDU (Christopher Sean Moran) writes:
|>Help me... I have a program called VORLAX which I need to compile.
|>It was written and compiled originally on CDC FORTRAN IV.  All
|>I have access to is Unix f77.  I have tried to compile it, but
|>its a no go.  One problem is the first line
|>
|>PROGRAM VORLAX(INPUT,OUTPUT, etc)
|>
|>the compiler doesnt like the parenthesis after the program 
|>declaration.  Past that there are no other problems.

Ah, good old days!  The parenthesis above were a CDC extension
providing a sort of i/o redirection.  You could run the program by
something like
VORLAX,FOO,BAR.
which worked as vorlax < foo > bar would work on Unix.
But you could redirect many files with arbitrary fortran unit
numbers.

|>I do get an executable after compiling if I take the stuff
|>in the parenthesis out. But UNIX dumps my core every time
|>I run the program.  Can anyone help me?

As opposed to Fortran 90 vs Fortran 77, Fortran 77 is not downward 
compatible with Fortran 66 (CDC's FORTRAN IV is Fortran 66).
In particular, DO loops behave in a different way, and in Fortran 66
they are *always* executed at least once. So that
      A=0.
      DO 100 I=2,1
      A = A + 1.
100   CONTINUE
      B = B/A
would run fine with Fortran 66 but dump your core with Fortran 77.
Many compilers have an option to force the old-style behavior; look
for -onetrip or something like that.

Of course, your program may dump for other reasons.  The CDC was
a 60 (sic) bits machine using a 6-bit (ugh) character set, not ASCII,
so the potential for breakdowns related to COMMONs, EQUIVALENCEs,
characters stored in reals ... etc are huge.  I would suggest to check
accurately everything dealing with character manipulation.  As in
Fortran 66 there was no CHARACTER type, this is kinda fun. :-)
Good luck!
furio  
--
furio ercolessi    <furio@uiuc.edu>*    <furio@sissa.it>+
* materials research lab, uni illinois at urbana-champaign
+ intl school for advanced studies, trieste, italy   

"Change nothing and continue with immaculate consistency"
                                      [ Brian Eno, "Oblique Strategies" ]
From: yhchen@eng.umd.edu (Yin-Hsin Chen)
Newsgroups: comp.lang.fortran
Subject: Re: Maximum number of openfiles on MS FORTRAN 5.1?
Date: 25 Jan 1993 04:04:35 GMT
Organization: Project GLUE, University of Maryland, College Park
NNTP-Posting-Host: coffee.eng.umd.edu

In article <1993Jan24.174628.1@afit.af.mil> cwillits@afit.af.mil writes:
>
>According to Appendix C of the _Microsoft FORTRAN Reference_, a program written
>in MS FORTRAN 5.1 and run under DOS or OS/2 cannot open more than 20 files at a
>time.  (Under certain situations involving OS/2, this can be extended to 40.)
>
>Another poster referred to changing the "FILES=" line in CONFIG.SYS.  Setting
>this limit to more than 20 has no effect on the MS FORTRAN limit of 20 open
>files.
> 
 There are two parts that affect the open files. One is on DOS side.
You can increase this part by changing the "FILES=" line in
CONFIG.SYS. The second part is on MS FORTRAN side. According to MS
FORTRAN 4.1 & 5.0, some assembly code must be changed to increase the
limit. Sorry I never use MS FORTRAN 5.1. Under DOS, I ever increased
the open files to 40+. I cannot open more files under DOS. But under
OS/2 1.0, I can increase the open files to 60+. Because this was what
I need at that time, I don't know the limit. Again, this is for MS
FORTRAN 5.0, not 5.1. But I don't think the number of the open files
will decrease.

>Craig J. Willits
>Graduate Student, Operations Research
>Air Force Institute of Technology
>cwillits@afit.af.mil


Newsgroups: comp.lang.fortran
From: cwillits@afit.af.mil
Subject: Re: Maximum number of openfiles on MS FORTRAN 5.1?
Organization: Air Force Institute of Technology
Date: Sun, 24 Jan 1993 12:46:28 GMT

In article <Jan.22.09.43.13.1993.26857@gandalf.rutgers.edu>, 
hempatel@gandalf.rutgers.edu (Hemanshu Patel) writes:
> 
> 	I am using MS Fortan 5.1 on a PC running DOS, and I've written 
> 	a program on a SPARC 1 which opens 20 or so files. It compiles
> 	and runs fine.  I then transfered it to a PC, it compiles fine
> 	but I  get a runtime  error of  too many files opened. I don't 
> 	remember the  exact error code. Does  anyone know  the maximum 
> 	number of files openable at one time under MS Fortran 5.1, and
> 	any tricks around. I really don't want to  open and close each 
> 	file every time,  especially since the data  stored in them is 
> 	sequentially  written. Any help  would be appreciated. Than...
> 
> 	Hemanshu

According to Appendix C of the _Microsoft FORTRAN Reference_, a program written
in MS FORTRAN 5.1 and run under DOS or OS/2 cannot open more than 20 files at a
time.  (Under certain situations involving OS/2, this can be extended to 40.)

Another poster referred to changing the "FILES=" line in CONFIG.SYS.  Setting
this limit to more than 20 has no effect on the MS FORTRAN limit of 20 open
files.
 
Craig J. Willits
Graduate Student, Operations Research
Air Force Institute of Technology
cwillits@afit.af.mil
Organization: Queen's University at Kingston
Date: Sat, 23 Jan 1993 21:07:54 EST
From: <MATOVICM@QUCDN.QueensU.CA>
Newsgroups: comp.lang.fortran
Subject: Re: dbx headache
 <1993Jan22.135940.9828@msdrl.com> <1993Jan22.171934.15193@midway.uchicago.edu>

Thanks a lot to all the people that bothered to respond. At least I know now
that my headache is real, because the responses seem to point somewhere in the
future (if FORTRAN lives long to see it?), with the exception of the dbx fea-
ture offered on the SPARC, but, then, I work on SGI for the time being.

I think I could have the solution in principle, but I couldn't make it work.
Here is the idea:
    DBX allows interactive function (and in FORTRAN, subroutine) calls from
within debugger, if this function/subroutine is linked with the program. This
way, I managed to incorporate a routine that dumps all my data in the output
files whenever a want it. I simply enter
       ccall mywrite
Than using other (simple) program I examine that database. This whole thing
would work MUCH better if I were able to pass the arguments to the subroutine
or function call. So far, I've been trying... The problem is that dbx requests
C calling conventions even for the FORTRAN debuging, and I couldn't match these
conventions so far. I've tried to reverse the order of arguments, to compile
the C routine (just the one to print data) using mkf2c interface, than assemb-
ler, and all I managed is to drive my frustration up. Anybody out there that
could add to this?

Darko Matovic
From: kroeker@oc1.oc.chemie.th-darmstadt.de (Martin Kroeker)
Newsgroups: comp.lang.fortran
Subject: IAND(I,J) IOR(I,J) ???
Date: 24 Jan 1993 21:06:08 GMT
Organization: Technical University, Darmstadt, Germany
Distribution: world
NNTP-Posting-Host: oc1.oc.chemie.th-darmstadt.de

Could somebody please point me to a fortran source code that provides the
functionality of the non-standard functions IAND, IOR, IEOR and BTEST ?
I am trying to port a database application from a soon-to-be-junked IBM
mainframe to a workstation where the fortran compiler is in fact f2c, and my
own attempts at these bit-handling functions have failed miserably.
Thanks in advance,
Martin
-- 
Dipl.Ing Martin Kroeker                   kroeker@oc1.oc.chemie.th-darmstadt.de
Inst. f. Organ. Chemie                    martin@oc2.oc.chemie.th-darmstadt.de
Univ. (TH) Darmstadt                           db7p@mvs.hrz.th-darmstadt.de
Germany                                     (in real life: <not determined> )
Newsgroups: comp.lang.fortran
From: shen@athena.cs.uga.edu (Mingzuo Shen)
Subject: intrinsic function for the imaginary part and conjugate?
Organization: University of Georgia, Athens
Distribution: usa
Date: Thu, 21 Jan 1993 21:24:30 GMT

Hi all,

    Metcalf's book (Effective Fortran, 1985) has a list of
intrinsic functions. Among them, the intrinsic function for
obtaining the imaginary part of a complex number is AIMAG,
which makes sense. However, there is no intrinsic function
for obtaining the real part of a complex number?

    More seriously(?), the instrinsic function for complex
conjugate is also AIMAG? I am sure this is a typo or something.
Please help via e-mail. Thanks in advance.

Mingzuo Shen

Newsgroups: comp.lang.fortran
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: IAND,IOR... - Thank you
Organization: Los Alamos National Laboratory
Date: Tue, 26 Jan 1993 19:08:31 GMT

In article <1k1dcdINNpm3@rs2.hrz.th-darmstadt.de>, kroeker@oc1.oc.chemie.th-darmstadt.de (Martin Kroeker) writes:
|> Many thanks to all who responded to my query about coding non-standard
|> bit manipulation functions in fortran, especially to Eric Haug, who provided
|> the simple (ouch !) solution in C:
|> long btest (long *a, long *b)
|>            return(*a>>*b);

This is clearly an incorrect solution.  Suppose the first argument is
eight and the second is one, this version of btest returns four - which
is *not* the value of the bit addressed by the second argument in either
big- or little-endian bit numbering.  In little-endian, the following
operation would be correct:

  long btest (long *a, long *b)
             return(*a>>*b & 1);

|> After my plea for help I had finally found a clumsy solution in fortran, but
|> this one naturally beats it easily.

I've never run across a Fortran implementation which did not have 
these as operations as either intrinsic functions or operators which 
are inlined and which use the hardware instructions (if the hardware 
has them) to perform these operations.  A glance at the document for 
your particular Fortran implementation would probably have revealed a 
non-clumsy Fortran solution.  Certainly it's less clumsy to use a
implementation defined extension to Fortran than to rely on C (the
interface to which is also implementation defined and not portable).

-- 
J. Giles
From: sarachanbd@crd.ge.com (B. D. Sarachan)
Newsgroups: comp.lang.fortran
Subject: Re: fortran for Mac
Date: 28 Jan 93 19:52:09 GMT
Reply-To: sarachanbd@crd.ge.com (B. D. Sarachan)
Distribution: usa
Organization: GE Research & Development Center

In article <C1KpqB.D0J@cs.columbia.edu>, guapo@cs.columbia.edu (J. Robert Diana) writes:
|> 
|> Is there any fortran compiler for the mac?
-- 
The best is probably Language Systems Fortran, which runs under the Macintosh Programmer's
Workshop (MPW).  LS Fortran together with MPW costs $595 and is available from APDA.
(You can get a free APDA catalog by calling 1-800-282-2732.)

I don't believe that you need an FPU to use LS Fortran.

==
  sarachanbd@crd.ge.com

  Brion Sarachan
  GE Research & Development
  P.O. Box 8, Rm. KW-C273
  Schenectady, NY 12301

  Tel. (518) 387-6553
  Fax  (518) 387-7080

Please note that the "Standard Disclaimer" applies here.
Newsgroups: comp.lang.fortran
From: thodges@beta.tricity.wsu.edu (Tom Hodges)
Subject: Re: Maximum number of openfiles on MS FORTRAN 5.1?
Organization: Washington State University
Date: Sun, 24 Jan 93 19:52:53 GMT


Newsgroups: comp.lang.fortran
From: Patrick F. McGehearty <patrick@convex.COM>
Subject: Re: Compiler groups working on real apps?
Originator: patrick@wagner.convex.com
Date: Mon, 25 Jan 1993 17:12:27 GMT
Reply-To: patrick@convex.COM (Patrick F. McGehearty)
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

In article <C1Cnq5.1zt@news.cso.uiuc.edu> ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi) writes:
...comments suggesting that Livermore Loops do not contain interesting
...representatives of his type of applications (classical molecular
...dynamics), partly due to lack of use of the indirect addressing
...coding technique.

I consider the Livermore Loops a necessary but not sufficient test of
compiler code generation quality.  I suspect one reason why it does not
contain much indirect addressing is that most codes from which the loops
were selected were developed in the 1970's and before.  Architectures
were different, problem sizes were smaller, etc, etc.  At time passed
we (the computing community) evolve different approaches, so our commonly
used benchmarks need to evolve and expand also.  I would welcome some
meaningful kernel benchmarks of indirect addressing.

Ideally, such a benchmark would contain:
1) Source code in reasonably portable Fortran (so we are all looking at the
same thing)
2) Information about whether the different elements of the indirectly
addressed arrays are independent (very important for adding compiler
directives to allow vector or parallel execution.
3) Several data sets for evaluating the benchmark
  The data sets should have the following characteristics
  a) A small data set which executes quickly on the slowest machine the
	application is interested in (say a second or two on a current 20
	Mips, 20 Mflops box)
    This data set is useful to the compiler developers for basic correctness
    testing, and for the architectural simulator people for studying new
    architectures.
  b) A medium data set which executes in not more than a few hours on the
	slowest machine of interest.
  c) A large data set which is large enough to properly stress architectural
	features such as cache, large numbers of processors, communication
	latencies, etc, etc.
For an indirect addressing benchmark particularly, the pattern of memory
accesses should fairly represent production environment data sets so future
systems will be tuning to maximize real data sets, not some artifically
simplified data set.  An extreme example of a bad data set would be one
where each indirect address was at a successive location in memory.

I understand the Perfect Group is actively seeking such benchmarks.
If they adopt a benchmark and put it in their suite, it will gain instant
credibility with a number of vendors.  For contact info on the Perfect
Group, see the FAQ in comp.benchmarks.
From: RKOHLBUS@jennifer.umd.edu (Robert C. Kohlbus)
Newsgroups: comp.lang.fortran
Subject: Translator
Date: 22 Jan 93 20:59:19 GMT
Organization: University of Maryland


	Question : Is there a convertor(translator) that converts either
pascal or C to Fortran?  Please respond via e-mail.  Thanks.

=========================================================================

Robert Kohlbus
University of Maryland
Network Admin. / Computer Programmer
Internet:
    rkohlbus@jennifer.umd.edu
    kohlbus@wam.umd.edu

=========================================================================
Newsgroups: comp.lang.fortran
From: lionel@quark.enet.dec.com (Steve Lionel)
Subject: Re: Fast I/O
Reply-To: lionel@quark.enet.dec.com (Steve Lionel)
Organization: Digital Equipment Corporation, Nashua NH
Date: Thu, 21 Jan 1993 14:15:03 GMT


In article <1993Jan21.081105.4047@molene.ifremer.fr>, 
molagnon@ditigo.ifremer.fr (Michel Olagnon) writes:
|>
|>Many Fortran compilers are not efficient on I/O with implied DO loops.
|>Replacing 
|>      write (lu) (a (j), j=1,n)
|>with
|>      call fstwrt (lu, a, n)
|>         .
|>         .
|>      subroutine fstwrt (lu, a, n)
|>      double precision a (n)
|>      write (lu) a
|>      return
|>usually gives dramatic improvement.
|>
|>I have a follow-up question : why don't compilers execute this optimization ?
|>

Digital's VAX FORTRAN does.  It also optimizes some more complex implied
DO-loops, including those with non-unity strides and with expressions in
the array subscript, as long as it can tell that the stride is constant.
If the stride is 1, the I/O operation occurs directly from the array memory
rather than being copied to a buffer.
--

Steve Lionel                    lionel@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
From: kroeker@oc1.oc.chemie.th-darmstadt.de (Martin Kroeker)
Newsgroups: comp.lang.fortran
Subject: IAND,IOR... - Thank you
Date: 25 Jan 93 19:00:29 GMT
Organization: Technical University, Darmstadt, Germany
NNTP-Posting-Host: oc1.oc.chemie.th-darmstadt.de

Many thanks to all who responded to my query about coding non-standard
bit manipulation functions in fortran, especially to Eric Haug, who provided
the simple (ouch !) solution in C:
long btest (long *a, long *b)
           return(*a>>*b);
long iand (long *a, long *b)
           return(*a & *b);
long ior (long *a, long *b)
           return(*a | *b);
After my plea for help I had finally found a clumsy solution in fortran, but
this one naturally beats it easily.
Martin (who promises to try harder next time :-) )
-- 
Dipl.Ing Martin Kroeker                   kroeker@oc1.oc.chemie.th-darmstadt.de
Inst. f. Organ. Chemie                    martin@oc2.oc.chemie.th-darmstadt.de
Univ. (TH) Darmstadt                           db7p@mvs.hrz.th-darmstadt.de
Germany                                     (in real life: <not determined> )
Newsgroups: comp.lang.fortran
From: guapo@cs.columbia.edu (J. Robert Diana)
Subject: fortran for Mac
Summary: fortran compiler for mac(commercial or shareware)
Organization: Columbia University Department of Computer Science
Date: Thu, 28 Jan 1993 16:56:34 GMT


Is there any fortran compiler for the mac?  I need to learn fortran eventually
and I will not have acces to a network by that time and I own a Mac LCII.
Are there any commercial or shareware compilers out there?  If so, where?
I do not have an FPU either and I know this has been a problem with other
compilers/interpreters.  Thanks.


Rob Diana
From: pln@egret0.Stanford.EDU (Patrick L. Nolan)
Newsgroups: comp.lang.fortran
Subject: Re: How to get command line arguments from unix with FORTRAN?
Date: 25 Jan 1993 22:24:21 GMT
Organization: Stanford University
Reply-To: pln@egret0.Stanford.EDU
NNTP-Posting-Host: egret1.stanford.edu
X-Newsreader: TIN [version 1.1 PL6]

Peter Kocks (kocks@leland.Stanford.EDU) wrote:
: 
: Subject says all.
: 
: Can someone tell me how to read the command line arguments of
: a unix command line from with FORTRAN.  Something presumably similar
: to the c
: 
: main(int argc, char **argv){
: }
: 
It probably varies with the flavor of unix.  On a Sun, you have:

GETARG(3F)          FORTRAN LIBRARY ROUTINES           GETARG(3F)
 
NAME
     getarg, iargc - get the kth command line argument
 
SYNOPSIS
     subroutine getarg ( k, arg )
     character*(*) arg
 
     function iargc ()
 
DESCRIPTION
     The statement call getarg( k  ,  arg  )  will  get  the  kth
     command-line argument and put it into arg .
 
     The 0th argument is the command name.
 
     The function iargc returns the index of  the  last  command-
     line argument,
     and therefore the number  of  arguments  after  the  command
     name.

--
*   Patrick L. Nolan            (415)723-0133                 *
*   W. W. Hansen Experimental Physics Laboratory (HEPL)       * 
*   Stanford University                                       *
*   Bitnet: PLN@SLACVM    Internet: pln@egret0.stanford.edu   *
Newsgroups: comp.lang.fortran
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: Fast I/O
Organization: Los Alamos National Laboratory
Date: Fri, 22 Jan 1993 18:10:29 GMT

In article <1993Jan21.081105.4047@molene.ifremer.fr>, molagnon@ditigo.ifremer.fr (Michel Olagnon, Ifremer DITI GO, 98.22.41.44) writes:
|> [...]
|> Many Fortran compilers are not efficient on I/O with implied DO loops.
|> Replacing 
|>       write (lu) (a (j), j=LO,HI)		![generalize your case a bit]
|> with
|>       call fstwrt (lu, a(LO), HI-LO+1)	![similar generalization]
|>          .
|>          .
|>       subroutine fstwrt (lu, a, n)
|>       double precision a (n)
|>       write (lu) a
|>       return
|> usually gives dramatic improvement.
|> 
|> I have a follow-up question : why don't compilers execute this optimization ?

I asked Cray for something similar to this more than 5 years ago.
In fact, they actually had an interface to the I/O library defined
which not only passed the array and the length, but the stride as
well.  This would have permitted buffered I/O for even strided
data to run as fast as the example you gave.  (It doesn't help
unbuffered I/O unless the stride is exactly one - in which case
you get the same thing as you just posted.)  For some reason,
even though Cray had the interface defined and the hooks in the
compiler to implement it, they never did.  I estimated that it
would have sped some I/O bound code by several times.

The reason for the speedup is that most implementations compile
the implied loop into a tight loop around the I/O library call.
The above made a separate trip through the I/O routines for each
element of the array.  The whole-array write only takes a single
trip through the library for the whole array.  The call/return 
overhead often dominates for I/O on single elements.

-- 
J. Giles
From: shepard@sampson.ccsf.caltech.edu (Ron Shepard)
Newsgroups: comp.lang.fortran
Subject: Re: compiling FORTRAN IV on Unix f77
Date: 27 Jan 93 21:01:32 GMT
Organization: California Institute of Technology, Pasadena
NNTP-Posting-Host: sampson.ccsf.caltech.edu

In article <27JAN199311453903@almach.caltech.edu> shoppa@almach.caltech.edu
(TIM SHOPPA) writes:
[text deleted]
>	A useful package for finding things like this is "FLINT", which
>unfortunately is not (as far as I know) a public-domain program.  It's like
>C's "lint", but instead for Fortran.  Does anyone know of a similar
>product which *is* public-domain?

You might try the ftnchek program available from netlib.

Is there reference to ftnchek in the FAQ?  If not, it might be worth adding.

-Ron Shepard
shepard@tcg.anl.gov