HDTenEightyP/NetNews huggingface dataset:
From: jordan@aero.org (Larry M. Jordan)
Newsgroups: comp.lang.modula2
Subject: Re: LATERST VERSION FST M2
Date: 21 Jan 1993 21:34:13 GMT
Organization: The Aerospace Corporation
NNTP-Posting-Host: daystrom.aero.org

In article <39923.2B5E1A55@puddle.fidonet.org> Greg.Vigneault@puddle.fidonet.org (Greg Vigneault) writes:
>AR> Could anyone tell me what the latest version of FST M2 is? I
>  > currently have version 2.0 which if from 1998!
>
> The latest FST Modula-2 version is 3.1  It adds OOP.
>

Greg,

Could you give a short description (syntax and semantics) of the
OOP extension.  Some things I'd like to know:

o module type or record extenstion

o single or multple inheritance 

o only 'virtual' methods (like Oberon-2) or
  virtual and non-virtual (like C++)

o syntax



--Larry Jordan
From: Sean.Wilson@f590.n139.z1.fidonet.org (Sean Wilson)
Newsgroups: comp.lang.modula2
Subject: JPI Compiler bug?
Date: Thu, 21 Jan 93 11:17:52 PDT
Organization: FidoNet node 1:139/590 - PMI BBS, Green Bay WI


MO>   Here`s a question for networked JPI-supporters:

MO>   We tried to `overload` the NEW-procedure by implementing the module

MO>   DEFINITION MODULE XStorage;

MO>   FROM SYSTEM IMPORT ADDRESS;

MO>   BEGIN

MO>   ...

MO>   PROCEDURE NEW ( VAR adr : ADDRESS );
MO>   BEGIN
MO>      ALLOCATE( adr, SIZE(adr^) );
MO>   END NEW.

MO>   END XStorage.


MO>   Our intention was to avoid substituting NEW-calls in a number of source-MO>   files by ALLOCATE() calls. This doesn`t work, because the compiler MO>   allocates 4 bytes of memory, although the amount of x bytes, required MO>   for the data structure adr points at, should be allocated, eg.

MO>   TYPE
MO>      RecordPtr = POINTER TO Record;
MO>      Record    = RECORD
MO>                     str : ARRAY [0..79] OF CHAR;
MO>                     int : INTEGER;
MO>                  END;

MO>   XStorage.NEW( adr ) allocates 4 bytes of memory. An explicit MO>   ALLOCATE()-call works.


MO>   Got the point?

MO>   Marcus

This isn't a compiler bug, overloading NEW() cannot be done in this way. When the compiler encounters a call to NEW() it will normally expand this to a call of the form:

        ALLOCATE(adr, SIZE(adr^));

as you have determined.  In order for this to work, the compiler must have information about the type of the variable in the NEW() call.  This size information is not passed to your overloaded NEW().

The solution is to overload not the NEW() procedure but the ALLOCATE() and DEALLOCATE() procedures.  Since these are not compiler generated you can be sure of getting all the relevant information, you can then do whatever you like in your own code.  e.g:

DEFINITION MODULE XStorage;

PROCEDURE ALLOCATE(VAR adr: ADDRESS; len: CARDINAL);
PROCEDURE DEALLOCATE(VAR adr: ADDRESS; len: CARDINAL);

END XStorage.

IMPLEMENTATION MODULE XStorage;

  IMPORT Storage;

PROCEDURE ALLOCATE(VAR adr: ADDRESS; len: CARDINAL);
BEGIN
  (* ... *)
  Storage.ALLOCATE(adr, len);
  (* ... *)
END ALLOCATE;

PROCEDURE DEALLOCATE(VAR adr: ADDRESS; len: CARDINAL);
BEGIN
  (* ... *)
  Storage.DEALLOCATE(adr, len);
  (* ... *)
END DEALLOCATE;

END XStorage.


MODULE Tst;

  FROM XStorage IMPORT ALLOCATE, DEALLOCATE;
(* The above line replaces the following line in your code.     *) (* FROM Storage IMPORT ALLOCATE, DEALLOCATE;                    *)


  TYPE
    RecordPtr = POINTER TO Record;
    Record    = RECORD
      str : ARRAY [0..79] OF CHAR;
      int : INTEGER;
    END;

  VAR
    rec : RecordPtr;
BEGIN
  (* In the following call the compiler still generates a call  *)
  (* to ALLOCATE, but this is resolved by XStorage.ALLOCATE     *)
  (* rather than Storage.ALLOCATE.                              *)
  NEW(rec);
END Tst.

Best regards
  Sean.

___
 X PQ-Under-Trial 2.15 X If you ain't got it then you ain't communicatin'.


--  
uucp: uunet!m2xenix!puddle!139!590!Sean.Wilson
Internet: Sean.Wilson@f590.n139.z1.fidonet.org
Newsgroups: comp.lang.modula2
From: robart@agora.rain.com (Joe Bob)
Subject: Re: pascal code to modula
Organization: a gora
Distribution: world 
Date: Mon, 25 Jan 1993 10:34:26 GMT

In article <cspt.62.727781974@giraffe.ru.ac.za> cspt@giraffe.ru.ac.za (Prof. P. Terry) writes:
>(like some folks are going to believe ISO M-2 is Modula-2?)


  You seem to be implying that you think ISO M-2 will be a step backwards.
In what ways is this the case?  (I haven't seen any draft specs since the
one of Jan 1 1990).

Newsgroups: comp.lang.modula2
From: randy@psg.com (Randy Bush)
Subject: Re: pascal code to modula
Organization: Pacific Systems Group, Portland Oregon, US
Date: Fri, 22 Jan 1993 16:35:33 GMT

csfraw@vehka.cs.uta.fi (Francis Akoto) writes:
> This is a pascal code
>    i,j: integer ;
>    i := i or j ;

That most certainly is *not* Pascal code.

If you are trying to achieve a bitwise inclusive OR of the two integers, then
you would have to go through tagless variant records in a dirty hack.

To do this in Modula-2, one would do something like

    VAR i, j : INTEGER;
    i := INTEGER ( BITSET(i) OR BITSET(j) )

randy
-- 
randy@psg.com   ...!uunet!m2xenix!randy
Date: Fri, 22 Jan 1993 05:04:00 CET
From: marcus_olk@cl-hh.comlink.de
Reply-To: marcus_olk@cl-hh.comlink.de
Distribution: world
Newsgroups: comp.lang.modula2
Subject: re: Re: JPI Compiler bug?
Organization: Freies Telekommunikations-Zentrum Hamburg e.V.
Content-Length: 768     
X-Gateway: NETCALL3.8 UC xclhh.comlink.de [UZERCP V3.99d]

ROBART%AGORA.RAIN.COM@UUCP.ZER wrote in a message as of 20.01.93 12:24 Uhr:

> Since adr is of type ADDRESS, adr^ is of type WORD, so you allocate
> TSIZE(WORD), which with this compiler is evidently 4.

But what does adr^ mean? adr^ should be the referenced type adr points
at. This might be a RECORD structre or an ARRAY or...

So: what does NEW(adr) or ALLOCATE(adr, SIZE(adr^)) respectively, exactly do?

Marcus

--
 Marcus Olk        # Internet: olk@informatik.uni-hamburg.de
 Schwalbenweg 9a   #           marcus_olk@cl-hh.comlink.de
 D-2000 Hamburg 61 # Zerberus: MARCUS_OLK@CL-HH.ZER
`Wer sagt, dass man Glueck nicht kaufen kann, hat keine Ahnung von Shopping'
                                                          --- David Lee Roth

## net_sh v1.5 (sb)
From: boh@SFU.CA
Newsgroups: comp.lang.modula2
Subject: Re: JPI discussion bother me
Date: 27 Jan 93 10:42:30 GMT
Reply-To: Modula2 List <INFO-M2%UCF1VM.BITNET@uga.cc.uga.edu>
Organization: The Internet

I notice your address and notice that you'er from ModulaWare.

Are you guys planning a PC version of ModulaWare's Oberon and Modula 2
compilers ?  I am hoping for an OS/2 2.x implementation and JPI seems to be
the only company offering a 16bit Modula 2 package.

Good Health.

Changhao
boh@sfu.ca
Newsgroups: comp.lang.modula2
From: seurer@rchland.vnet.ibm.com (Bill Seurer)
Subject: Re: JPI discussion bother me
Date: Wed, 27 Jan 1993 15:49:03 GMT
Reply-To: BillSeurer@vnet.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester

MOST of the messages in this group are about some specific compiler or
another.  Discussing the Modula-2 standard and compiler independent
questions are interesting but probably not of as much use to most
followers of this group as are the nitty, gritty details they need
to get their programs going.

Maybe what we need is a comp.lang.modula-2.philosophical for questions
not relating to "real" compilers.

:-)
-- 

- Bill Seurer     Language and Compiler Development      IBM Rochester, MN
  Internet: BillSeurer@vnet.ibm.com    America On-Line: BillSeurer@aol.com
Newsgroups: comp.lang.modula2
From: randy@psg.com (Randy Bush)
Subject: Re: Looking for libraries for SUN m2c
Organization: Pacific Systems Group, Portland Oregon, US
Date: Tue, 26 Jan 1993 15:22:09 GMT

ms@p102.informatik.Uni-Bremen.DE (Martin Schroeder) writes:
> Subject says it all -- are there any libraries for SUN m2c?

You may be interested in the Olsen Library.  For both Sun Modula-2 and
Logitech 3.0, I believe.

You can find it in ftp.psg.com:~/pub/modula-2/olsen/*

randy
-- 
randy@psg.com   ...!uunet!m2xenix!randy
From: randy@psg.com (Randy Bush)
Newsgroups: comp.lang.modula2
Subject: Re: JPI discussion bother me
Date: 27 Jan 93 18:13:02 GMT
Organization: Pacific Systems Group, Portland Oregon, US

100023.2527@COMPUSERVE.COM (Guenter Dotzel) writes:
> Nothing against talking about implementation specific details from time to
> time, but the discussion of JPI specific Modula-2 stuff bothers me.

Let me understand.  *Users* helping each other with an implementation is
unfit for this group, but crass commercial advertising by you, a vendor,
is wonderful.  While I am not a DOS anything fan, stuff it Guenter.

> I don't know whether the Usenet allows vendor specific newsgroup

It does.  Try biz.modulaware.sell.sell.sell.

> Also the thread about NEW/ALLOCATE is boring.

To me too.  But clearly not for others, and this group is not just for me
and thee.  Luckily most folk use newsreaders that have a skip and kill
keys.

randy
-- 
randy@psg.com   ...!uunet!m2xenix!randy
Newsgroups: comp.lang.modula2
From: ms@p102.informatik.Uni-Bremen.DE (Martin Schroeder)
Subject: Looking for libraries for SUN m2c
Reply-To: L15D@ALF.ZFN.UNI-BREMEN.DE
Organization: Universitaet Bremen
Date: Mon, 25 Jan 1993 14:08:43 GMT

Subject says it all -- are there any libraries for SUN m2c?
From: ccsam004@othello.ucdavis.edu (Brian C Hill)
Newsgroups: comp.lang.modula2
Subject: looking for pd modula 2 or 3
Date: 26 Jan 93 02:55:02 GMT
X-Newsreader: Tin 1.1 PL3


	Hello.

	I did not see a posting for a FAQ or other info sheet, so
here is the question. I have found a couple of sites were modula
2 is availble for various platforms - sun3, vax and binaries for a
DEC, but is there a site that has the latest PD version of either
modula 2 or 3?

   +----------------------------------------------------------------------+
   | Brian C. Hill                     INTERNET: hillb@cs.ucdavis.edu     |
   | System Administrator/Programmer   BITNET:   bchill@ucdavis           |
   +----------------------------------------------------------------------+
   | Computer Science & Info. Resources    PHONE: (916) 752-8878 (or 6547)|
   | University of California, Davis       FAX:   (916) 752-4767 (or 9154)|
   +----------------------------------------------------------------------+
From: csfraw@vehka.uta.fi (Francis Akoto)
Newsgroups: comp.lang.modula2
Subject: Re: pascal code to modula
Date: 24 Jan 93 13:33:59 GMT
Reply-To: csfraw@vehka.uta.fi (Francis Akoto)
Organization: University of Tampere, Finland

In article <1993Jan22.163533.8577@psg.com> randy@psg.com (Randy Bush) writes:
>csfraw@vehka.cs.uta.fi (Francis Akoto) writes:
>> This is a pascal code
>>    i,j: integer ;
>>    i := i or j ;
>
>That most certainly is *not* Pascal code.
>
I checked again and the code is excatly like the one above. That program is
working, so i guess the code is right.

--
gallows
     Opinions are like assholes;
     Everybody has one but nobody wants to look at the others.

Newsgroups: comp.lang.fortran
From: ball@msdrl.com (Richard Ball)
Subject: Re: dbx headache
Organization: Merck Research Laboratories
Date: Fri, 22 Jan 93 13:59:40 GMT

MATOVICM@QUCDN.QueensU.CA () writes:
: I'm fed up with dbx (SGI, IRIX 3.3.2, IRIX 4.0.1) when debugging fortran
: programs. Examining arrays is pain in a neck unless you deal with the
: size a(3,3) or similar. Is there any way to say e.g.
:   print a from 155 to 175 (and possibly to specify the increment).
: Or, is there any other UNIX (public domain) debugger that can handle
: arrays frinedly?

your dbx should let you do
&a(155)/20f
to print the 20 elements of a in floating point format starting at element
155. It's not the most friendly way but it is better than listing the whole
thing.
From: mpe@shamash.cdc.com ()
Newsgroups: comp.lang.fortran
Subject: FAQ list - could someone please post or Email a copy???
Date: 27 Jan 93 19:56:28 GMT

Title said everything....

Newsgroups: comp.lang.fortran
From: joelw@convex.com (Joel Williamson)
Subject: Re: loop reduction problem on Silicon Graphics
Date: Thu, 28 Jan 1993 17:45:23 GMT
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 <1993Jan28.112542@ltssun8.epfl.ch> dubuf@ltssun7.epfl.ch (Hans du Buf) writes:
>
>I want to apply the same procedure in getting e.g. the maximum value in an array:
>
>       rmax=-1.0                                     !assume a(i) >= 0
>C$DOACROSS SHARE(a),LOCAL(i),REDUCTION(rmax)
>       do 10 i=1,1000
>       if (a(i).gt.rmax) rmax=a(i)
>10   continue
>

Regardless of whether it parallelizes, you'll get better performance
with

       do 10 i=1,1000
         rmax = max (a(i), rmax)
10   continue

and it just might parallelize as well.

Joel Williamson
-- 

Newsgroups: comp.lang.fortran
From: rvenable@helix.nih.gov (Richard M. Venable)
Subject: Re: dbx headache
Organization: National Institutes of Health, Bethesda
Date: Sat, 23 Jan 1993 19:42:50 GMT

In article <C1BI9E.6ot@me.utoronto.ca> steinman@me.utoronto.ca (David Steinman) writes:
>jfu2@kimbark.uchicago.edu (Carlo Graziani) writes:
>
>>In article <1993Jan22.135940.9828@msdrl.com> ball@msdrl.com (Richard Ball) writes:
>>>MATOVICM@QUCDN.QueensU.CA () writes:
>>>: I'm fed up with dbx (SGI, IRIX 3.3.2, IRIX 4.0.1) when debugging fortran
>
>As if by magic, something called "Duel" has been posted in alt.sources.  I
>claims to be a high-level debugging language which does exactly what you
>require.  The caveat is that is will currently only work with gdb (Gnu 
>debugger?), but can be implemented with dbx, etc.
>
>Here's the intro from the post...
>
>-----------------------------------------------------------------------------
>DUEL -  A high level language for debugging C programs.
>-----------------------------------------------------------------------------

Sorry, but this thread was discussing debugging FORTRAN with dbx, not C; I
don't think gcc and gdb are relevant to this thread, and possibly newsgroup.


-----------------------------------------------------------------
 Rick Venable                  |    "Eschew
 FDA/CBER Biophysics Lab       |   Obfuscation"  
 rvenable@helix.nih.gov        |         -- the Phantom Nerd   
-----------------------------------------------------------------

Newsgroups: comp.lang.fortran
From: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Subject: Compiler groups working on real apps? (was Re: Fast I/O)
Reply-To: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Organization: MRL - UIUC
Date: Fri, 22 Jan 1993 20:49:03 GMT

In article <1993Jan22.193019.12936@news.eng.convex.com>, Patrick F. McGehearty <patrick@convex.COM>
writes:
|>[...]  There are always more
|>potential optimizations and features to add to a language like Fortran
|>than there are resources to add them (Fortran 90 makes this statement
|>self-evident :-).  If a compiler group has been entirely driven by the old
|>simple benchmarks such as Whetstones, Dhrystones, and Linpack 100x100, 
|>they will not even realize that there is a worthwhile optimization to be
|>made in this case.  If they use real production applications, then the
|>optimization may get on their to-do list, depending on their target market
|>segment. 

Hmmm.  Do you mean that compiler developers may have the resources
to deal with masses of strange, horrible codes written or used by all
the folks out here? To analyze these codes and see where they spend time?

This is probably too much to ask.  But I am wondering.  Maybe any one of
us (users) could spend some time in putting together some "typical" code,
containing a simplified version of the loops where our programs spend
most of the time.  Staying within, say, 100 lines.  These "test cases" could 
be posted on c.l.f. (and stored at some anon ftp site) and compiler developers 
could have a look at them and perhaps improve the compilers.

These typical loops could perhaps also be coded as self-contained
benchmarks a-la-Linpack, inducing a bit of competitiveness :-), 
helping us to understand better the strengths and weaknesses of the
various architectures, but not necessarily so.

Any comment?

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" ]
Newsgroups: comp.lang.fortran
From: michael@chpc.utexas.edu (Michael Lemke)
Subject: Re: Reformatter for FORTRAN code
Organization: The University of Texas System - CHPC
Date: Thu, 28 Jan 93 04:14:40 GMT

In article <1993Jan27.210033.19508@stsci.edu> stallcup@stsci.edu (Scott Stallcup) writes:
> We are looking for any tools to reformat FORTRAN code
> (Sometimes called a pretty-printer).  Public domain
> or commercial programs will be considered.  Preferably,
> the program will be able to handle VAX/VMS extensions.
>

Check out TOOLPACK.  Ask archie where to get.  Unfortunately for your 
requirement, though, it is *very* strict on standard Fortran (but accepts 
lowercase and long variables but not include.).  It can `de-spaghettify'
your code which makes it a very useful tool to understand stone-age 
FORTRAN III.5 code.

Michael
-- 
Michael Lemke
Astronomy, UT Austin, Texas
(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
From: corbett@lupa.Eng.Sun.COM (Robert Corbett)
Newsgroups: comp.lang.fortran
Subject: Re: dbx headache
Date: 23 Jan 1993 03:18:01 GMT
Organization: Sun
NNTP-Posting-Host: lupa

MATOVICM@QUCDN.QueensU.CA () writes:
> I'm fed up with dbx (SGI, IRIX 3.3.2, IRIX 4.0.1) when debugging fortran
> programs. Examining arrays is pain in a neck unless you deal with the
> size a(3,3) or similar. Is there any way to say e.g.
>   print a from 155 to 175 (and possibly to specify the increment).
> Or, is there any other UNIX (public domain) debugger that can handle
> arrays frinedly?

I can't help you for SGI equipment, but the dbx for SPARCstations
provided in SPARCworks 2.0.1 appears to do exactly what you want.

The manual *Debugging a Program* states

Syntax for FORTRAN Array Slicing and Striding

     For each dimension of an array, the full syntax to the
     print command to slice the array is:

	 (debugger) print arr (exp1:exp2:exp3)

	 where:

	     exp1 = start_of_slice
	     exp2 = end_of_slice
	     exp3 = length_of_stride
		    (the number of elements skipped is exp3 - 1)

    For an n-dimensional slice, separate the definition of each
    slice with a comma:

	(debugger) print arr (exp1:exp2:exp3, exp1:exp2:exp3,...)

The manual goes on to explain how the elements are laid out in storage,
and convenient shorthand notations.

					Yours truly,
					Robert Corbett
From: jwhite@oasys.dt.navy.mil (Joseph White)
Newsgroups: comp.lang.fortran
Subject: Re: Maximum number of openfiles on MS FORTRAN 5.1?
Date: 22 Jan 93 19:15:18 GMT
Reply-To: jwhite@oasys.dt.navy.mil (Joseph White)
Organization: Annapolis Detachment, CARDEROCKDIV, NSWC  Code 2723 
	      (formerly David Taylor Research Center, Annapolis MD)

In comp.lang.fortran, 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

The information you are looking for is in the file filehand.doc on the
dirtribution floppy disks.  On the 5.25 inch disks, it is on disk 5, I
don't which disk in the 3.5 inch set.  I haven't looked at it in a
while, but I seem to remember that you need an assembler to do it.

Joe White
Newsgroups: comp.lang.fortran
From: ags@seaman.cc.purdue.edu (Dave Seaman)
Subject: Re: intrinsic function for the imaginary part and conjugate?
Organization: Purdue University
Distribution: usa
Date: Thu, 21 Jan 1993 22:34:55 GMT

In article <C183Gu.7MK@athena.cs.uga.edu> shen@athena.cs.uga.edu (Mingzuo  
Shen) writes:
> 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?

I have not seen Metcalf's book, but the Fortran 77 standard says the  
generic function REAL, when given a complex argument, returns the real  
part.

>     More seriously(?), the instrinsic function for complex
> conjugate is also AIMAG? I am sure this is a typo or something.

According to the standard, the complex conjugate function is called CONJG.

--
Dave Seaman
ags@seaman.cc.purdue.edu
Newsgroups: comp.lang.fortran
From: jtbell@hubcap.clemson.edu (Jon Bell)
Subject: Re: Block Data is evil
Organization: Presbyterian College, Clinton SC
Date: Sat, 23 Jan 1993 15:10:52 GMT

In article <C1AMpC.BAt@umassd.edu> hshubs@cis.umassd.edu (Howard S Shubs) writes:
>In <1993Jan22.183106.15813@newshost.lanl.gov> jlg@cochiti.lanl.gov (J. Giles) writes:
>
>>Yes, and that permits you to do run-time management of a statically
>>allocated "maximum" space.  You figure out what the maximum memory
>>you ever need is and you statically allocate that much:
>
>>      PARAMETER (MAXMEM=1000000)
>>      COMMON /MEMORY/ MEM(MAXMEM)
>
>>This reserves one million integer sized words.  Now, you can write
>>a MALLOC routine which returns avalable space from within this array
>>in the form of an index (you actually have two mallocs, one for
>>integers and reals, the other for complex and doubles - since the
>>indices must be scaled differently).  To use:
>
>You're not seriously suggesting that this be used in production code,
>are you?  If you are, is this intended as job security?

It's already been done.  When I was a grad student in experimental
particle physics, I worked with CERN's HYDRA library, which implemented
dynamic memory allocation in FORTRAN using the same basic idea.  I 
think this package is still widely used in particle physics.

Jon Bell / Dept. of Physics & C.S. / Presbyterian College / Clinton SC USA
From: jrbd@craycos.com (James Davies)
Newsgroups: comp.lang.fortran
Subject: Re: Compiler groups working on real apps? (was Re: Fast I/O)
Date: 23 Jan 93 00:36:39 GMT
Organization: Cray Computer Corporation

In article <C19wHr.GF3@news.cso.uiuc.edu> ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi) writes:

>This is probably too much to ask.  But I am wondering.  Maybe any one of
>us (users) could spend some time in putting together some "typical" code,
>containing a simplified version of the loops where our programs spend
>most of the time.  Staying within, say, 100 lines.  These "test cases" could 
>be posted on c.l.f. (and stored at some anon ftp site) and compiler developers 
>could have a look at them and perhaps improve the compilers.
>
>These typical loops could perhaps also be coded as self-contained
>benchmarks a-la-Linpack, inducing a bit of competitiveness :-), 
>helping us to understand better the strengths and weaknesses of the
>various architectures, but not necessarily so.
>
>Any comment?

You've just described the Livermore Loops.
Newsgroups: comp.lang.fortran