What can Fortran do that C, C++, C# can't?

Along similar lines where would Fortran be a superior chice over C, C+
+, or C#

Jeff

RF ENGINEER55

> What can Fortran do that C, C++, C# can't?
>
> Along similar lines where would Fortran be a superior chice over C, C+
> +, or C#

None that I know of.  Here is a dated (1992) paper comparing F77,
F90, C and C++ for engineering pgrograms:
    http://www.leshatton.org/Documents/JSX_0192.pdf

Me, myself and I, we all prefer C++.  I like strong typing and
mandatory function prototypes.  I also like function overloading.

However, I find that the programmer is more important than the
language.  Good programmers can write good code in any language.
Bad programmers can screw anything up.

Lynn

Lynn McGuire wrote:
>> What can Fortran do that C, C++, C# can't?
>>
>> Along similar lines where would Fortran be a superior chice over C, C+
>> +, or C#
> 
> None that I know of.  Here is a dated (1992) paper comparing F77,
> F90, C and C++ for engineering pgrograms:
>    http://www.leshatton.org/Documents/JSX_0192.pdf

Far too dated and superficial in the facilities of current Fortran (see 
Richard Maine's comments in other thread where it was brought up) I 
think to be of any value any longer.
> 
> Me, myself and I, we all prefer C++.  I like strong typing and
> mandatory function prototypes.  I also like function overloading.

"IMPLICIT NONE"  :)

Generic functions exist in Fortran since F90/95 and more oo-related 
stuff is in F03/F08.

I as the same trio am adamantly in the opposite camp... :)

I expect the above sentiment is largely owing to not having legacy F77 
code that hasn't already been ported years ago to F95 compilers so that 
those features are now old hat.  In your situation wherein you're forced 
to use a compiler last updated nearly 20 years ago now and a code base 
some of which dates to 40 years or more, it's not surprising that 
something newer looks shinier.  :)

> However, I find that the programmer is more important than the
> language.  Good programmers can write good code in any language.
> Bad programmers can screw anything up.

Amen...some of the best code I've ever read was written in Forth.  It 
was almost as easy to read as a text.  OTOH, some of the worst was also 
on the same project but by a far less adept coder.  I've not doubt that 
same coders C or Fortran would also have been very poor as well.

--

rfengineer55 wrote:
> What can Fortran do that C, C++, C# can't?
> 
> Along similar lines where would Fortran be a superior chice over C, C+
> +, or C#
> 
> Jeff
> 
> RF ENGINEER55

I suggest a google search on that topic - there have been countless 
discussions/arguments over the years.  I'd be surprised if you find many here 
who want to reprise them.

dpb <none@non.net> wrote:
....
> I expect the above sentiment is largely owing to not having legacy F77
> code

In Lynn's case, I'd claim that the code was legacy F66 code that had not
yet been fully ported to f77. It obviously also has a mixture of some
newer features, but if she is just now getting rid of the Hollerith
usage, I'd say that part reflects F66 legacy. Hollerith was not part of
the F77 standard. There is an F77 Appendix describing Hollerith, but
about the first thing the Appendix section of f77 says is "These
Appendices are not part of American National Standard Programming
Language Fortran..."

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

Richard Maine wrote:
> dpb <none@non.net> wrote:
> ...
>> I expect the above sentiment is largely owing to not having legacy F77
>> code
> 
> In Lynn's case, I'd claim that the code was legacy F66 code that had not
> yet been fully ported to f77. It obviously also has a mixture of some
> newer features, but if she 

I _believe_ this Lynn is a he (altho I may be wrong).  :)


> ... is just now getting rid of the Hollerith
> usage, I'd say that part reflects F66 legacy. Hollerith was not part of
> the F77 standard. There is an F77 Appendix describing Hollerith, but
> about the first thing the Appendix section of f77 says is "These
> Appendices are not part of American National Standard Programming
> Language Fortran..."


And, that is true of at least some of the code as well as predating F77 
-- I thought I had covered that but not quite as strongly, granted.

I was thinking mostly that at the moment he's still stuck w/ a F77 
compiler albeit w/ some extensions as the port to IVF isn't functional 
even though it apparently compiles owing to the difference in the /SAVE 
compiler option behavior.

Either way, I think it's fair to say that his and his company's 
viewpoint on Fortran is colored strongly by the limitations placed on 
them of an apparently quite large and old code base.

--

On Jun 28, 6:17=A0pm, Gib Bogle <g.bo...@auckland.no.spam.ac.nz> wrote:
> rfengineer55 wrote:
> > What can Fortran do that C, C++, C# can't?
>
> > Along similar lines where would Fortran be a superior chice over C, C+
> > +, or C#
>
> > Jeff
>
> > RF ENGINEER55
>
> I suggest a google search on that topic - there have been countless
> discussions/arguments over the years. =A0I'd be surprised if you find man=
y here
> who want to reprise them.

I'll take Lynn's word for it :-)  Good enough for now. The last thing
I need now is another research project.

I figured that if there was anything that Fortran could do, the fine
folks here would know.

Jeff
RFENGINEER55

> In Lynn's case, I'd claim that the code was legacy F66 code that had not
> yet been fully ported to f77. It obviously also has a mixture of some
> newer features, but if she is just now getting rid of the Hollerith
> usage, I'd say that part reflects F66 legacy. Hollerith was not part of
> the F77 standard. There is an F77 Appendix describing Hollerith, but
> about the first thing the Appendix section of f77 says is "These
> Appendices are not part of American National Standard Programming
> Language Fortran..."

BTW, in a case of non-strongly typed variable names, Lynn is a He.

I wish that I could say that you were wrong about the F66 code but
you are mostly correct.  In fact, we only started using "implicit
none" since 2005 at the urging of several on this group.  It took
a year just to get that ball rolling because the oldest member of
my staff was firmly against it.  But he was one of those awesome
programmers who could write great code in any language.  He has
since retired in Dec 2008 at the age of 73.  I miss him greatly as
we worked together for over 20 years.

Lynn

dpb wrote:
....

> I was thinking mostly that at the moment he's still stuck w/ a F77 
> compiler ...

And, actually I wrote the earlier as the basis of _my_ preference for 
Fortran vis a vis C/C++ being that I hadn't had any code base for quite 
a long time that was constrained such as his.  At one time had support 
on all that stuff and worse but that went away when I left the power 
reactor vendor arena behind many years ago...fortunately.  :)

--

On 6/28/2010 6:32 PM, Richard Maine wrote:
> dpb<none@non.net>  wrote:
> ...
>> I expect the above sentiment is largely owing to not having legacy F77
>> code
>
> In Lynn's case, I'd claim that the code was legacy F66 code that had not
> yet been fully ported to f77. It obviously also has a mixture of some
> newer features, but if she is just now getting rid of the Hollerith
> usage, I'd say that part reflects F66 legacy. Hollerith was not part of
> the F77 standard. There is an F77 Appendix describing Hollerith, but
> about the first thing the Appendix section of f77 says is "These
> Appendices are not part of American National Standard Programming
> Language Fortran..."
>
Even with software it is possible to generate non-repeating sequences. 
I don't have any precise requirement personally.  But I've used some 
poor quality ones.  In one case, I was trying to set random pixels (or 
actually copy a graphic at random positions) in a bitmap image and the 
RNG sequence was visually predictable.  Maybe it was just a poor quality 
RNG implementation (or maybe even I was misusing it).

Lynn McGuire <lmc@winsim.com> wrote:

> BTW, in a case of non-strongly typed variable names, Lynn is a He.

Darn. Darn. Darn. Now that you bring it to mind, I recall making that
mistake before. I apologize. I'll try to avoid making that mistake a
third time. Having once had the notion stuck in my mind, it tends to
sneak back in.

Hey, I should be used to "generic" names. My wife is Trindel, named
after her father. There had been a family tradition of naming the
first-born son Trindel. When the "unthinkable" happened (as first born,
she wasn't a son), her parents decided that the name worked anyway. She
had some thought of continuing it with our first born (who was a son).
We compromised by making it his middle name.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

rfengineer55 <rfengineer55@aol.com> wrote:

> I figured that if there was anything that Fortran could do, the fine
> folks here would know.

Google "turing equivalent".

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

In article 
<08ad53e3-f827-4d57-896b-cf6bc245003e@z8g2000yqz.googlegroups.com>,
 rfengineer55 <rfengineer55@aol.com> wrote:

> What can Fortran do that C, C++, C# can't?

One of the most important things a fortran compiler can do is that it 
can compile fortran programs.  There are millions of lines of legacy 
fortran, both in programs and in library routines.

I think all of these are complete programming languages in the sense 
that you can do anything that can be programmed.  You can write a 
fortran compiler in the other languages, for example, and compile 
fortran programs (like gfortran does).  Or you could write a lisp 
machine in these languages and run lisp programs.  And so on.

If you are asking what is easier, or simpler, in fortran than in other 
languages, then you may get a few mostly personal responses.  For 
example, I personally think arrays are easier to work with in fortran 
than in most other languages.

$.02 -Ron Shepard

On Jun 28, 8:41=A0pm, Ron Shepard <ron-shep...@NOSPAM.comcast.net>
wrote:
> In article
> <08ad53e3-f827-4d57-896b-cf6bc2450...@z8g2000yqz.googlegroups.com>,
>
> =A0rfengineer55 <rfenginee...@aol.com> wrote:
> > What can Fortran do that C, C++, C# can't?
>
> One of the most important things a fortran compiler can do is that it
> can compile fortran programs. =A0There are millions of lines of legacy
> fortran, both in programs and in library routines.
>
> I think all of these are complete programming languages in the sense
> that you can do anything that can be programmed. =A0You can write a
> fortran compiler in the other languages, for example, and compile
> fortran programs (like gfortran does). =A0Or you could write a lisp
> machine in these languages and run lisp programs. =A0And so on.
>
> If you are asking what is easier, or simpler, in fortran than in other
> languages, then you may get a few mostly personal responses. =A0For
> example, I personally think arrays are easier to work with in fortran
> than in most other languages.
>
> $.02 -Ron Shepard

Ron,

I was asking in terms of what the Fortran language itself had
provisions for that cold not be done in C, C++, or C#. I don't know if
fortran can handle structured like an array of pointers, to pointers,
to type Integer, for example. C can handle some complex pointer
structures. I've never seen similoar structures done if fortran, but
I've not seen everything that Fortran can do either :-)

I would tend to believe that C, C++, and C# can do more than Fortran
can do. Just an educated guess on my part.

Jeff

RF ENGINEER55

rfengineer55 <rfengineer55@aol.com> wrote:

> What can Fortran do that C, C++, C# can't?
> 
> Along similar lines where would Fortran be a superior chice over C, C+
> +, or C#
> 
> Jeff
> 
> RF ENGINEER55

All the above languages are Turing equivalent, so anything that can be
done in any one of the above can be done in any of the others.  They
differ in how easily and how naturaly different things can be done.
Often the naturally is a matter of taste and experience.Sometime the
fact that something cannot be easily done in a language is an advantage
of the language if what can be easily done is equivalent to shooting off
your foot.

-- 
Bill Clodius
los the lost and net the pet to email

rfengineer55 <rfengineer55@aol.com> wrote:

> I was asking in terms of what the Fortran language itself had
> provisions for that cold not be done in C, C++, or C#. I don't know if
> fortran can handle structured like an array of pointers, to pointers,
> to type Integer, for example.

That would not be particulary close to what a language "can do". What a
language "can do" would be solve computational problems. Your examples
sound more like a list of features. That's not a very meaningful basis
for much of anything, particularly when expressed in terms of features
of a specific language. Your examples are actually amazingly close to
Ron's description of a Fortran compiler being able to compile Fortran
code. No a Fortran compiler can't compile C code, just like a C compiler
can't compile Fortran code, but that's not a very useful comparison.

Even by the usual low standards of language wars, this is a pretty poor
start.

But as Gib noted, most people here aren't likely to be interested in
rehashing old flame wars. About all it will do is get you added to
killfiles.

But I'm probably not communicating very effectively here - just like I
apparently did not manage to communicate that I do not provide my email
address for private Fortran consulting purposes. :-(

Don't expect to see any more replies in this thread from me. I'm pretty
much expecting to see more things in it that strike me as nonsense, but
I'm not going to bother to say so any more. You can take my future
silence as making the point more effectively than I could in words.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

In article <i0b9nl$809$1@news.eternal-september.org>, Lynn McGuire
<lmc@winsim.com> writes: 

> However, I find that the programmer is more important than the
> language.  Good programmers can write good code in any language.
> Bad programmers can screw anything up.

Fortran programmers can write Fortran in any language.  :-)

In article 
<918d5e01-2848-40cc-8894-744a58a4ebaa@d37g2000yqm.googlegroups.com>,
 rfengineer55 <rfengineer55@aol.com> wrote:

> On Jun 28, 8:41�pm, Ron Shepard <ron-shep...@NOSPAM.comcast.net>
> wrote:
> > In article
> > <08ad53e3-f827-4d57-896b-cf6bc2450...@z8g2000yqz.googlegroups.com>,
> >
> > �rfengineer55 <rfenginee...@aol.com> wrote:
> > > What can Fortran do that C, C++, C# can't?
> >
> > One of the most important things a fortran compiler can do is that it
> > can compile fortran programs. �There are millions of lines of legacy
> > fortran, both in programs and in library routines.

I guess I should have elaborated on this a little more.  Those 
fortran programs are in constant use every day, and the fortran 
library routines are being incorporated every day into new programs.

> > I think all of these are complete programming languages in the sense
> > that you can do anything that can be programmed. 

Someone else used the correct term "Turing complete".

>�You can write a
> > fortran compiler in the other languages, for example, and compile
> > fortran programs (like gfortran does). �Or you could write a lisp
> > machine in these languages and run lisp programs. �And so on.
> >
> > If you are asking what is easier, or simpler, in fortran than in other
> > languages, then you may get a few mostly personal responses. �For
> > example, I personally think arrays are easier to work with in fortran
> > than in most other languages.
> >
> > $.02 -Ron Shepard
> 
> Ron,
> 
> I was asking in terms of what the Fortran language itself had
> provisions for that cold not be done in C, C++, or C#.

You must not have read the replies to your original post.  Several 
of them made the same point.  All these languages are complete, and 
you can do anything in any of them that can be programmed.  I gave 
some examples of this above.

> I don't know if
> fortran can handle structured like an array of pointers, to pointers,
> to type Integer, for example.

Yes.  The syntax is a little different but the functionality is the 
same.  In fortran you would put the pointer inside of a derived 
type, and then declare an array of that type.

> C can handle some complex pointer
> structures.

Oh yeah, that reminds me of complex arithmetic support.  It has been 
part of standard fortran since the 60's.  I think some of the other 
languages you mentioned have only recently gained support for 
complex arithmetic.  But, you could simulate it in these other 
languages in various ways, so as long as you did not have to combine 
code from two or more different sources that had implemented this 
hack in different and incompatible ways, you could achieve what was 
necessary.

> I've never seen similoar structures done if fortran, but
> I've not seen everything that Fortran can do either :-)
> 
> I would tend to believe that C, C++, and C# can do more than Fortran
> can do. Just an educated guess on my part.

Again, you must not be reading the replies to your post.

As far as my earlier reply, which you also apparently did not read, 
consider something as simple as the following declaration

   real array(-m:m,0:n,k)

This declaration allows you to reference it as array(i1,i2,i3) where 
those indices take their natural values in the mathematical 
expression that you are evaluating.  You aren't stuck with 
zero-offset arrays, or with only one-dimensional arrays where you 
have to compute the 3D index manually, you just use the 
multidimensional array in the natural way.

You can achieve something similar in those other languages, but it 
is not as clear and straightforward.  I remember hearing a lot of 
criticism of the original Numerical Recipes in C, for example, where 
it was necessary to violate the standard to achieve similar 
functionality (i.e. to make the code look more like the mathematical 
equation that it was evaluating).  And even with that illegal hack, 
the code was not easy to understand and the compiler could not 
provide any bounds checking support.  BTW, the above is f77, an 
obsolete version of the language that is over 30 years old -- modern 
fortran has even better general array support.

$.02 -Ron Shepard

On 06/28/2010 04:17 PM, dpb wrote:
> Lynn McGuire wrote:
>>> What can Fortran do that C, C++, C# can't?
>>>
>>> Along similar lines where would Fortran be a superior chice over C, C+
>>> +, or C#
>>
>> None that I know of. Here is a dated (1992) paper comparing F77,
>> F90, C and C++ for engineering pgrograms:
>> http://www.leshatton.org/Documents/JSX_0192.pdf
>
> Far too dated and superficial in the facilities of current Fortran (see
> Richard Maine's comments in other thread where it was brought up) I
> think to be of any value any longer.
>>
>> Me, myself and I, we all prefer C++. I like strong typing and
>> mandatory function prototypes. I also like function overloading.
>
> "IMPLICIT NONE" :)
>
> Generic functions exist in Fortran since F90/95 and more oo-related
> stuff is in F03/F08.
>
> I as the same trio am adamantly in the opposite camp... :)
>
> I expect the above sentiment is largely owing to not having legacy F77
> code that hasn't already been ported years ago to F95 compilers so that
> those features are now old hat. In your situation wherein you're forced
> to use a compiler last updated nearly 20 years ago now and a code base
> some of which dates to 40 years or more, it's not surprising that
> something newer looks shinier. :)
>
>> However, I find that the programmer is more important than the
>> language. Good programmers can write good code in any language.
>> Bad programmers can screw anything up.
>
> Amen...some of the best code I've ever read was written in Forth. It was
> almost as easy to read as a text. OTOH, some of the worst was also on
> the same project but by a far less adept coder. I've not doubt that same
> coders C or Fortran would also have been very poor as well.
>
> --
Wow, A Forth fan?  I have written Forth interpreters.  Very elegant, very practical.

In spite of all the arguments, Fortran (as it continues to evolve) is at a very 
minimum, damn good!

J:)

Gary L. Scott <garylscott@sbcglobal.net> wrote:
(snip)

> Even with software it is possible to generate non-repeating sequences. 

Well, not repeating within a given time period, which could be
longer than the age of the universe.  A gigabit of state will
give you an extremely long period, but it will eventually repeat.
2**(2**30)-1 seconds is a very long time.  I saw some time ago a
claim that 10**136 was supposed to be the largest useful number.
That is, the volume of the universe in cubic Fermis. (Also known
as femtometers, with the convenient abreviation fm in either case.)
The volume of a proton is about 1fm.

> I don't have any precise requirement personally.  But I've used some 
> poor quality ones.  In one case, I was trying to set random pixels (or 
> actually copy a graphic at random positions) in a bitmap image and the 
> RNG sequence was visually predictable.  Maybe it was just a poor quality 
> RNG implementation (or maybe even I was misusing it).

Many good PRNGs are not so good if you use only the low bits.
That is mostly a problem if you use ones that generate integers
and use MOD for reducing the generated number to an appropriate
small range.  

But also humans are sometimes good at seeing patterns even
where there is no pattern.  Consider constellations, for example.

-- glen

Ron Shepard <ron-shepard@nospam.comcast.net> wrote:
> In article 
> <08ad53e3-f827-4d57-896b-cf6bc245003e@z8g2000yqz.googlegroups.com>,
> rfengineer55 <rfengineer55@aol.com> wrote:
 
>> What can Fortran do that C, C++, C# can't?
 
> One of the most important things a fortran compiler can do is that it 
> can compile fortran programs.  There are millions of lines of legacy 
> fortran, both in programs and in library routines.
 
> I think all of these are complete programming languages in the sense 
> that you can do anything that can be programmed.  You can write a 
> fortran compiler in the other languages, for example, and compile 
> fortran programs (like gfortran does).  Or you could write a lisp 
> machine in these languages and run lisp programs.  And so on.

There are many Fortran compilers written in C, as far as I know,
no C compilers written in Fortran.  

-- glen

Jerry DeLisle wrote:

> In spite of all the arguments, Fortran (as it continues to evolve) is at 
> a very minimum, damn good!

I don't like Fortran
oh no
I love it!

Ron Shepard <ron-shepard@nospam.comcast.net> wrote:
(snip)
 
>> C can handle some complex pointer structures.

Especially arrays of pointers.
 
> Oh yeah, that reminds me of complex arithmetic support.  It has been 
> part of standard fortran since the 60's.  

It has, but the library support for it wasn't so complete until
somewhat later.  Fortran 66, for example, doesn't allow for
(complex)**(complex).  Also, only single precision complex
until much later than the 60's.  

A large part of the Fortran code doing complex arithmetic,
such as just about every FFT implementation, uses arrays of REAL
(or maybe DOUBLE PRECISION).

(snip)

-- glen

On 06/29/2010 01:03 AM, Lynn McGuire wrote:

I'm also full-time C++ developer, working in the environment where 
FORTRAN is also used.

> Me, myself and I, we all prefer C++. I like strong typing and
> mandatory function prototypes. I also like function overloading.

Just for the sake of truth: C++ is *far more* than just strong typing 
and overloading. These are just scratch on the surface of the language

On the other hand, C++ is quite (very?) complex, and it has very steep 
learning curve. If someone already knows FORTRAN (read: any programming 
language), and it fulfils all his needs, there is absolutely no reason 
to switch to another language.

>
> However, I find that the programmer is more important than the
> language. Good programmers can write good code in any language.
> Bad programmers can screw anything up.

I second this one.

On Jun 29, 8:02=A0am, Leclerc <gordan.sikic.rem...@this.inet.hr> wrote:
>
>
> I'm also full-time C++ developer, working in the environment where
> FORTRAN is also used.

Just a nitpick - it's spelt Fortran, and has been for around 20 years
despite what Microsoft claim,

Ian

>> I'm also full-time C++ developer, working in the environment where
>> FORTRAN is also used.
>
> Just a nitpick - it's spelt Fortran, and has been for around 20 years
> despite what Microsoft claim,

:)

of course,

Mea culpa

On 6/28/2010 10:40 PM, rfengineer55 wrote:
> On Jun 28, 8:41 pm, Ron Shepard<ron-shep...@NOSPAM.comcast.net>
> wrote:
>> In article
>> <08ad53e3-f827-4d57-896b-cf6bc2450...@z8g2000yqz.googlegroups.com>,
>>
>>   rfengineer55<rfenginee...@aol.com>  wrote:
>>> What can Fortran do that C, C++, C# can't?
>>
>> One of the most important things a fortran compiler can do is that it
>> can compile fortran programs.  There are millions of lines of legacy
>> fortran, both in programs and in library routines.
>>
>> I think all of these are complete programming languages in the sense
>> that you can do anything that can be programmed.  You can write a
>> fortran compiler in the other languages, for example, and compile
>> fortran programs (like gfortran does).  Or you could write a lisp
>> machine in these languages and run lisp programs.  And so on.
>>
>> If you are asking what is easier, or simpler, in fortran than in other
>> languages, then you may get a few mostly personal responses.  For
>> example, I personally think arrays are easier to work with in fortran
>> than in most other languages.
>>
>> $.02 -Ron Shepard
>
> Ron,
>
> I was asking in terms of what the Fortran language itself had
> provisions for that cold not be done in C, C++, or C#. I don't know if
> fortran can handle structured like an array of pointers, to pointers,
> to type Integer, for example. C can handle some complex pointer
> structures. I've never seen similoar structures done if fortran, but
> I've not seen everything that Fortran can do either :-)
>
> I would tend to believe that C, C++, and C# can do more than Fortran
> can do. Just an educated guess on my part.

Many of those complex structures are ill-advised abominations.  In some 
cases, the C programmer does that because of either stupidity or lack of 
suitable replacement features in the C language for which Fortran may 
have a better replacement feature.  It is better to think in terms of 
how can a problem be solved and not get hung up on the particular 
method.  There may be other, in many cases better methods of solving the 
same problem.

>
> Jeff
>
> RF ENGINEER55

On 2010-06-28 20:53:00 -0300, Lynn McGuire <lmc@winsim.com> said:

>> In Lynn's case, I'd claim that the code was legacy F66 code that had not
>> yet been fully ported to f77. It obviously also has a mixture of some
>> newer features, but if she is just now getting rid of the Hollerith
>> usage, I'd say that part reflects F66 legacy. Hollerith was not part of
>> the F77 standard. There is an F77 Appendix describing Hollerith, but
>> about the first thing the Appendix section of f77 says is "These
>> Appendices are not part of American National Standard Programming
>> Language Fortran..."
> 
> BTW, in a case of non-strongly typed variable names, Lynn is a He.
> 
> I wish that I could say that you were wrong about the F66 code but
> you are mostly correct.  In fact, we only started using "implicit
> none" since 2005 at the urging of several on this group.  It took
> a year just to get that ball rolling because the oldest member of
> my staff was firmly against it.  But he was one of those awesome
> programmers who could write great code in any language.  He has
> since retired in Dec 2008 at the age of 73.  I miss him greatly as
> we worked together for over 20 years.
> 
> Lynn

It sounds like a textbook example of an "indispensable" employee. It will
now take considerable time to recover from the "indispensable" employee.

I have always been told that when a manager discovers that they have an
"indispensable" employee that they should immediately plan to fire that
employee before it become irrecoverable.

>
> Just a nitpick - it's spelt Fortran, and has been for around 20 years
> despite what Microsoft claim,

Another paneful claim? See my signature.:-)


I remember last year when I was trying to decide which language to
choose for rewriting C-Graph:

http://www.codeartnow.com/code/download/c-graph-1/c-graph-version-2-preview

I considered both C and C++. I had been coding in nothing else but
Lisp for years and had forgotten all my C.

I decided that Fortran was easier to learn (or relearn) than C. As for
C++, all the Googling I did pointed to coders migrating from C++ to
Fortran as they believed that C++ was too error prone. The decision to
use Fortran (based on what I could see from the web) was easy.

The only stumbling block came later as I investigated using the GNU
Autotools to package the program. There is far more information
pertaining to packaging C programs with the Autotools than Fortran,
and I found that rushing learning the Autotools with the peculiar
things I want to do with C-Graph, was not an option - particularly
having chosen Fortran rather than C.

Overall, I'm happy that I did choose Fortran (members of this group
persuaded me to learn 90/95/2003 instead of sticking with 77, which is
what I used to code the original program for my dissertation back in
1983). I plan to review C sometime, but somehow, I don't think I'll be
coding in C++ anytime soon for OOP - not with the progressive
developments in Fortran, and my love of Lisp.


agt

--
Freedom - no pane, all gaiGN!

Code Art Now
http://codeartnow.com
Email: a...@codeartnow.com

In article <Vu2dnZxfzsu_c7TRnZ2dnUVZ_gOdnZ2d@supernews.com>,
 "Gary L. Scott" <garylscott@sbcglobal.net> wrote:

> > I would tend to believe that C, C++, and C# can do more than Fortran
> > can do. Just an educated guess on my part.
> 
> Many of those complex structures are ill-advised abominations. 

A good example of this is multidimensional arrays which I indicated 
earlier.  Since C did not allow these (except with constant dimensions, 
I think was the exception), everyone was forced to implement various 
hacks to work around this shortcoming of the language.  Usually this 
involved arrays of pointers, or arrays of pointers to pointers, or some 
such, depending on the dimension of the matrix.  If this is an example 
of C "doing more than Fortran", then that is surely trying to turn a 
liability into an asset.

Even though fortran does support these kinds of data structures, it is 
often better to avoid them.  Allocatable arrays in fortran, for example, 
have several advantages over the analogous pointer approach, and that is 
often the preferred data type given the various options.  As far as I 
know, even modern C does not support multidimensional allocatable 
arrays, and it gives the programmer no control over the lower bounds 
within the array, so it is some 30+ years behind fortran in some ways, 
and 20+ years behind fortran in others.  I don't know about the latest 
version of the other languages in this thread title in this respect.

$.02 -Ron Shepard

On 6/29/2010 1:01 PM, Ron Shepard wrote:
> In article<Vu2dnZxfzsu_c7TRnZ2dnUVZ_gOdnZ2d@supernews.com>,
>   "Gary L. Scott"<garylscott@sbcglobal.net>  wrote:
>
>>> I would tend to believe that C, C++, and C# can do more than Fortran
>>> can do. Just an educated guess on my part.
>>
>> Many of those complex structures are ill-advised abominations.
>
> A good example of this is multidimensional arrays which I indicated
> earlier.  Since C did not allow these (except with constant dimensions,
> I think was the exception), everyone was forced to implement various
> hacks to work around this shortcoming of the language.  Usually this
> involved arrays of pointers, or arrays of pointers to pointers, or some
> such, depending on the dimension of the matrix.  If this is an example
> of C "doing more than Fortran", then that is surely trying to turn a
> liability into an asset.
>
> Even though fortran does support these kinds of data structures, it is
> often better to avoid them.  Allocatable arrays in fortran, for example,
> have several advantages over the analogous pointer approach, and that is
> often the preferred data type given the various options.  As far as I
> know, even modern C does not support multidimensional allocatable
> arrays, and it gives the programmer no control over the lower bounds
> within the array, so it is some 30+ years behind fortran in some ways,
> and 20+ years behind fortran in others.  I don't know about the latest
> version of the other languages in this thread title in this respect.

In C++, you can write a class to implement a multidimensional array.  Or 
you can download a Boost library:

http://www.boost.org

I've read some of the documentation.  At first glance, this appears to 
be nontrivial.  I suspect that simple cases would be easier to code in 
Fortran.

FWIW, ALGOL let the programmer specify lower bounds long before Fortran. 
  Meanwhile, Burroughs Extended ALGOL implemented multidimensional 
arrays as arrays of pointers.  This was a "feature."

Louis

On Jun 28, 11:30=A0pm, nos...@see.signature (Richard Maine) wrote:
> rfengineer55 <rfenginee...@aol.com> wrote:
> > I was asking in terms of what the Fortran language itself had
> > provisions for that cold not be done in C, C++, or C#. I don't know if
> > fortran can handle structured like an array of pointers, to pointers,
> > to type Integer, for example.
>
> That would not be particulary close to what a language "can do". What a
> language "can do" would be solve computational problems. Your examples
> sound more like a list of features. That's not a very meaningful basis
> for much of anything, particularly when expressed in terms of features
> of a specific language. Your examples are actually amazingly close to
> Ron's description of a Fortran compiler being able to compile Fortran
> code. No a Fortran compiler can't compile C code, just like a C compiler
> can't compile Fortran code, but that's not a very useful comparison.
>
> Even by the usual low standards of language wars, this is a pretty poor
> start.
>
> But as Gib noted, most people here aren't likely to be interested in
> rehashing old flame wars. About all it will do is get you added to
> killfiles.
>
> But I'm probably not communicating very effectively here - just like I
> apparently did not manage to communicate that I do not provide my email
> address for private Fortran consulting purposes. :-(
>
> Don't expect to see any more replies in this thread from me. I'm pretty
> much expecting to see more things in it that strike me as nonsense, but
> I'm not going to bother to say so any more. You can take my future
> silence as making the point more effectively than I could in words.
>
> --
> Richard Maine =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Good judgment come=
s from experience;
> email: last name at domain . net | experience comes from bad judgment.
> domain: summertriangle =A0 =A0 =A0 =A0 =A0 | =A0-- Mark Twain

Richard,

Understood.

I'm also not interested in starting a war or any other similar
childish nonsense. Only interested in a meaningful discussion here.

I was more interested in a simple thumbnail scratch regarding any
possible features that fortran has over the various versions of C. It
would appear from what's been posted here, that there really isn't
anything Fortran can do than the others can't. That is, from a
practical point of view of "can't."

Thank you for your comments.

Jeff

RF ENGINEER55

On Jun 29, 12:53=A0am, Ron Shepard <ron-shep...@NOSPAM.comcast.net>
wrote:
> In article
> <918d5e01-2848-40cc-8894-744a58a4e...@d37g2000yqm.googlegroups.com>,
>
> =A0rfengineer55 <rfenginee...@aol.com> wrote:
> > On Jun 28, 8:41=A0pm, Ron Shepard <ron-shep...@NOSPAM.comcast.net>
> > wrote:
> > > In article
> > > <08ad53e3-f827-4d57-896b-cf6bc2450...@z8g2000yqz.googlegroups.com>,
>
> > > =A0rfengineer55 <rfenginee...@aol.com> wrote:
> > > > What can Fortran do that C, C++, C# can't?
>
> > > One of the most important things a fortran compiler can do is that it
> > > can compile fortran programs. =A0There are millions of lines of legac=
y
> > > fortran, both in programs and in library routines.
>
> I guess I should have elaborated on this a little more. =A0Those
> fortran programs are in constant use every day, and the fortran
> library routines are being incorporated every day into new programs.
>
> > > I think all of these are complete programming languages in the sense
> > > that you can do anything that can be programmed.
>
> Someone else used the correct term "Turing complete".
>
>
>
>
>
> >=A0You can write a
> > > fortran compiler in the other languages, for example, and compile
> > > fortran programs (like gfortran does). =A0Or you could write a lisp
> > > machine in these languages and run lisp programs. =A0And so on.
>
> > > If you are asking what is easier, or simpler, in fortran than in othe=
r
> > > languages, then you may get a few mostly personal responses. =A0For
> > > example, I personally think arrays are easier to work with in fortran
> > > than in most other languages.
>
> > > $.02 -Ron Shepard
>
> > Ron,
>
> > I was asking in terms of what the Fortran language itself had
> > provisions for that cold not be done in C, C++, or C#.
>
> You must not have read the replies to your original post. =A0Several
> of them made the same point. =A0All these languages are complete, and
> you can do anything in any of them that can be programmed. =A0I gave
> some examples of this above.
>
> > I don't know if
> > fortran can handle structured like an array of pointers, to pointers,
> > to type Integer, for example.
>
> Yes. =A0The syntax is a little different but the functionality is the
> same. =A0In fortran you would put the pointer inside of a derived
> type, and then declare an array of that type.
>
> > C can handle some complex pointer
> > structures.
>
> Oh yeah, that reminds me of complex arithmetic support. =A0It has been
> part of standard fortran since the 60's. =A0I think some of the other
> languages you mentioned have only recently gained support for
> complex arithmetic. =A0But, you could simulate it in these other
> languages in various ways, so as long as you did not have to combine
> code from two or more different sources that had implemented this
> hack in different and incompatible ways, you could achieve what was
> necessary.
>
> > I've never seen similoar structures done if fortran, but
> > I've not seen everything that Fortran can do either :-)
>
> > I would tend to believe that C, C++, and C# can do more than Fortran
> > can do. Just an educated guess on my part.
>
> Again, you must not be reading the replies to your post.
>
> As far as my earlier reply, which you also apparently did not read,
> consider something as simple as the following declaration
>
> =A0 =A0real array(-m:m,0:n,k)
>
> This declaration allows you to reference it as array(i1,i2,i3) where
> those indices take their natural values in the mathematical
> expression that you are evaluating. =A0You aren't stuck with
> zero-offset arrays, or with only one-dimensional arrays where you
> have to compute the 3D index manually, you just use the
> multidimensional array in the natural way.
>
> You can achieve something similar in those other languages, but it
> is not as clear and straightforward. =A0I remember hearing a lot of
> criticism of the original Numerical Recipes in C, for example, where
> it was necessary to violate the standard to achieve similar
> functionality (i.e. to make the code look more like the mathematical
> equation that it was evaluating). =A0And even with that illegal hack,
> the code was not easy to understand and the compiler could not
> provide any bounds checking support. =A0BTW, the above is f77, an
> obsolete version of the language that is over 30 years old -- modern
> fortran has even better general array support.
>
> $.02 -Ron Shepard- Hide quoted text -
>
> - Show quoted text -

Ron,

It serves no useful purpose for you to guess what i read, and did not
read. It's more a matter of what I chose to comment on, and what not
to comment on.

I'm just jooking for some very general information, and language is a
matter of individual preference. That's not where i am/was going.

Thanks to all for the information.

RF ENGINEER55

On 6/29/2010 2:13 PM, rfengineer55 wrote:
<snip>
> It
> would appear from what's been posted here, that there really isn't
> anything Fortran can do than the others can't.

Or vice versa.

> That is, from a
> practical point of view of "can't."

"Can't" has a technical definition;  see "Turing complete."

If you want to discuss what's easy to do in a given language, or which 
language you enjoy writing, that's a different story.

Louis

"rfengineer55"  asked this question:
> What can Fortran do that C, C++, C# can't?
>
> Along similar lines where would Fortran be a superior chice over C, C+
> +, or C#
>

Since the CPUs on todays computers are not getting any faster (as was 
promised 20 years ago), my main concern is what will crunch numbers faster.

So which compiler or language is best suited for faster processing?

-- Steve F.

>> However, I find that the programmer is more important than the
>> language.  Good programmers can write good code in any language.
>> Bad programmers can screw anything up.
>
> Fortran programmers can write Fortran in any language.  :-)

I was waiting for that !

Lynn

Fortran is the worst programming language, apart from all the others for 
which compilers have been written from time to time.

-- 
Qolin

Email: my qname at domain dot com
Domain: qomputing
"Gib Bogle" <g.bogle@auckland.no.spam.ac.nz> wrote in message 
news:i0c529$5rh$1@speranza.aioe.org...
> Jerry DeLisle wrote:
>
>> In spite of all the arguments, Fortran (as it continues to evolve) is at 
>> a very minimum, damn good!
>
> I don't like Fortran
> oh no
> I love it! 

> There are many Fortran compilers written in C, as far as I know,
> no C compilers written in Fortran.

If the old Prime computers had a C compiler, it was probably
written in Fortran.  The whole operating system was written in
a heavily extended fortran 66 until the 198? release which was
rewritten in PL/1.

Lynn

Here is an even more dated paper (1893) comparing Fortran and some other 
languages:

http://www.pbm.com/~lindahl/real.programmers.html

-- 
Qolin

Email: my qname at domain dot com
Domain: qomputing
"Lynn McGuire" <lmc@winsim.com> wrote in message 
news:i0b9nl$809$1@news.eternal-september.org...
>> What can Fortran do that C, C++, C# can't?
>>
>> Along similar lines where would Fortran be a superior chice over C, C+
>> +, or C#
>
> None that I know of.  Here is a dated (1992) paper comparing F77,
> F90, C and C++ for engineering pgrograms:
>    http://www.leshatton.org/Documents/JSX_0192.pdf
>
> Me, myself and I, we all prefer C++.  I like strong typing and
> mandatory function prototypes.  I also like function overloading.
>
> However, I find that the programmer is more important than the
> language.  Good programmers can write good code in any language.
> Bad programmers can screw anything up.
>
> Lynn 

On Tue, 29 Jun 2010 13:44:49 -0700, "Steve Fry" <scfry@raytheon.com>
wrote:

>"rfengineer55"  asked this question:
>> What can Fortran do that C, C++, C# can't?
>>
>> Along similar lines where would Fortran be a superior chice over C, C+
>> +, or C#
>>
>
>Since the CPUs on todays computers are not getting any faster (as was 
>promised 20 years ago), my main concern is what will crunch numbers faster.
>


Based on what criteria ?
The last time I checked, Moore's law still holds.


Luka

 > I was wondering what fortran 77 you are using or have used?

We use Open Watcom F77, C and C++ for developing our simulator
kernel.  ( www.openwatcom.org )  We moved to the Watcom compilers
in 1992 after using the NDP 386 compilers for several years.  The
NDP compilers were horrible, they generated assembly language
which I had to hand tweak to fix bugs in the near/far jumps.

We will be moving to another compiler within a year or so.  Either
Visual Studio C++ or maybe the Absoft fortran compiler.

 > What would you suggest for a good reference book  for cross
 > referencing differences between the various Fortran extensions?

Dont know of one.  The Open Watcom F77 language manual
( http://www.openwatcom.org/ftp/manuals/current/f77lr.pdf ) has
an appendix A entitled "A. Open Watcom FORTRAN 77 Extensions to
Standard FORTRAN 77".

 > I normally rely on the"compatibility" settings in my compiler, but I
 > rather have a moe active understanding about what's being converted.

We use /save and /xfloat.  /save means save local variables
between subroutine calls and initialize them to zero.  /xfloat
means convert all single precision floating constants and
expressions to double precision.

Lynn

On 6/29/10 4:05 PM, Lynn McGuire wrote:
>>> However, I find that the programmer is more important than the
>>> language. Good programmers can write good code in any language.
>>> Bad programmers can screw anything up.
>>
>> Fortran programmers can write Fortran in any language. :-)
>
> I was waiting for that !
>
> Lynn
>
>
>
A long long time ago, my business partner worked with a guy
who was charged with writing a C compiler in C.  He was a
"computer science" guy, so he thought in Pascal instead of C
(I said a long long time ago).  He spent the first few
whatevers of his time developing a whole slew of macros and
#define things and then wrote his part of the C compiler in
"pascal" and let cpp do the interesting part.  We made
some money doing the debugging!

Dick Hendrickson

On 6/29/10 3:44 PM, Steve Fry wrote:
> "rfengineer55"  asked this question:
>> What can Fortran do that C, C++, C# can't?
>>
>> Along similar lines where would Fortran be a superior chice over C, C+
>> +, or C#
>>
>
> Since the CPUs on todays computers are not getting any faster (as was
> promised 20 years ago), my main concern is what will crunch numbers faster.
>
> So which compiler or language is best suited for faster processing?
>
Almost without exception, the language you understand best.  Unless you
are doing time-critical stuff (weather forecasting, missile
interception, etc.) your time (and the time of the guy who has to
understand your code next year) is much more valuable than the
computer time.  Almost always, computer programs should be viewed
as human-to-human communication.  It's a good idea to plan on at
least one of those humans as being not real bright and to go for
clarity.

Dick Hendrickson
> -- Steve F.
>
>

On 2010-06-29 21:04:16 -0300, Dick Hendrickson <dick.hendrickson@att.net> said:

> On 6/29/10 3:44 PM, Steve Fry wrote:
>> "rfengineer55"  asked this question:
>>> What can Fortran do that C, C++, C# can't?
>>> 
>>> Along similar lines where would Fortran be a superior chice over C, C+
>>> +, or C#
>>> 
>> 
>> Since the CPUs on todays computers are not getting any faster (as was
>> promised 20 years ago), my main concern is what will crunch numbers faster.
>> 
>> So which compiler or language is best suited for faster processing?
>> 
> Almost without exception, the language you understand best.  Unless you
> are doing time-critical stuff (weather forecasting, missile
> interception, etc.) your time (and the time of the guy who has to
> understand your code next year) is much more valuable than the
> computer time.  Almost always, computer programs should be viewed
> as human-to-human communication.  It's a good idea to plan on at
> least one of those humans as being not real bright and to go for
> clarity.

All too often the not too bright guy is the original author about 20 
minutes later!

As in, Why did I do that?

> Dick Hendrickson
>> -- Steve F.

>> Almost without exception, the language you understand best. Unless you
>> are doing time-critical stuff (weather forecasting, missile
>> interception, etc.) your time (and the time of the guy who has to
>> understand your code next year) is much more valuable than the
>> computer time. Almost always, computer programs should be viewed
>> as human-to-human communication. It's a good idea to plan on at
>> least one of those humans as being not real bright and to go for
>> clarity.
>
> All too often the not too bright guy is the original author about 20 minutes later!
>
> As in, Why did I do that?

Or worse yet, the original author 10 years later <g> !
"There is no way I wrote that crappy code".

Lynn

"Phillip Helbig---undress to reply" <helbig@astro.multiCLOTHESvax.de> wrote in message news:i0c02e$cb0$2@online.de...
| In article <i0b9nl$809$1@news.eternal-september.org>, Lynn McGuire
| <lmc@winsim.com> writes:
|
| > However, I find that the programmer is more important than the
| > language.  Good programmers can write good code in any language.
| > Bad programmers can screw anything up.
|
| Fortran programmers can write Fortran in any language.  :-)

You can say that again!

A good example is ACM Algorithm 306. 

On Jun 29, 5:34=A0pm, Gordon Sande <Gordon.Sa...@gmail.com> wrote:
> On 2010-06-29 21:04:16 -0300, Dick Hendrickson <dick.hendrick...@att.net>=
 said:
>
>
>
> > On 6/29/10 3:44 PM, Steve Fry wrote:
> >> "rfengineer55" =A0asked this question:
> >>> What can Fortran do that C, C++, C# can't?
>
> >>> Along similar lines where would Fortran be a superior chice over C, C=
+
> >>> +, or C#
>
> >> Since the CPUs on todays computers are not getting any faster (as was
> >> promised 20 years ago), my main concern is what will crunch numbers fa=
ster.
>
> >> So which compiler or language is best suited for faster processing?
>
> > Almost without exception, the language you understand best. =A0Unless y=
ou
> > are doing time-critical stuff (weather forecasting, missile
> > interception, etc.) your time (and the time of the guy who has to
> > understand your code next year) is much more valuable than the
> > computer time. =A0Almost always, computer programs should be viewed
> > as human-to-human communication. =A0It's a good idea to plan on at
> > least one of those humans as being not real bright and to go for
> > clarity.
>
> All too often the not too bright guy is the original author about 20
> minutes later!
>
> As in, Why did I do that?
>

No kidding!  I was debugging a piece of code I wrote a few
years ago, and came across 8 to 10  lines of "clever" code
for linear interpolation.  It took me half a day to remember
how the code worked.  There was comment in front of those
lines of code, which is even much longer than previous. :-)

--
steve

"Louis Krupp" <lkrupp_nospam@indra.com.invalid> wrote in message news:Wu-dnaeciddxx7fRnZ2dnUVZ_g6dnZ2d@indra.net...
| On 6/29/2010 2:13 PM, rfengineer55 wrote:
| <snip>
| > It
| > would appear from what's been posted here, that there really isn't
| > anything Fortran can do than the others can't.
|
| Or vice versa.

It's a question of how well it can be done,
and how easy it is to do. 

"Louis Krupp" <lkrupp_nospam@indra.com.invalid> wrote in message news:A6ydnb_IMP5nzrfRnZ2dnUVZ_rKdnZ2d@indra.net...

| In C++, you can write a class to implement a multidimensional array.  Or
| you can download a Boost library:
|
| http://www.boost.org
|
| I've read some of the documentation.  At first glance, this appears to
| be nontrivial.  I suspect that simple cases would be easier to code in
| Fortran.
|
| FWIW, ALGOL let the programmer specify lower bounds long before Fortran.

And PL/I, BASIC, etc, etc. 

"Lynn McGuire" <lmc@winsim.com> wrote in message news:i0do2r$pt4$1@news.eternal-september.org...
|> There are many Fortran compilers written in C, as far as I know,
| > no C compilers written in Fortran.
|
| If the old Prime computers had a C compiler, it was probably
| written in Fortran.  The whole operating system was written in
| a heavily extended fortran 66 until the 198? release which was
| rewritten in PL/1.

That's interesting. 

"Steve Fry" <scfry@raytheon.com> wrote in message news:7XsWn.305$5N3.154@bos-service2b.ext.ray.com...
| "rfengineer55"  asked this question:
| > What can Fortran do that C, C++, C# can't?
| >
| > Along similar lines where would Fortran be a superior chice over C, C+
| > +, or C#
|
| Since the CPUs on todays computers are not getting any faster (as was
| promised 20 years ago), my main concern is what will crunch numbers faster.

They actually are getting faster.

| So which compiler or language is best suited for faster processing? 

On 6/29/2010 3:05 PM, Lynn McGuire wrote:
>>> However, I find that the programmer is more important than the
>>> language. Good programmers can write good code in any language.
>>> Bad programmers can screw anything up.
>>
>> Fortran programmers can write Fortran in any language. :-)
>
> I was waiting for that !

I currently code mostly in C and C++.  I still usually use the letters 
'i' through 'n' to start integer variable names and the other letters 
for floating point variables.  Funny how that works.

Louis

On Tue, 29 Jun 2010 16:20:22 -0500, Lynn McGuire <lmc@winsim.com>
wrote:

>> There are many Fortran compilers written in C, as far as I know,
>> no C compilers written in Fortran.
>
>If the old Prime computers had a C compiler, it was probably
>written in Fortran.  The whole operating system was written in
>a heavily extended fortran 66 until the 198? release which was
>rewritten in PL/1.

It did have a C compiler whose principal merit was that porting
to it was a thorough test of the quality of your code.  Integers
were 32 bits; pointers to integers were 32 bits; pointers to
character arrays were 48 bits.  There were quite a few
eccentricities.  


Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Reality is real; words are real too.
However words are not reality.

In article <7hpk26508f5u9upi2llp267c2lsrik0e5l@4ax.com>,
 Luka Djigas <ldigas@get.rid.of.this.gmail.com> wrote:

> Based on what criteria ?
> The last time I checked, Moore's law still holds.

You know that Moor's law is about the number of transistors, not the 
speed of the clock, right?

$.02 -Ron Shepard

On Tue, 29 Jun 2010 23:54:02 -0500, Ron Shepard
<ron-shepard@NOSPAM.comcast.net> wrote:

>In article <7hpk26508f5u9upi2llp267c2lsrik0e5l@4ax.com>,
> Luka Djigas <ldigas@get.rid.of.this.gmail.com> wrote:
>
>> Based on what criteria ?
>> The last time I checked, Moore's law still holds.
>
>You know that Moor's law is about the number of transistors, not the 
>speed of the clock, right?
>
>$.02 -Ron Shepard

Yes but still, it has always served as a good indicator of
development.

helbig@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply)
writes:

>
> Fortran programmers can write Fortran in any language.  :-)
>
Hello,
just a small remark:
I remember this statement as
"Real Programmers write FORTRAN in any language".
Of course at that time "Real Programmers" usually meant Fortran
Programmers, but it was a more general description of old style
programmers. In this context Fortran means the "proper" tools for these
guys, who also
"don't write comments. The code was hard to write, it should be hard to
understand." 
Best wishes
Alois

-- 
Alois Steindl,                           Tel.: +43 (1) 58801 / 32558      
Inst. for Mechanics and Mechatronics     Fax.: +43 (1) 58801 / 32598
Vienna University of Technology,         A-1040 Wiedner Hauptstr. 8-10   

 On Wed, 30 Jun 2010 12:34:21 +1000, "robin" <robin51@dodo.com.au>
wrote:

>"Lynn McGuire" <lmc@winsim.com> wrote in message news:i0do2r$pt4$1@news.eternal-september.org...
>|> There are many Fortran compilers written in C, as far as I know,
>| > no C compilers written in Fortran.
>|
>| If the old Prime computers had a C compiler, it was probably
>| written in Fortran.  The whole operating system was written in
>| a heavily extended fortran 66 until the 198? release which was
>| rewritten in PL/1.
>
>That's interesting. 
>
The original OS was in the public domain. It was written in the R-Mode
instruction set, if I remember correctly.

The PR1MOS system was written in the V-Mode instruction set.

The C compiler did not get written until much later, in part because
the Pr1me machine addressed to 16 bit quantities originally.
Eventually a special instruction was added to permit easy byte
addressing. Eventually C was done in the I-Mode and X-Mode instruction
sets.

The system programming language in the 80s was SPL a PL/1 variant
a'la Multics. It had special system programming instructions and
syntax. It was initially in V-Mode.

There was an ANSI variant PL/1 as well.

In the 90s work was begun on a Modula variant as the system
programming language. A new OS was largely complete for an
X-Mode instruction set, but the company bought Computervision
and most development in the old Pr1me ceased.

Ed Feustel

Edward Feustel wrote:
>  On Wed, 30 Jun 2010 12:34:21 +1000, "robin" <robin51@dodo.com.au>
> wrote:
> 
>> "Lynn McGuire" <lmc@winsim.com> wrote in message news:i0do2r$pt4$1@news.eternal-september.org...
>> |> There are many Fortran compilers written in C, as far as I know,
>> | > no C compilers written in Fortran.
>> |
>> | If the old Prime computers had a C compiler, it was probably
>> | written in Fortran.  The whole operating system was written in
>> | a heavily extended fortran 66 until the 198? release which was
>> | rewritten in PL/1.
>>
>> That's interesting. 
>>
> The original OS was in the public domain. It was written in the R-Mode
> instruction set, if I remember correctly.
> 
> The PR1MOS system was written in the V-Mode instruction set.
> 
> The C compiler did not get written until much later, in part because
> the Pr1me machine addressed to 16 bit quantities originally.
> Eventually a special instruction was added to permit easy byte
> addressing. Eventually C was done in the I-Mode and X-Mode instruction
> sets.
> 
> The system programming language in the 80s was SPL a PL/1 variant
> a'la Multics. It had special system programming instructions and
> syntax. It was initially in V-Mode.
> 
> There was an ANSI variant PL/1 as well.
> 
> In the 90s work was begun on a Modula variant as the system
> programming language. A new OS was largely complete for an
> X-Mode instruction set, but the company bought Computervision
> and most development in the old Pr1me ceased.
> 
> Ed Feustel

Someone has a public-access PRIMOS system on emulated hardware - 
actuallt three systems with different PRIMOS releases.

Ron Shepard <ron-shepard@nospam.comcast.net> wrote:
(snip)
 
> Even though fortran does support these kinds of data structures, it is 
> often better to avoid them.  Allocatable arrays in fortran, for example, 
> have several advantages over the analogous pointer approach, and that is 
> often the preferred data type given the various options.  As far as I 
> know, even modern C does not support multidimensional allocatable 
> arrays, and it gives the programmer no control over the lower bounds 
> within the array, so it is some 30+ years behind fortran in some ways, 
> and 20+ years behind fortran in others.  I don't know about the latest 
> version of the other languages in this thread title in this respect.

I believe that C99 has variable dimension automatic arrays.
I haven't tried them yet.

-- glen

In article <i0fli7$hq9$1@speranza.aioe.org>,
 glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Ron Shepard <ron-shepard@nospam.comcast.net> wrote:
> (snip)
>  
> > Even though fortran does support these kinds of data structures, it is 
> > often better to avoid them.  Allocatable arrays in fortran, for example, 
> > have several advantages over the analogous pointer approach, and that is 
> > often the preferred data type given the various options.  As far as I 
> > know, even modern C does not support multidimensional allocatable 
> > arrays, and it gives the programmer no control over the lower bounds 
> > within the array, so it is some 30+ years behind fortran in some ways, 
> > and 20+ years behind fortran in others.  I don't know about the latest 
> > version of the other languages in this thread title in this respect.
> 
> I believe that C99 has variable dimension automatic arrays.
> I haven't tried them yet.

Can you allocate these multidimensional arrays with malloc() (or 
some other library routine) in the same routine that they are used?  
In older versions of C, malloc() would only allocate 1D arrays, and 
the programmer had to restort to various pointer tricks to mimic 
using it as a multidimensional array.  And some of those pointer 
tricks were, strictly speaking, illegal in the language. As I said 
before, claiming that as a "feature" of the language is like trying 
to make a liability sound like an asset.

$.02 -Ron Shepard

On 2010-06-30 12:50:38 -0300, Ron Shepard 
<ron-shepard@NOSPAM.comcast.net> said:

> In article <i0fli7$hq9$1@speranza.aioe.org>,
>  glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> 
>> Ron Shepard <ron-shepard@nospam.comcast.net> wrote:
>> (snip)
>> 
>>> Even though fortran does support these kinds of data structures, it is
>>> often better to avoid them.  Allocatable arrays in fortran, for example,
>>> have several advantages over the analogous pointer approach, and that is
>>> often the preferred data type given the various options.  As far as I
>>> know, even modern C does not support multidimensional allocatable
>>> arrays, and it gives the programmer no control over the lower bounds
>>> within the array, so it is some 30+ years behind fortran in some ways,
>>> and 20+ years behind fortran in others.  I don't know about the latest
>>> version of the other languages in this thread title in this respect.
>> 
>> I believe that C99 has variable dimension automatic arrays.
>> I haven't tried them yet.
> 
> Can you allocate these multidimensional arrays with malloc() (or
> some other library routine) in the same routine that they are used?
> In older versions of C, malloc() would only allocate 1D arrays, and
> the programmer had to restort to various pointer tricks to mimic
> using it as a multidimensional array.  And some of those pointer
> tricks were, strictly speaking, illegal in the language. As I said
> before, claiming that as a "feature" of the language is like trying
> to make a


> liability sound like an asset.

Have you ever talked to an accountant for a bank? Everything seems to get
turned on its head! Their loan to you is an asset for the bank, since it is
a liability for you and by double entry rules it has to be an asset on the
other end of the transaction. Banks call the money you deposit with them
liabilities under the same logic. It takes a bit of getting used to!

> $.02 -Ron Shepard

"Steve Fry" <scfry@raytheon.com> wrote in message
news:7XsWn.305$5N3.154@bos-service2b.ext.ray.com...
....
> Since the CPUs on todays computers are not getting any faster (as was
> promised 20 years ago), my main concern is what will crunch numbers
> faster.
....
> -- Steve F.

Steve, you must have a particular type of number crunching in mind.
Multi-core CPUs can perform certain types of number crunching (those that
benefit from parallel calculations) faster than CPUs with less cores.  My
hunch is that your statement is based on the use of only a one or two-core
CPU, or on code that was not written to use multiple cores, or on code that
gets little benefit from parallel processing (like legacy code written
without using a modern Fortran).  My suggestion is to test your statement by
writing a Fortran benchmark program that maximizes the use of a modern
Fortran, and vectored processing, and then compare the time of a "this year"
CPU (e.g., an AMD 12-core CPU) with one of a few years ago (e.g. a four-core
CPU).  If your job requires you to perform a lot of number crunching, and
your company is unwilling to provide you with a system with more than
four-cores, then I understand where your misconception about CPU speeds 
comes from.  Perhaps your statement would be true if you replaced "CPUs on 
todays computers" with "CPUs on today's cheapest computers".

Also, graphical CPUs (GPUs) have been demonstrably been getting faster--much
faster.  The latest AMD and NVidia GPUs are surpassing the teraflop barrier.
You may have been ignoring graphics number-crunching when you wrote your
statement, but that's where the big money is being focused (CGI and video
games).

My opinion on languages:  Use one that you are comfortable with, is suitable
for the job, and is maintainable.

-DStar

"Steve Fry" <scfry@raytheon.com> wrote in message
news:7XsWn.305$5N3.154@bos-service2b.ext.ray.com...
....
> Since the CPUs on todays computers are not getting any faster (as was
> promised 20 years ago), my main concern is what will crunch numbers
> faster.
....
> -- Steve F.

Steve, you must have a particular type of number crunching in mind.
Multi-core CPUs can perform certain types of number crunching (those that
benefit from parallel calculations) faster than CPUs with less cores.  My
hunch is that your statement is based on the use of only a one or two-core
CPU, or on code that was not written to use multiple cores, or on code that
gets little benefit from parallel processing (like legacy code written
without using a modern Fortran).  My suggestion is to test your statement by
writing a Fortran benchmark program that maximizes the use of a modern
Fortran, and vectored processing, and then compare the time of a "this year"
CPU (e.g., an AMD 12-core CPU) with one of a few years ago (e.g. a four-core
CPU).  If your job requires you to perform a lot of number crunching, and
your company is unwilling to provide you with a system with more than
four-cores, then I understand where your misconception about CPU speeds
comes from.  Perhaps your statement would be true if you replaced "CPUs on
todays computers" with "CPUs on today's cheapest computers".

Also, graphical CPUs (GPUs) have been demonstrably been getting faster--much
faster.  The latest AMD and NVidia GPUs are surpassing the teraflop barrier.
You may have been ignoring graphics number-crunching when you wrote your
statement, but that's where the big money is being focused (CGI and video
games).

My opinion on languages:  Use one that you are comfortable with, is suitable
for the job, and is maintainable.  I do not think that one particlar 
language stands out.

-DStar

>> BTW, in a case of non-strongly typed variable names, Lynn is a He.
>
> Darn. Darn. Darn. Now that you bring it to mind, I recall making that
> mistake before. I apologize. I'll try to avoid making that mistake a
> third time. Having once had the notion stuck in my mind, it tends to
> sneak back in.

No worries !  In fact, I have been on a personal campaign to get
the female users of "Lynn" to get more strongly typed by changing
their names to "Lynne".  My campaign has been a total and abject
utter failure though as none to date are willing to change <g>.

You would not believe how many letters I get to Ms. Lynn McGuire.
It is a clue that they are spam and do not even get opened.

Thanks,
Lynn

robin wrote:
> "Steve Fry" <scfry@raytheon.com> wrote in message news:7XsWn.305$5N3.154@bos-service2b.ext.ray.com...
> | "rfengineer55"  asked this question:
> | > What can Fortran do that C, C++, C# can't?
> | >
> | > Along similar lines where would Fortran be a superior chice over C, C+
> | > +, or C#
> |
> | Since the CPUs on todays computers are not getting any faster (as was
> | promised 20 years ago), my main concern is what will crunch numbers faster.
> 
> They actually are getting faster.
> 

Yes, indeed, they are, because more transistors *are* useful for 
speeding up even nominally serial code, and computer architects are 
still coming up with more clever ways to use them.

Which language is fastest?  Assembly language, along with a deep 
understanding of the hardware you are using.

Neither c nor Fortran is an adequate substitute for assembly language 
because you invariably have a compiler with its own idiosyncrasies 
between you and the hardware.

It makes no sense to pursue the language issue as a determinant of 
speed, because an important prerequisite, a deep understanding of the 
hardware being used, is usually lacking. If you have a deep 
understanding of the hardware, you can usually work around compiler 
idiosyncrasies.

Most people really aren't all *that* interested in raw speed, anyway, or 
they shouldn't be.  A more meaningful questions is: in which language 
can I get the most useful work done in a given amount of time?  Even 
that question isn't exactly on target, unless you don't care what 
happens to the code when it falls to someone other than you to maintain, 
extend, or even to use it.

I'm in a position now where my c skills are sharper than my Fortran 
skills, but I'm still thinking that Fortran is probably the better 
choice for many things I do.  I'm sure that, as others have pointed out, 
the various pros and cons have been aired ad nauseum, but I'm still 
curious as to what people think about and actually do with Fortran 
(particularly as opposed to c) right now.

Robert.

Alois Steindl wrote:
> helbig@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply)
> writes:
> 
>> Fortran programmers can write Fortran in any language.  :-)
>>
> Hello,
> just a small remark:
> I remember this statement as
> "Real Programmers write FORTRAN in any language".
> Of course at that time "Real Programmers" usually meant Fortran
> Programmers, but it was a more general description of old style
> programmers. In this context Fortran means the "proper" tools for these
> guys, who also
> "don't write comments. The code was hard to write, it should be hard to
> understand." 
> Best wishes
> Alois

AFAIK, the quotation originated in the letter to editor in Datamation 
years ago...a portion of the specific paragraph containing it follows--

"... Recently, however, a black cloud has formed on the Real Programmer 
horizon. It seems that some highly placed Quiche Eaters at the Defense 
Department decided that all Defense programs should be written in some 
grand unified language called "ADA" ((C), DoD). For a while, it seemed 
that ADA was destined to become a language that went against all the 
precepts of Real Programming-- a language with structure, a language 
with data types, strong typing, and semicolons. In short, a language 
designed to cripple the creativity of the typical Real Programmer. 
Fortunately, the language adopted by DoD had enough interesting features 
to make it approachable-- it's incredibly complex, includes methods for 
messing with the operating system and rearranging memory, and Edsger 
Dijkstra doesn't like it [6]. (Dijkstra, as I'm sure you know, was the 
author of "GOTOs Considered Harmful"-- a landmark work in programming 
methodology, applauded by Pascal Programmers and Quiche Eaters alike.) 
Besides, the determined Real Programmer can write Fortran programs in 
any language."

The url I have bookmarked for the fun of it is at that has the full text is

<http://www.pbm.com/~lindahl/real.programmers.html>

Enjoy!  :)

--

>> If the old Prime computers had a C compiler, it was probably
>> written in Fortran.  The whole operating system was written in
>> a heavily extended fortran 66 until the 198? release which was
>> rewritten in PL/1.
>
> It did have a C compiler whose principal merit was that porting
> to it was a thorough test of the quality of your code.  Integers
> were 32 bits; pointers to integers were 32 bits; pointers to
> character arrays were 48 bits.  There were quite a few
> eccentricities.

48 bit char pointer and 32 bit integer pointer, nasty !

When we ported our fortran to the IBM mainframe from the Univac 1108
in 1975, we ran into a major problem.  All of the machines that we
had supported to that date were 36 bits or more using 6 bit bytes.
So, our hollerith had 6HABCDEF all over the place.   We had to
change that to 4HABCD plus 2HEF.  It was a major effort to change.

Lynn

> Also, graphical CPUs (GPUs) have been demonstrably been getting faster--much
> faster.  The latest AMD and NVidia GPUs are surpassing the teraflop barrier.
> You may have been ignoring graphics number-crunching when you wrote your
> statement, but that's where the big money is being focused (CGI and video
> games).

I have been following CUDA ( http://developer.nvidia.com/page/home.html )
/ OpenCL ( http://www.khronos.org/opencl/ ) with high interest.  I have
noted that neither have a fortran interface though.

Lynn

On Jun 30, 12:48=A0pm, Lynn McGuire <l...@winsim.com> wrote:
>
> You would not believe how many letters I get to Ms. Lynn McGuire.
> It is a clue that they are spam and do not even get opened.
>

You should open some of them,they might not be spam.

I also thought that you might be female, as are all the other "Lynn"s
I've met. I was happy to see that more females were becoming Fortran
groupies(lol)! So the disclosure of your gender was a bit of a
disappointment.:-(

Back to the topic. Soon, with all the developments in Fortran, C (and
the rest) number crunching performance might just converge. I think
Dick Hendrickson got it right:

"Almost without exception, [use]the language you understand best.
Unless you are doing time-critical stuff "

agt

--
Freedom - no pane, all gaiGN!

Code Art Now
http://codeartnow.com
Email: agt@codeartnow.com

Hello,

On 2010-06-30 13:06:29 -0400, Lynn McGuire <lmc@winsim.com> said:
> 
> I have been following CUDA ( http://developer.nvidia.com/page/home.html )
> / OpenCL ( http://www.khronos.org/opencl/ ) with high interest.  I have
> noted that neither have a fortran interface though.

Since they have C interfaces, they have Fortran interfaces.
Interoperability with C is widely implemented.

The interesting part is the changing chips means changing semantics
part of programming them.

-- 
Cheers!

Dan Nagle

Dick Hendrickson wrote:
> On 6/29/10 3:44 PM, Steve Fry wrote:
>> "rfengineer55"  asked this question:
>>> What can Fortran do that C, C++, C# can't?
>>>
>>> Along similar lines where would Fortran be a superior chice over C, C+
>>> +, or C#
>>>
>>
>> Since the CPUs on todays computers are not getting any faster (as was
>> promised 20 years ago), my main concern is what will crunch numbers 
>> faster.
>>
>> So which compiler or language is best suited for faster processing?
>>
> Almost without exception, the language you understand best.  Unless you
> are doing time-critical stuff (weather forecasting, missile
> interception, etc.) your time (and the time of the guy who has to
> understand your code next year) is much more valuable than the
> computer time.  Almost always, computer programs should be viewed
> as human-to-human communication.  It's a good idea to plan on at
> least one of those humans as being not real bright and to go for
> clarity.

That "not real bright" human is you, next month.  Listen to the voice of 
experience.  :-]

Dick Hendrickson wrote:
> Almost always, computer programs should be viewed
> as human-to-human communication.

Yep. Source code tends to be "write-once, read-many-times" (paraphrased from "Pragmatic
Thinking and Learning: Refactor Your Wetware") as in the author writes it, and the
users/maintainers read it again and again to figure out wtfigo?

cheers,

paulv

On 6/30/2010 3:25 PM, Dan Nagle wrote:
> Hello,
>
> On 2010-06-30 13:06:29 -0400, Lynn McGuire <lmc@winsim.com> said:
>>
>> I have been following CUDA ( http://developer.nvidia.com/page/home.html )
>> / OpenCL ( http://www.khronos.org/opencl/ ) with high interest. I have
>> noted that neither have a fortran interface though.
>
> Since they have C interfaces, they have Fortran interfaces.
> Interoperability with C is widely implemented.
>
> The interesting part is the changing chips means changing semantics
> part of programming them.
>
Successful use of nvcc via iso_c_binding as well as via PGI cudafortran 
has been reported.  cudafortran falls short of full OpenMP 
functionality, in the versions I've seen, but still this hardly deserves 
the accusation of "no Fortran interface."
A lot of developer time is being devoted by multiple vendors in this area.
-- 
Tim Prince

Hello,

On 2010-06-30 18:33:16 -0400, Tim Prince <tprince@myrealbox.com> said:

> A lot of developer time is being devoted by multiple vendors in this area.

Agreed.

And a lot of standards committee's time as well.
J3 is spending a lot of time on "Further Interoperability with C"
and is working with the MPI Fortran binding subgroup.
The level of cooperation is excellent.  I expect the results
to be implemented rather quickly when published.

-- 
Cheers!

Dan Nagle

Paul van Delst wrote:
> Dick Hendrickson wrote:
>> Almost always, computer programs should be viewed
>> as human-to-human communication.
> 
> Yep. Source code tends to be "write-once, read-many-times" (paraphrased from "Pragmatic
> Thinking and Learning: Refactor Your Wetware") as in the author writes it, and the
> users/maintainers read it again and again to figure out wtfigo?

Or wtfitc

"Lynn McGuire" <lmc@winsim.com> wrote in message news:i0ft8s$qjn$1@news.eternal-september.org...
| >> If the old Prime computers had a C compiler, it was probably
| >> written in Fortran.  The whole operating system was written in
| >> a heavily extended fortran 66 until the 198? release which was
| >> rewritten in PL/1.
| >
| > It did have a C compiler whose principal merit was that porting
| > to it was a thorough test of the quality of your code.  Integers
| > were 32 bits; pointers to integers were 32 bits; pointers to
| > character arrays were 48 bits.  There were quite a few
| > eccentricities.
|
| 48 bit char pointer and 32 bit integer pointer, nasty !
|
| When we ported our fortran to the IBM mainframe from the Univac 1108
| in 1975, we ran into a major problem.  All of the machines that we
| had supported to that date were 36 bits or more using 6 bit bytes.
| So, our hollerith had 6HABCDEF all over the place.   We had to
| change that to 4HABCD plus 2HEF.  It was a major effort to change.

That's because the code wasn't written with portability in mind. 

Ron Shepard <ron-shepard@nospam.comcast.net> wrote:
(snip, I wrote)
 
>> I believe that C99 has variable dimension automatic arrays.
>> I haven't tried them yet.
 
> Can you allocate these multidimensional arrays with malloc() (or 
> some other library routine) in the same routine that they are used?  

> In older versions of C, malloc() would only allocate 1D arrays, and 
> the programmer had to restort to various pointer tricks to mimic 
> using it as a multidimensional array.  

Well, malloc() allocates memory, what you do with the allocated
memory is a different question.  In C terms, the question, then,
is the ability to have a pointer to two dimensional variable
sized data.  I don't know if C99 can do that or not.  You might
call it a trick, but the common method is an array of pointers,
which is legal and also advantageous when the memory needed isn't
rectangular.  It is a convenience of C that a reference to such
looks the same as a reference to a 2D array.  

It was also useful in the 80286 days when allocating arrays
bigger than 64K, but where each column was smaller than 64K.
I had programs running on OS/2 1.0 and 1.2 using many megabytes
easily, when most were running DOS in 640K.

> And some of those pointer 
> tricks were, strictly speaking, illegal in the language. As I said 
> before, claiming that as a "feature" of the language is like trying 
> to make a liability sound like an asset.

The trick used in "Numerical Recipes" so they could translate
their Fortran programs with 1 origin arrays to C without fixing
the origin is, strictly, illegal, though it works in just about 
all systems.  (As do many Fortran array tricks unless bounds 
checking is turned on.)

As I remember it, the PDP-11 Fortran compilers addressed 2D
arrays though an array of addresses, that being faster than
doing the multiply that was otherwise required.  For newer
hardware it is likely that a multiply is faster than a
memory reference.

-- glen

Lynn McGuire <lmc@winsim.com> wrote:
(snip)
 
> 48 bit char pointer and 32 bit integer pointer, nasty !
 
> When we ported our fortran to the IBM mainframe from the Univac 1108
> in 1975, we ran into a major problem.  All of the machines that we
> had supported to that date were 36 bits or more using 6 bit bytes.
> So, our hollerith had 6HABCDEF all over the place.   We had to
> change that to 4HABCD plus 2HEF.  It was a major effort to change.

Some might have instead used REAL*8 (or DOUBLE PRECISION).
It is convenient of S/360 not to normalize data on load
store operations.

-- glen

On 29.06.2010. 23:22, Colin Watters wrote:
> Here is an even more dated paper (1893) comparing Fortran and some other
> languages:

Jeez, I didn't know Fortran is *THAT* old :o)

--
Jugoslav
www.xeffort.com

In article <7XsWn.305$5N3.154@bos-service2b.ext.ray.com>,
Steve Fry <scfry@raytheon.com> wrote:
> "rfengineer55"  asked this question:
> > What can Fortran do that C, C++, C# can't?
> >
> > Along similar lines where would Fortran be a superior chice over C, C+
> > +, or C#
> >
> 
> Since the CPUs on todays computers are not getting any faster (as was 
> promised 20 years ago),

"As was promised"?  What am I not thinking of here?  (And why would
you believe a promise that single processors would continue to get
faster forever?)

Or maybe you mean that 20 years ago advocates of parallel computing
were already saying that there were limits on the speed of a single
processor, so the future was parallel?  That's what I remember,
and while it has taken longer than they might have thought,
we may be there now?

> my main concern is what will crunch numbers faster.
> 
> So which compiler or language is best suited for faster processing?

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

In article <ron-shepard-BBD726.10503830062010@forte.easynews.com>,
Ron Shepard  <ron-shepard@NOSPAM.comcast.net> wrote:
> In article <i0fli7$hq9$1@speranza.aioe.org>,
>  glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> 
> > Ron Shepard <ron-shepard@nospam.comcast.net> wrote:
> > (snip)
> >  
> > > Even though fortran does support these kinds of data structures, it is 
> > > often better to avoid them.  Allocatable arrays in fortran, for example, 
> > > have several advantages over the analogous pointer approach, and that is 
> > > often the preferred data type given the various options.  As far as I 
> > > know, even modern C does not support multidimensional allocatable 
> > > arrays, and it gives the programmer no control over the lower bounds 
> > > within the array, so it is some 30+ years behind fortran in some ways, 
> > > and 20+ years behind fortran in others.  I don't know about the latest 
> > > version of the other languages in this thread title in this respect.
> > 
> > I believe that C99 has variable dimension automatic arrays.
> > I haven't tried them yet.

Yes.  They're called VLAs ("variable-length arrays").  Simple
example below.  

> Can you allocate these multidimensional arrays with malloc() (or 
> some other library routine) in the same routine that they are used?  

No, they're not explicitly allocated, but automatic, meaning that
space for them is (as far as I know) allocated from the same pool
used for local variables -- typically "the stack".  That has its
advantages but also its disadvantages.

Indexing is still, again as far as I know, zero-based, which is
a pain. 

> In older versions of C, malloc() would only allocate 1D arrays, and 
> the programmer had to restort to various pointer tricks to mimic 
> using it as a multidimensional array.  And some of those pointer 
> tricks were, strictly speaking, illegal in the language. As I said 
> before, claiming that as a "feature" of the language is like trying 
> to make a liability sound like an asset.

Agreed.

Complete though terse example (which compiles with gcc under
Linux -- though you need the "-std=c99" flag):

#include <stdio.h>
#include <stdlib.h>

/* fill n by m array */
void fill(size_t n, size_t m, int a[m][n]) {
    for (int i = 0; i < n; ++i)
        for (int j = 0; j < m; ++j)
            a[i][j] = i+j;
}
/* print n by m array */
void print(size_t n, size_t m, int a[m][n]) {
    for (int i = 0; i < n; ++i) 
        for (int j = 0; j < m; ++j) 
            printf("a[%d][%d] = %d\n", i, j, a[i][j]);
}
/* main program */
/* command-line arguments n, m specify dimensions of array */
int main(int argc, char* argv[]) {
    /* error handling code for command-line arguments omitted */
    int n = atoi(argv[1]);
    int m = atoi(argv[2]);
    int a[n][m];
    fill(n, m, a);
    print(n, m, a);
    return 0;
}

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

"Ron Shepard" <ron-shepard@NOSPAM.comcast.net> wrote in message 
news:ron-shepard-AFCEBB.14012429062010@news60.forteinc.com...
| In article <Vu2dnZxfzsu_c7TRnZ2dnUVZ_gOdnZ2d@supernews.com>,
| "Gary L. Scott" <garylscott@sbcglobal.net> wrote:
|
| > > I would tend to believe that C, C++, and C# can do more than Fortran
| > > can do. Just an educated guess on my part.
| >
| > Many of those complex structures are ill-advised abominations.
|
| A good example of this is multidimensional arrays which I indicated
| earlier.  Since C did not allow these (except with constant dimensions,
| I think was the exception), everyone was forced to implement various
| hacks to work around this shortcoming of the language.

No-one is "forced" to use it.
There are other languages easily handle multiply-dimensioned arrays. 

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:i0grfv$ije$2@speranza.aioe.org...
| Lynn McGuire <lmc@winsim.com> wrote:
| (snip)
|
| > 48 bit char pointer and 32 bit integer pointer, nasty !
|
| > When we ported our fortran to the IBM mainframe from the Univac 1108
| > in 1975, we ran into a major problem.  All of the machines that we
| > had supported to that date were 36 bits or more using 6 bit bytes.
| > So, our hollerith had 6HABCDEF all over the place.   We had to
| > change that to 4HABCD plus 2HEF.  It was a major effort to change.
|
| Some might have instead used REAL*8 (or DOUBLE PRECISION).
| It is convenient of S/360 not to normalize data on load
| store operations.

The S/360 has nothing to do with the topic.
In any case, INTEGER would have provided an appropriate
choice. 

On Wed, 30 Jun 2010, Robert Myers sent:
|---------------------------------------------------|
|"[..]                                              |
|                                                   |
|Which language is fastest?  Assembly language, [..]|
|[..]                                               |
|                                                   |
|[..]"                                              |
|---------------------------------------------------|

VHDL produces even faster implementations.

On Wed, 30 Jun 2010, Lynn McGuire sent:
|-----------------------------------------------------------------|
|"[..]                                                            |
|                                                                 |
|You would not believe how many letters I get to Ms. Lynn McGuire.|
|It is a clue that they are spam and do not even get opened."     |
|-----------------------------------------------------------------|

Important mail for me which I wanted to read used to be addressed to
Mrs. C. P. Gloster. Though I am not female, a former employer referred
to me by a female pronoun in a letter of reference.

On Wed, 30 Jun 2010, Dogstar sent:
|----------------------------------------------------------------------------|
|""Steve Fry" <scfry@raytheon.com> wrote in message                          |
|news:7XsWn.305$5N3.154@bos-service2b.ext.ray.com...                         |
|...                                                                         |
|> Since the CPUs on todays computers are not getting any faster (as was     |
|> promised 20 years ago), my main concern is what will crunch numbers       |
|> faster.                                                                   |
|...                                                                         |
|> -- Steve F.                                                               |
|                                                                            |
|Steve, you must have a particular type of number crunching in mind.         |
|Multi-core CPUs [..]                                                        |
|----------------------------------------------------------------------------|

A "multi-core CPU" is a euphemism for many CPUs.

|----------------------------------------------------------------------------|
|"[..]                                                                       |
|                                                                            |
|Also, graphical CPUs (GPUs) have been demonstrably been getting faster--much|
|faster.  [..]                                                               |
|[..]                                                                        |
|                                                                            |
|[..]"                                                                       |
|----------------------------------------------------------------------------|

Fair enough.

Steve Fry wrote:
> "rfengineer55"  asked this question:
>> What can Fortran do that C, C++, C# can't?
>>
>> Along similar lines where would Fortran be a superior chice over C, C+
>> +, or C#
>>
> 
> Since the CPUs on todays computers are not getting any faster (as was 
> promised 20 years ago), my main concern is what will crunch numbers faster.
> 
> So which compiler or language is best suited for faster processing?

As couched, the answer to that question is "maybe"... :)

--

Colin Paul Gloster wrote:
> On Wed, 30 Jun 2010, Robert Myers sent:
> |---------------------------------------------------|
> |"[..]                                              |
> |                                                   |
> |Which language is fastest?  Assembly language, [..]|
> |[..]                                               |
> |                                                   |
> |[..]"                                              |
> |---------------------------------------------------|
> 
> VHDL produces even faster implementations.

Sometimes, if you are in a situation where an FPGA is a realistic option.

My point was that raw speed depends more on the hardware and your 
knowledge of how to exploit it than it does on choice of programming 
language, assuming that the choices in programming language all compile 
to native code.

This is not the place to discuss it, but, the need for a "portable 
assembler," such as c, is debatable, since so much now is x86.  VHDL is 
not a realistic option for most applications programmers, but x86 
assembler is.  That's what the people I know who really want to write 
fast code use, and, as for me, I'd rather read well-commented assembler 
than the typical c program.

Robert.

"Jugoslav Dujic" <jdujic@yahoo.com> wrote in message
news:i0hu98$ocp$1@speranza.aioe.org...
> On 29.06.2010. 23:22, Colin Watters wrote:
>> Here is an even more dated paper (1893) comparing Fortran and some other
>> languages:
>
> Jeez, I didn't know Fortran is *THAT* old :o)
>
> --
> Jugoslav
> www.xeffort.com

Real programmers do not need electronic computers to program in Fortran.

From the _The Big Book of FORTRAN Misinformation_:

In 1893 FORTRAN programmers (note the captialization) used steam-powered
computers (called "engines").  The memory was made out of chips of ram horn
(cf. RAM memory chips) that formed the cogs within the machine.  The early
FORTRAN language consisted only of three arithmetic operators ( -, *, and
**), the unary minus (-), the assignment operator (=), the arithmetic IF
instruction, and a SET/UNSET light instruction.  Because of the limited
number of arithmetic operators, addition was performed by subtracting the
negative of a number and division by mulitplying by a value taken to the -1
power (cf. "Real programmers don't need division").  The program was
transcribed into EBCDIC (Every Boy Can Decode IBM's Crazy) code and punched
onto loom cards.  The loom cards were used to re-initialized the cogs in the
machine (cf. "character recognition unit").

--Dogstar

>> You would not believe how many letters I get to Ms. Lynn McGuire.
>> It is a clue that they are spam and do not even get opened.
>
> You should open some of them,they might not be spam.

My full name is Michael Lynn McGuire.  Anything important
knows that first name.

Thanks,
Lynn

> This is not the place to discuss it, but, the need for a "portable assembler," such as c, is debatable, since so much now is x86.
> VHDL is not a realistic option for most applications programmers, but x86 assembler is. That's what the people I know who really want
> to write fast code use, and, as for me, I'd rather read well-commented assembler than the typical c program.

Actually, the most programmed platform nowadays is in the mobile
devices, notably the smart phones, which are mostly the ARM cpu.
    http://en.wikipedia.org/wiki/ARM_architecture
    http://www.arm.com/about/newsroom/19720.php
The ARM cpu is a RISC architecture and has it's own assembler
language that is not x86 compatible.

Lynn

Gib Bogle wrote:
> 
> Paul van Delst wrote:
> > Dick Hendrickson wrote:
> >> Almost always, computer programs should be viewed
> >> as human-to-human communication.
> >
> > Yep. Source code tends to be "write-once, read-many-times" (paraphrased from "Pragmatic
> > Thinking and Learning: Refactor Your Wetware") as in the author writes it, and the
> > users/maintainers read it again and again to figure out wtfigo?
> 
> Or wtfitc

c??  N >> 1 !!

Lynn McGuire wrote:

> 
> Actually, the most programmed platform nowadays is in the mobile
> devices, notably the smart phones, which are mostly the ARM cpu.
>    http://en.wikipedia.org/wiki/ARM_architecture
>    http://www.arm.com/about/newsroom/19720.php
> The ARM cpu is a RISC architecture and has it's own assembler
> language that is not x86 compatible.
> 

I had made the naive assumption that someone asking about Fortran was 
not programming a smart phone.

Conceivably, there are DSP people out there who might be interested in 
Fortan and programming something other than x86.  If you're interested 
in speed, no matter the context, I stand by my comments.

As to describing an "architecture" (as opposed to the ISA) as "RISC," I 
think we are living on different planets.

Robert.

> =A0glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> I believe that C99 has variable dimension automatic arrays.
> I haven't tried them yet.

> Ron Shepard <ron-shep...@nospam.comcast.net> wrote:
> Can you allocate these multidimensional arrays with malloc() (or
> some other library routine) in the same routine that they are used?

Below is an example of a dynamically allocated C99 2D variable length
array using gcc. (As I wrote it, I realized that I ought to remember
to be more grateful for the ability to write something like "print *,
parray" in Fortran.) Note that once you have created such an array, if
you want to pass it as an actual argument to another function, you the
programmer must pass the bounds along with the array. In Fortran
terms, C99 added adjustable arrays to the assumed-size arrays which it
inherited from K&R C, but still does not provide assumed-shape or
deferred-shape arrays. In compiler-implementation terms, a C99 pointer
to a variable length array is still a simple memory address, not a
dope vector containing information about the array bounds.

#include <stdio.h>
#include <stdlib.h>

int
main(int argc, char **argv) {
  int xdim =3D argc;
  int ydim =3D argc + 1;
  float (*parray)[xdim][ydim] =3D malloc(xdim * ydim * sizeof(float));
  for (int x =3D 0; x < xdim; x +=3D 1) {
    for (int y =3D 0; y < ydim; y +=3D 1) {
      (*parray)[x][y] =3D 10 * x + y;
      }
    }
  for (int x =3D 0; x < xdim; x +=3D 1) {
    for (int y =3D 0; y < ydim; y +=3D 1) {
      printf("%g ", (*parray)[x][y]);
      }
    printf("\n");
    }
  return 0;
  }

$ gcc ctest.c -std=3Dc99
$ ./a.out
0 1
$ ./a.out 1
0 1 2
10 11 12
$ ./a.out 1 2
0 1 2 3
10 11 12 13
20 21 22 23

On 7/1/2010 7:26 AM, robin wrote:
> "glen herrmannsfeldt"<gah@ugcs.caltech.edu>  wrote in message news:i0grfv$ije$2@speranza.aioe.org...
> | Lynn McGuire<lmc@winsim.com>  wrote:
> | (snip)
> |
> |>  48 bit char pointer and 32 bit integer pointer, nasty !
> |
> |>  When we ported our fortran to the IBM mainframe from the Univac 1108
> |>  in 1975, we ran into a major problem.  All of the machines that we
> |>  had supported to that date were 36 bits or more using 6 bit bytes.
> |>  So, our hollerith had 6HABCDEF all over the place.   We had to
> |>  change that to 4HABCD plus 2HEF.  It was a major effort to change.
> |
> | Some might have instead used REAL*8 (or DOUBLE PRECISION).
> | It is convenient of S/360 not to normalize data on load
> | store operations.
>
> The S/360 has nothing to do with the topic.
> In any case, INTEGER would have provided an appropriate
> choice.
>
>

Not if you want to store an eight-byte string in one variable;  then you 
need double precision.

Burroughs Large Systems also didn't normalize floating point data under 
at least certain circumstances.  Many years ago, I ported a 3-D 
perspective plot package, PUREJOY, from CDC (6600?) to a B6700.  Early 
plots had weird spikes which came from the meta-data (for lack of a 
better term) that the CDC code put in the low-order three or so bits of 
coordinates.  The CDC apparently normalized these variables so the 
low-order bits didn't change the value much, but the B6700 FORTRAN code 
had to be told to force normalization somehow (the instruction set 
included a NRML operator or something, but I don't recall how I did this 
in FORTRAN) before diddling with the low-order bits.

Louis

Steven Correll <steven.correll@gmail.com> wrote:
>> �glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> I believe that C99 has variable dimension automatic arrays.
>> I haven't tried them yet.
 
>> Ron Shepard <ron-shep...@nospam.comcast.net> wrote:
>> Can you allocate these multidimensional arrays with malloc() (or
>> some other library routine) in the same routine that they are used?
 
> Below is an example of a dynamically allocated C99 2D variable length
> array using gcc. (As I wrote it, I realized that I ought to remember
> to be more grateful for the ability to write something like "print *,
> parray" in Fortran.) 

I find it interesting that PRINT was in Fortran I and Fortran II,
but removed during the change to Fortran IV and Fortran 66, then
added back later.  (Though the older form required a format
statement number, with no option for *.

> Note that once you have created such an array, if
> you want to pass it as an actual argument to another function, you the
> programmer must pass the bounds along with the array. In Fortran
> terms, C99 added adjustable arrays to the assumed-size arrays which it
> inherited from K&R C, but still does not provide assumed-shape or
> deferred-shape arrays. In compiler-implementation terms, a C99 pointer
> to a variable length array is still a simple memory address, not a
> dope vector containing information about the array bounds.

Note though, at least as far as I can tell, the dimensions
need to be known at block entry, similar to Fortran 66 adjustable
arrays, though with the ability to allocate them.
 
> #include <stdio.h>
> #include <stdlib.h>
 
> int
> main(int argc, char **argv) {
>  int xdim = argc;
>  int ydim = argc + 1;
>  float (*parray)[xdim][ydim] = malloc(xdim * ydim * sizeof(float));

It might be a little less confusing, especially to those who
don't do a lot of C programming, to write it as:

  float (*parray)[xdim][ydim];
  parray = malloc(xdim * ydim * sizeof(float));

Specifically, it declares a pointer to a 2D array, and then
allocates memory for the pointer.

Also, for Fortran programmers not so used to C,

float *x[3][3];     // declares a 2D array of pointers
float (*x)[3][3];   // declares a pointer to a 2D array
float (*x[3])[3];   // declares an array of pointer to arrays

>  for (int x = 0; x < xdim; x += 1) {
>    for (int y = 0; y < ydim; y += 1) {
>      (*parray)[x][y] = 10 * x + y;
>      }
>    }
>  for (int x = 0; x < xdim; x += 1) {
>    for (int y = 0; y < ydim; y += 1) {
>      printf("%g ", (*parray)[x][y]);
>      }
>    printf("\n");
>    }
>  return 0;
>  }

And note that you really don't need C99, all you need is cpp:

#define x(i,j) (*(x+((i)-1)*(n)+(j)-1))

which, unless I typed wrong, gets you a variable dimension,
origin 1, allocatable and changable dimension array that you even
reference like a Fortran array.

Or, to be even more Fortran like:

#define x(i,j) (*(x+((j)-1)*(n)+(i)-1))


-- glen

Louis Krupp <lkrupp_nospam@indra.com.invalid> wrote:
 
> Not if you want to store an eight-byte string in one variable;  
> then you need double precision.  

It seems that Robin missed that part.
 
> Burroughs Large Systems also didn't normalize floating point data under 
> at least certain circumstances.  Many years ago, I ported a 3-D 
> perspective plot package, PUREJOY, from CDC (6600?) to a B6700.  Early 
> plots had weird spikes which came from the meta-data (for lack of a 
> better term) that the CDC code put in the low-order three or so bits of 
> coordinates.  The CDC apparently normalized these variables so the 
> low-order bits didn't change the value much, but the B6700 FORTRAN code 
> had to be told to force normalization somehow (the instruction set 
> included a NRML operator or something, but I don't recall how I did this 
> in FORTRAN) before diddling with the low-order bits.

There are some Burroughs machines that store integer and floating
point in the same format.  The exponent is arranged such that it
is zero for an appropriately unnormalized integer value, and 
is the prefered exponent result if no bits are lost.

Fortunately Fortran leaves the results of overflow undefined,
as users of those machines will be very surprised.

-- glen

Robert Myers <rbmyersusa@gmail.com> wrote:
(snip)
 
> This is not the place to discuss it, but, the need for a "portable 
> assembler," such as c, is debatable, since so much now is x86.  VHDL is 
> not a realistic option for most applications programmers, but x86 
> assembler is.  That's what the people I know who really want to write 
> fast code use, and, as for me, I'd rather read well-commented assembler 
> than the typical c program.

I have written assembler for many machines and x86 is my least
favorite.  Well, I haven't written much for RISC machines,
such as Sparc and HP-PA, but I think I would still prefer
them over x86.  

-- glen

On Tue, 29 Jun 2010 16:05:41 -0500, Lynn McGuire <lmc@winsim.com>
wrote:

>>> However, I find that the programmer is more important than the
>>> language.  Good programmers can write good code in any language.
>>> Bad programmers can screw anything up.
>>
>> Fortran programmers can write Fortran in any language.  :-)
>
>I was waiting for that !

Well they can... And do...

For my sins I have worked for a compiler company where the senior
developer came for a Fortran background.  The C compiler was written
in C but the mind set was definitely Fortran.  After 3 months working
on the C preprocessor I remember taking time out to refactor using
these strange things called loops and other magical and mystical
constructs.

Cheers,
Mark
-- 
       |\      _,,,---,,_          A picture used to be worth a
ZZZzzz /,`.-'`'    -.  ;-;;,       thousand words - then along
      |,4-  ) )-,_. ,\ (  `'-'     came television!
     '---''(_/--'  `-'\_)          

Mark Stevens  (mark at thepcsite fullstop co fullstop uk)

This message is provided "as is".

On Wed, 30 Jun 2010 12:34:21 +1000, "robin" <robin51@dodo.com.au>
wrote:

>"Lynn McGuire" <lmc@winsim.com> wrote in message news:i0do2r$pt4$1@news.eternal-september.org...
>|> There are many Fortran compilers written in C, as far as I know,
>| > no C compilers written in Fortran.
>|
>| If the old Prime computers had a C compiler, it was probably
>| written in Fortran.  The whole operating system was written in
>| a heavily extended fortran 66 until the 198? release which was
>| rewritten in PL/1.

Salford's FORTRAN 77 compiler for the Prime was written in Fortran and
I believe that their Prolog compiler was also written in Fortran.

Cheers,
Mark
-- 
       |\      _,,,---,,_          A picture used to be worth a
ZZZzzz /,`.-'`'    -.  ;-;;,       thousand words - then along
      |,4-  ) )-,_. ,\ (  `'-'     came television!
     '---''(_/--'  `-'\_)          

Mark Stevens  (mark at thepcsite fullstop co fullstop uk)

This message is provided "as is".

glen herrmannsfeldt wrote:
> Robert Myers <rbmyersusa@gmail.com> wrote:
> (snip)
>  
>> This is not the place to discuss it, but, the need for a "portable 
>> assembler," such as c, is debatable, since so much now is x86.  VHDL is 
>> not a realistic option for most applications programmers, but x86 
>> assembler is.  That's what the people I know who really want to write 
>> fast code use, and, as for me, I'd rather read well-commented assembler 
>> than the typical c program.
> 
> I have written assembler for many machines and x86 is my least
> favorite.  Well, I haven't written much for RISC machines,
> such as Sparc and HP-PA, but I think I would still prefer
> them over x86.  
> 

But that just transfers the discussion from language wars to ISA wars. 
No one has gotten much out of any of those wars.

If fast code is your priority, you need to understand the hardware and 
write in assembly language for the actual hardware you are using.

There are some issues about c and Fortran and how readily they can be 
optimized without hand recoding, but I assume those issues have all been 
thoroughly aired in this forum.

I frequently find code written in c to be nearly unreadable.  That's a 
more important consideration to me than speed.

If speed is your concern, then you should be using assembler, and, if 
readability of your assembler is concerned, you should comment your work 
so as to leave nothing to the imagination of whoever comes after you. 
That advice would go for coding in c, too, but most c coders appear to 
be beyond redemption.

If you are doing certain kinds of work, Fortran will probably produce 
more readable code than c.  If you are doing other kinds of work, the 
opposite will likely be true.

Robert.

In article <i0hu98$ocp$1@speranza.aioe.org>, Jugoslav Dujic
<jdujic@yahoo.com> writes: 

> On 29.06.2010. 23:22, Colin Watters wrote:
> > Here is an even more dated paper (1893) comparing Fortran and some other
> > languages:
> 
> Jeez, I didn't know Fortran is *THAT* old :o)

FORTRAN IV even had a Roman numeral.  :-)

Robert Myers <rbmyersusa@gmail.com> wrote:
(snip, I wrote)
 
>> I have written assembler for many machines and x86 is my least
>> favorite.  

> But that just transfers the discussion from language wars to ISA wars. 
> No one has gotten much out of any of those wars.

That should be true, but I don't think it is.

I think the parts I don't like about x86 assembler are more 
the way the MS assemblers work than the ISA itself.  
The ways you specify address modes, for example.  

-- glen

Steven Correll wrote:

> #include <stdio.h>
> #include <stdlib.h>
> 
> int
> main(int argc, char **argv) {
>   int xdim = argc;
>   int ydim = argc + 1;
>   float (*parray)[xdim][ydim] = malloc(xdim * ydim * sizeof(float));
>   for (int x = 0; x < xdim; x += 1) {
>     for (int y = 0; y < ydim; y += 1) {
>       (*parray)[x][y] = 10 * x + y;
>       }
>     }
>   for (int x = 0; x < xdim; x += 1) {
>     for (int y = 0; y < ydim; y += 1) {
>       printf("%g ", (*parray)[x][y]);
>       }
>     printf("\n");
>     }
>   return 0;
>   }

It's a bit inconvenient that an array element must be accessed as 
(*parray)[x][y], and also a bit confusing since this is not required in the case 
of the old 1-D array.
   float (*b)[10] = malloc(10*sizeof(float));
and
   float *b = malloc(10*sizeof(float));
have the same effect, but in the latter case the elements are accessed by b[i], 
while in the former by (*b)[i].

Phillip Helbig wrote:
> In article <i0hu98$ocp$1@speranza.aioe.org>, Jugoslav Dujic
><jdujic@yahoo.com> writes: 
>
>> On 29.06.2010. 23:22, Colin Watters wrote:
>> > Here is an even more dated paper (1893) comparing Fortran and some other
>> > languages:
>> 
>> Jeez, I didn't know Fortran is *THAT* old :o)
>
> FORTRAN IV even had a Roman numeral.  :-)

The nice thing about Roman numbers is that you can't have a division by
zero error.

On 2010-07-01, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> I have written assembler for many machines and x86 is my least
> favorite.

Ever written assembler for 6502? ;-)

Thomas Koenig <tkoenig@netcologne.de> wrote:
> On 2010-07-01, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
 
>> I have written assembler for many machines and x86 is my least
>> favorite.
 
> Ever written assembler for 6502? ;-)

S/360, S/370, PDP-10, PDP-11, VAX, 6809, but not much 6502.
I did write a disassembler for 6502, though, and I do remember
some interesting things about the instruction set.

But most of my complaints about x86 are with the assembler
itself, and not so much the instruction set.  I am not sure
by now how much of that is Intel, MS, or others along the way.

The 6502 doesn't have that many addressing modes, which reduces
the ways to go wrong in the assembler.  The one I remember is
that subroutine calls push one less than the address of the
next instruction on the stack, and return goes to one more
than the address it pops off.  You see this with jump tables
that push an address from a table on the stack, and then RET.
All the table entries are off by one.

-- glen

Thomas Koenig <tkoenig@netcologne.de> wrote:

> On 2010-07-01, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> 
> > I have written assembler for many machines and x86 is my least
> > favorite.
> 
> Ever written assembler for 6502? ;-)

I have. I don't recall it as being particularly bad. Not very powerful,
but easy enough. In fact, I've even written "machine language" for it in
a context where I didn't have an asembler available. That was for a
hobby project that I once did quite a while ago. I put together a
computer of sorts on a pair of breadboards. One breadboard was a "video
card" using a 6845 video controller. The other was CPU, RAM, PROM, and a
parallel I/O controller for a keyboard. I had a commercial keyboard and
monitor. I'd burn my programs into the prom without benefit of an
assembler. Never did anything serious with it; just played around.

I might also note that I find it a pretty narrow viewpoint to assume, s
one poster seems to do, that Fortran code is going to be targetting x86.
I've written Fortran code for an awful lot of systems, x86 being in a
minority. As I'm now retired and have only my home systems, the X86
fraction has gone way up, but it was a minority when I was working for a
living, which wasn't that awfully many years ago. At home, my Apple 2e
still works, but I seldom drag it out and haven't programmed for it in a
long time. I do have a PPC Mac mini, but I don't program for it.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

> I might also note that I find it a pretty narrow viewpoint to assume, s
> one poster seems to do, that Fortran code is going to be targetting
> x86.

I completely agree. Even without talking of assembler, I write and
compile Fortran code at least on x86, powerpc, sparc, ia64 and arm
processors.

Oh, and NEC SX-8 ;-)
though gfortran/gcc doesn't target it

-- 
FX

On Jul 3, 8:16=A0pm, "FX" <coud...@alussinan.org> wrote:
> > I might also note that I find it a pretty narrow viewpoint to assume, s
> > one poster seems to do, that Fortran code is going to be targetting
> > x86.
>
> I completely agree. Even without talking of assembler, I write and
> compile Fortran code at least on x86, powerpc, sparc, ia64 and arm
> processors.
>
> Oh, and NEC SX-8 ;-)
> though gfortran/gcc doesn't target it

Yeah, that's really bad, as there's no good Fortran Compiler for the
SX series.  I mean, no Compiler supporting Fortran 2003 and later.
NEC unfortunately refuses to modernize their compiler.  I still do
hope
that they will change their mind.
(Concerning raw performance, these machines are quite interesting).

Harald

> Yeah, that's really bad, as there's no good Fortran Compiler for the SX
> series.  I mean, no Compiler supporting Fortran 2003 and later.

You can always look at sx-gcc (http://code.google.com/p/sx-gcc/).

> Concerning raw performance, these machines are quite interesting.

Yes, but they require code a bit of code tuning to get the best of the
vector pipeline.

-- 
FX

On Jul 3, 10:17=A0pm, "FX" <coud...@alussinan.org> wrote:
> > Yeah, that's really bad, as there's no good Fortran Compiler for the SX
> > series. =A0I mean, no Compiler supporting Fortran 2003 and later.
>
> You can always look at sx-gcc (http://code.google.com/p/sx-gcc/).

Nice!  ;-)
Although gcc-4.2 did not provide much of Fortran 2003.

> > Concerning raw performance, these machines are quite interesting.
>
> Yes, but they require code a bit of code tuning to get the best of the
> vector pipeline.

Right.  But the detailed performance diagnostics you get with ftrace
is
very useful to get you there.  I still have to find anything close on
a
Linux system.

Harald

"Thomas Koenig" <tkoenig@netcologne.de> wrote in message 
news:i0nnhn$fb0$2@newsreader5.netcologne.de...
> On 2010-07-01, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>
>> I have written assembler for many machines and x86 is my least
>> favorite.
>
> Ever written assembler for 6502? ;-)

Yes, quite a lot of it. That chip had two major advantages. The first was 
zero page addressing. The second was that each memory access took 1 cycle. 
So a 1 MHz 6502 is about as fast as a 4 MHz Z80. [Yes I can still assemble 
small programs in hex by hand mostly from memory.]

As for Fortran vs other languages:

1. I know Fortran but only a bit of C.
2. Arrays.
3. Look at some of the problem programs posted in this newsgroup. Some of 
the code posted looks like a naive attempt to translate mathematical 
formulas into a programming language. But that's exactly what the language 
was designed for (minus the naivete). [See my discussion of a program by 
Eric and how it could have been improved, for example.]

[On soapbox]
So it bothers me when I read postings from graduates in science or 
engineering who have never used Fortran at all. Instead they may have used 
something like MATLAB. What are they missing?
1. The vast literature of existing programs written in Fortran. This also 
includes the algorithms expressed in Fortran.
2. A better understanding of the limitations of numeric computation, 
including floating point numbers, etc.
3. The ability to express themselves in a common language that is well 
understood.
4. The problems with a black box approach to problems. [When was the last 
time you saw Newton's method fall completely on its head? How about solving 
problems with the auto-solver of a modern calculator?]
[Off soapbox]

Elliot

Richard Maine wrote:

> 
> I might also note that I find it a pretty narrow viewpoint to assume, s
> one poster seems to do, that Fortran code is going to be targetting x86.
> I've written Fortran code for an awful lot of systems, x86 being in a
> minority. As I'm now retired and have only my home systems, the X86
> fraction has gone way up, but it was a minority when I was working for a
> living, which wasn't that awfully many years ago. At home, my Apple 2e
> still works, but I seldom drag it out and haven't programmed for it in a
> long time. I do have a PPC Mac mini, but I don't program for it.

I'm the one poster, and I'm going to do my best not to be snarky.

The Department of Energy is determined to keep Power and IBM in HPC, so 
some Fortran will be always be targeting Power unless and until the 
Department of Energy and/or IBM abandon their alliance.

ARM is an interesting potential player in HPC.  For the moment though, 
the key word is potential.

With those exceptions, the economics of high-end fabs pretty much 
dictate the future.  We are headed toward chip monoculture and writing 
in x86 assembler is a pretty good bet for most people.

If specialized stream processors (variants of graphics chips or similar) 
play a role, conventional Fortran will not be targeting them.

So what if you've got a million war stories of programming something 
else in the past?  That's exactly what the past is: past.  Affordable 
high-end chips are going to be x86 for the foreseeable future.

Robert.

On 7/3/2010 9:27 PM, e p chandler wrote:
<snip>
> [On soapbox]
> So it bothers me when I read postings from graduates in science or
> engineering who have never used Fortran at all. Instead they may have
> used something like MATLAB. What are they missing?
> 1. The vast literature of existing programs written in Fortran. This
> also includes the algorithms expressed in Fortran.
> 2. A better understanding of the limitations of numeric computation,
> including floating point numbers, etc.
> 3. The ability to express themselves in a common language that is well
> understood.

Well understood, but not by the people you're talking about.

I ran into a similar situation recently;  I modeled a solution to a 
graphics problem in Postscript and I thought I could use it to 
communicate with other interested parties.  One of these told me that he 
planned to learn Postscript about the same time he planned to learn 
Fortran.  What could I say?  I told him I could help him with Fortran, 
too, but the net effect was demoralizing.  If it wasn't in the 
programming language du jour, he wasn't having any.

> 4. The problems with a black box approach to problems. [When was the
> last time you saw Newton's method fall completely on its head? How about
> solving problems with the auto-solver of a modern calculator?]
> [Off soapbox]

Wait until they try to embed MATLAB in a spacecraft.

Louis

Robert Myers <rbmyersusa@gmail.com> wrote:

> Richard Maine wrote:
> > 
> > I might also note that I find it a pretty narrow viewpoint to assume, s
> > one poster seems to do, that Fortran code is going to be targetting x86.
....
> So what if you've got a million war stories of programming something 
> else in the past?  That's exactly what the past is: past.  Affordable
> high-end chips are going to be x86 for the foreseeable future.

I remain unconvinced. I do believe that there is much to be learned from
the past. One of the things I have learned, far more than individual war
stories, is that projections of computing future are usually wrong.
That's general to darn near all such projections, including those with
just as good a basis as this one seems to have. It is particularly so
with projections that any one thing is going to completely dominate some
facet of computing.

Everything in my experience suggests that betting everything on any one
compiler or architecture loses in the long run. That's one reason why I
became interested in standards.

If you want to think that everything in my experience counts as nothing
but war stories and that the past is to be ignored, I note the
applicability of the quote in my signature, though I doubt it will
change your mind. My experience also suggests that it is hard for people
to learn such lessons other than the hard way.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On 7/3/2010 10:30 PM, Robert Myers wrote:
<snip>
> Affordable high-end chips are going to be x86 for the foreseeable future.

Someone, somewhere, is going to take that as a challenge.

Louis

True. You can contact him on comp.sys.prime.  Not only does he have
the emulated versions of the OS running, He has managed to collect
many tools, languages, and I believe a few applications. I don't
remember if he has the "ANSI PL1" but he needs SPL to compile pieces
of the OS and many other utilities, etc.

The OS versions are numbered 18 and up if I remember correctly.
Ed


On Wed, 30 Jun 2010 07:20:21 -0400, Peter Flass
<Peter_Flass@Yahoo.com> wrote:

>Edward Feustel wrote:
>>  On Wed, 30 Jun 2010 12:34:21 +1000, "robin" <robin51@dodo.com.au>
>> wrote:
>> 
>>> "Lynn McGuire" <lmc@winsim.com> wrote in message news:i0do2r$pt4$1@news.eternal-september.org...
>>> |> There are many Fortran compilers written in C, as far as I know,
>>> | > no C compilers written in Fortran.
>>> |
>>> | If the old Prime computers had a C compiler, it was probably
>>> | written in Fortran.  The whole operating system was written in
>>> | a heavily extended fortran 66 until the 198? release which was
>>> | rewritten in PL/1.
>>>
>>> That's interesting. 
>>>
>> The original OS was in the public domain. It was written in the R-Mode
>> instruction set, if I remember correctly.
>> 
>> The PR1MOS system was written in the V-Mode instruction set.
>> 
>> The C compiler did not get written until much later, in part because
>> the Pr1me machine addressed to 16 bit quantities originally.
>> Eventually a special instruction was added to permit easy byte
>> addressing. Eventually C was done in the I-Mode and X-Mode instruction
>> sets.
>> 
>> The system programming language in the 80s was SPL a PL/1 variant
>> a'la Multics. It had special system programming instructions and
>> syntax. It was initially in V-Mode.
>> 
>> There was an ANSI variant PL/1 as well.
>> 
>> In the 90s work was begun on a Modula variant as the system
>> programming language. A new OS was largely complete for an
>> X-Mode instruction set, but the company bought Computervision
>> and most development in the old Pr1me ceased.
>> 
>> Ed Feustel
>
>Someone has a public-access PRIMOS system on emulated hardware - 
>actuallt three systems with different PRIMOS releases.

On Jul 3, 11:27=A0pm, "e p chandler" <e...@juno.com> wrote:
>
> <snip> [When was the last
> time you saw Newton's method fall completely on its head?


On January 29, when I posted clf's "Happy GNU Year" greeting:

<http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/
3fb4a711c5c540d/>

See:
<http://www.codeartnow.com/gallery-1/freedom/gravitating-to-gnu>
for a variation of the "Newton method falling on the head" thingy.

:-)

Fortran's design for handling "formula translation"/ "numeric
computation" was one of my reasons for re-learning the language. I
haven't coded in C for many years, so I really have no idea whether
Fortran is still superior in this respect.

People keep asking why I'm coding in Fortran and not C. So I keep
reading the threads in this group hoping to find a convincing
answer.:-)

agt

--
Freedom - no pane, all gaiGN!

Code Art Now
http://codeartnow.com
Email: agt@codeartnow.com

viper-2 wrote:
> On Jul 3, 11:27 pm, "e p chandler" <e...@juno.com> wrote:
>> <snip> [When was the last
>> time you saw Newton's method fall completely on its head?
> 
> 
> On January 29, when I posted clf's "Happy GNU Year" greeting:
> 
> <http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/
> 3fb4a711c5c540d/>
> 
> See:
> <http://www.codeartnow.com/gallery-1/freedom/gravitating-to-gnu>
> for a variation of the "Newton method falling on the head" thingy.
> 
> :-)
> 
> Fortran's design for handling "formula translation"/ "numeric
> computation" was one of my reasons for re-learning the language. I
> haven't coded in C for many years, so I really have no idea whether
> Fortran is still superior in this respect.
> 
> People keep asking why I'm coding in Fortran and not C. So I keep
> reading the threads in this group hoping to find a convincing
> answer.:-)
> 
The problem with any attempt to examine why Fortran might be preferable 
for certain kinds of computing and not others is that almost any claim 
you make, no matter how tentative, will devolve into counterclaims and 
war stories and ultimately into a flame war.

Fortran has its advantages, not the least of which is that it isn't c, 
and if you turn your code over to someone else, it's less likely to come 
back with incomprehensible cleverness.

There are other, more technical advantages, but most of them also come 
down to: it isn't c.

Robert.

On Jul 4, 11:02=A0am, Robert Myers <rbmyers...@gmail.com> wrote:
>
> There are other, more technical advantages, but most of them also come
> down to: it isn't c.


"It isn't C" doesn't tell me much but it does sound loaded, suggesting
that if you were more specific you'd risk starting a flame war.

I do remember that with C I'd have fun using pointers everywhere. With
Fortran, I'm still looking for an excuse to use a pointer instead of
an allocatable array in my current program. Googling, I came across a
thread in the archives recommending allocatable arrays over pointers
except in certain instances. So it seems that perhaps the development
of Fortran might be a more carefully considered process, possibly
benefiting from practices in C?

agt


--
Freedom - no pane, all gaiGN!

Code Art Now
http://codeartnow.com
Email: agt@codeartnow.com

On 2010-07-05 11:18:58 -0300, viper-2 <agt@codeartnow.com> said:

> On Jul 4, 11:02�am, Robert Myers <rbmyers...@gmail.com> wrote:
>> 
>> There are other, more technical advantages, but most of them also come
>> down to: it isn't c.
> 
> 
> "It isn't C" doesn't tell me much but it does sound loaded, suggesting
> that if you were more specific you'd risk starting a flame war.
> 
> I do remember that with C I'd have fun using pointers everywhere. With
> Fortran, I'm still looking for an excuse to use a pointer instead of
> an allocatable array in my current program. Googling, I came across a
> thread in the archives recommending allocatable arrays over pointers
> except in certain instances. So it seems that perhaps the development
> of Fortran might be a more carefully considered process, possibly
> benefiting from practices in C?
> 
> agt

One way of expressing might be to say that C is a high level assembler while
Fortran started with a relatively simple programming model.

An assembler programmer is comfortable with pointers and wants to have
complete control over them. All details are open and must be attended to!

The original Fortran was intended to manipulate more mathematically styled
objects like vectors and matrices and had a relatively simple storeage model
in mind. A goodly variety of details are predetermined so that the programmer
can pay more attention to relevant issues. If you insist on fighting those
details then Fortran is not for you (and you should not try following the
CompSci text intended for C).

Both have had to deal with reality over time so that the intents have had
to made precise. In Fortran that lead to things like the no aliasing rules
being imposed on the programmer and all the needs for side issues like
characters. Initially characters in Fortran were a disaster becuase there
were none except the adhoc nonstandard hacks. Now Fortran has very good clean
characters (even though they do not exacly follow the CompSci C based style).
Fortran had weak programming structuring aids (common, subroutines were 
about it)
but the Fortran 90 modules are pretty good. If one uses F90 the number 
of errors
that the compiler can catch are pretty impressive. C does not quite match F77
on that.

On Jul 5, 10:44=A0am, Gordon Sande <Gordon.Sa...@gmail.com> wrote:
>
> One way of expressing might be to say that C is a high level assembler wh=
ile
> Fortran started with a relatively simple programming model.
>
> An assembler programmer is comfortable with pointers and wants to have
> complete control over them. All details are open and must be attended to!
>

Goodness, I'd forgotten about all the fun I used to have writing code
for the Intel 80286. In the third (penultimate year) of my BSc
engineering program, we were introduced to microprocessors in the
digital systems course. They taught too many courses  and too many
topics in any one course, so the class as a whole didn't have enough
exposure to assembly language hacking for the kind of questions set on
the final examination.

I remember that the lecturer for that course set a question requiring
us to write 80286 code to multiple two numbers. He walked past me the
next day and looked at me, as if I were a ghost. I was the only
student able to do the question - which apparently he hadn't expected
anyone to be able to do. From the moment I saw the question, I
wondered why on earth he had included it on the exam. What I didn't
tell him was that I'd become quite addicted to assembly, and since
neither his lectures nor his labs gave me enough of a fix, I had found
a little Wiley publication (I forget the name) that did the trick. I
digested it during coffee breaks and again for desert at dinner
time.:-)

No wonder I enjoyed playing with pointers in C. So that's a little war
story of my own you can chuckle at. At least two members of this group
have a sense of humour, but my jokes lately (like the Newton's method
falling on the head thingy, above) don't quite seem to be hitting the
mark.:-)


A goodly variety of details are predetermined so that the programmer
> can pay more attention to relevant issues. If you insist on fighting thos=
e
> details then Fortran is not for you

Why fight the issues? Actually, I suspect that some Fortraners hack
numerical problems in Fortran, and then interface the code with C to
accomplish performance tweaks at low level. That might be one way to
go?

agt


--
Freedom - no pane, all gaiGN!

Code Art Now
http://codeartnow.com
Email: agt@codeartnow.com

On Jul 5, 12:48=A0pm, viper-2 <a...@codeartnow.com> wrote:
>  I
> digested it during coffee breaks and again for desert at dinner
> time.:-)
>

Oops! I meant "dessert".

:-)

agt


--
Freedom - no pane, all gaiGN!

Code Art Now
http://codeartnow.com
Email: agt@codeartnow.com

Gordon Sande wrote:

> If one uses F90 the number of errors
> that the compiler can catch are pretty impressive. C does not quite 
> match F77 on that.

Very tactfully stated.

Limitations on aliasing in Fortran sometimes allow the compiler to 
optimize in ways that are not possible in c because the compiler can't 
be sure if two sets of symbols don't refer to the same memory location. 
  It is also possible to use bounds checking in Fortran and not in c.

On the other side of the ledger, you would really have to abuse Fortran 
to write system code in Fortran.

Robert.

viper-2 wrote:
....

> Why fight the issues? Actually, I suspect that some Fortraners hack
> numerical problems in Fortran, and then interface the code with C to
> accomplish performance tweaks at low level. That might be one way to
> go?
....

In my experience/working universe I'd say for that reason the number 
that do that are miniscule.

If the code is written Fortran the reason for interfacing to C will be 
either for system-dependent stuff or external libraries that don't have 
Fortran bindings available or similar.  Oh, there's also the "management 
decision" that occasionally decrees new code _shall_ be written in the 
language du jour; I've run into that more than once as well (most 
particularly common in a former life in DOE lab-settings years ago).

One pita-type problem is the mismatch between normal storage order in C 
vis a vis Fortran...resolvable, of course, but a nuisance factor.

--

On 2010-07-05 13:48:49 -0300, viper-2 <agt@codeartnow.com> said:

> 
> A goodly variety of details are predetermined so that the programmer
>> can pay more attention to relevant issues. If you insist on fighting those
>> details then Fortran is not for you
> 
> Why fight the issues? Actually, I suspect that some Fortraners hack
> numerical problems in Fortran, and then interface the code with C to
> accomplish performance tweaks at low level. That might be one way to
> go?

Not likely! Fortran compilers are more likely to generate good code
than C compilers. Fortran can be more agressive in optimizations due
to the prohibitions on aliasing as well as a client base that has
different expectations.

On Jul 1, 3:17=A0pm, Gib Bogle <g.bo...@auckland.no.spam.ac.nz> wrote:
> It's a bit inconvenient that an array element must be accessed as
> (*parray)[x][y], and also a bit confusing since this is not required in t=
he case
> of the old 1-D array.
> =A0 =A0float (*b)[10] =3D malloc(10*sizeof(float));
> and
> =A0 =A0float *b =3D malloc(10*sizeof(float));
> have the same effect, but in the latter case the elements are accessed by=
 b[i],
> while in the former by (*b)[i].

Google groups seems to have eaten my first attempt, but excuse me if
the following is a repetition:

Actually you can do the analogous thing to achieve a 2D array: just as
you can access an implicit 1D array by indexing a pointer to scalar,
you can access an implicit 2D array by indexing a pointer to a 1D
array, as shown in the example below. Neither the implicit nor
explicit 2D array declarations are new in C99, so I've also added to
this example an illustration of the feature which is new in C99,
namely the equivalent of a Fortran adjustable array:

$ cat ctest1.c
#include <stdio.h>
#include <stdlib.h>

static void
printimplicit(int xdim, int ydim, float (*implicit)[]) {
  for (int x =3D 0; x < xdim; x +=3D 1) {
    for (int y =3D 0; y < ydim; y +=3D 1) {
      printf("%g ", (*implicit)[ydim * x + y]);
      }
    printf("\n");
    }
  }

static void
printexplicit(int xdim, int ydim, float (*explicit)[xdim][ydim]) {
  for (int x =3D 0; x < xdim; x +=3D 1) {
    for (int y =3D 0; y < ydim; y +=3D 1) {
      printf("%g ", (*explicit)[x][y]);
      }
    printf("\n");
    }
  }

int
main(int argc, char **argv) {
  int xdim =3D argc;
  int ydim =3D argc + 1;
  float (*implicit)[ydim] =3D malloc(xdim * ydim * sizeof(float));
  float (*explicit)[xdim][ydim] =3D malloc(xdim * ydim * sizeof(float));
  for (int x =3D 0; x < xdim; x +=3D 1) {
    for (int y =3D 0; y < ydim; y +=3D 1) {
      implicit[x][y] =3D 10 * x + y;
      (*explicit)[x][y] =3D 10 * x + y;
      }
    }
  printimplicit(xdim, ydim, implicit);
  printexplicit(xdim, ydim, explicit);
  return 0;
  }

$ gcc -std=3Dc99 ctest1.c
$ ./a.out 1 2
0 1 2 3
10 11 12 13
20 21 22 23
0 1 2 3
10 11 12 13
20 21 22 23
$

On Jul 5, 2:01=A0pm, Gordon Sande <Gordon.Sa...@gmail.com> wrote:
>
> > Why fight the issues? Actually, I suspect that some Fortraners hack
> > numerical problems in Fortran, and then interface the code with C to
> > accomplish performance tweaks at low level. That might be one way to
> > go?
>
> Not likely! Fortran compilers are more likely to generate good code
> than C compilers. Fortran can be more agressive in optimizations due
> to the prohibitions on aliasing as well as a client base that has
> different expectations.

On Jul 5, 1:37 pm, dpb <n...@non.net> wrote:
>
>
> In my experience/working universe I'd say for that reason the number
> that do that are miniscule.
>

Obviously, I have a lot of catching up to do.:-)


agt

--
Freedom - no pane, all gaiGN!

Code Art Now
http://codeartnow.com
Email: agt@codeartnow.com

In article <5384e12f-0a8f-4f6f-8a80-77dc0e7e7d83@q12g2000yqj.googlegroups.com>,
Steven Correll  <steven.correll@gmail.com> wrote:
> >  glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> > I believe that C99 has variable dimension automatic arrays.
> > I haven't tried them yet.
> 
> > Ron Shepard <ron-shep...@nospam.comcast.net> wrote:
> > Can you allocate these multidimensional arrays with malloc() (or
> > some other library routine) in the same routine that they are used?
> 
> Below is an example of a dynamically allocated C99 2D variable length
> array using gcc. 

Cool -- I had no idea this was possible (as is apparent from my reply
to Ron).  I thought I'd made an attempt to educate myself about VLAs
in C, but I guess I missed this aspect ....

[ snip nice example ]

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

Edward Feustel a �crit :
>  On Wed, 30 Jun 2010 12:34:21 +1000, "robin" <robin51@dodo.com.au>
> wrote:
> 
>> "Lynn McGuire" <lmc@winsim.com> wrote in message news:i0do2r$pt4$1@news.eternal-september.org...
>> |> There are many Fortran compilers written in C, as far as I know,
>> | > no C compilers written in Fortran.
>> |
>> | If the old Prime computers had a C compiler, it was probably
>> | written in Fortran.  The whole operating system was written in
>> | a heavily extended fortran 66 until the 198? release which was
>> | rewritten in PL/1.
>>
>> That's interesting. 
>>
> The original OS was in the public domain. It was written in the R-Mode
> instruction set, if I remember correctly.
> 
> The PR1MOS system was written in the V-Mode instruction set.
> 
> The C compiler did not get written until much later, in part because
> the Pr1me machine addressed to 16 bit quantities originally.
> Eventually a special instruction was added to permit easy byte
> addressing. Eventually C was done in the I-Mode and X-Mode instruction
> sets.
> 
> The system programming language in the 80s was SPL a PL/1 variant
> a'la Multics. It had special system programming instructions and
> syntax. It was initially in V-Mode.
> 
> There was an ANSI variant PL/1 as well.
> 

True, but before SPL and PL/1 subset G, there was the best flavor of a 
PL/1 dialect aimed at systems programming that I ever touched: it was 
named PL/P, lightweighted and superfast for compiling. All our new (at
that time) applications were coded in it. That was probably around 
1977-1978).

> In the 90s work was begun on a Modula variant as the system
> programming language. A new OS was largely complete for an
> X-Mode instruction set, but the company bought Computervision
> and most development in the old Pr1me ceased.
> 
> Ed Feustel

Bernard Giroud

"Thomas Koenig" <tkoenig@netcologne.de> wrote in message news:i0nnf8$fb0$1@newsreader5.netcologne.de...
| Phillip Helbig wrote:

| > FORTRAN IV even had a Roman numeral.  :-)
|
| The nice thing about Roman numbers is that you can't have a division by
| zero error.

Um, can you have division by anything? 

Thomas Koenig wrote:

> Phillip Helbig wrote:
>> In article <i0hu98$ocp$1@speranza.aioe.org>, Jugoslav Dujic
>><jdujic@yahoo.com> writes:
>>
>>> On 29.06.2010. 23:22, Colin Watters wrote:
>>> > Here is an even more dated paper (1893) comparing Fortran and some
>>> > other languages:
>>> 
>>> Jeez, I didn't know Fortran is *THAT* old :o)
>>
>> FORTRAN IV even had a Roman numeral.  :-)
> 
> The nice thing about Roman numbers is that you can't have a division by
> zero error.

Zero is not part of the Roman number system -- it was not needed in a number
system that did not use a polynomial expansion in terms of a small base.

-- mecej4

Phillip Helbig---undress to reply wrote:

> In article <i0hu98$ocp$1@speranza.aioe.org>, Jugoslav Dujic
> <jdujic@yahoo.com> writes:
> 
>> On 29.06.2010. 23:22, Colin Watters wrote:
>> > Here is an even more dated paper (1893) comparing Fortran and some
>> > other languages:
>> 
>> Jeez, I didn't know Fortran is *THAT* old :o)
> 
> FORTRAN IV even had a Roman numeral.  :-)

FORTRAN IV is more suggestive of a general or a pope than a numeral.

-- mecej4

On Jul 13, 12:35=A0am, mecej4 <mecej4.nyets...@operamail.com> wrote:

> FORTRAN IV is more suggestive of a general or a pope than a numeral.

A general?? What about a king or queen, or an American with the same
name as his father, grandfather and great-grandfather?
(Is FORTRAN III as obscure as Napoleon II?)y

-- John Harper

Bernard Giroud wrote in message <4c39b965$0$29567$426a74cc@news.free.fr>...
>Edward Feustel a �crit :
>>  On Wed, 30 Jun 2010 12:34:21 +1000, "robin" <robin51@dodo.com.au>
>> wrote:
>>
>>> "Lynn McGuire" <lmc@winsim.com> wrote in message news:i0do2r$pt4$1@news.eternal-september.org...
>>> |> There are many Fortran compilers written in C, as far as I know,
>>> | > no C compilers written in Fortran.
>>> |
>>> | If the old Prime computers had a C compiler, it was probably
>>> | written in Fortran.  The whole operating system was written in
>>> | a heavily extended fortran 66 until the 198? release which was
>>> | rewritten in PL/1.
>>>
>>> That's interesting.
>>>
>> The original OS was in the public domain. It was written in the R-Mode
>> instruction set, if I remember correctly.
>>
>> The PR1MOS system was written in the V-Mode instruction set.
>>
>> The C compiler did not get written until much later, in part because
>> the Pr1me machine addressed to 16 bit quantities originally.
>> Eventually a special instruction was added to permit easy byte
>> addressing. Eventually C was done in the I-Mode and X-Mode instruction
>> sets.
>>
>> The system programming language in the 80s was SPL a PL/1 variant
>> a'la Multics. It had special system programming instructions and
>> syntax. It was initially in V-Mode.
>>
>> There was an ANSI variant PL/1 as well.
>>
>
>True, but before SPL and PL/1 subset G, there was the best flavor of a
>PL/1 dialect aimed at systems programming that I ever touched: it was
>named PL/P, lightweighted and superfast for compiling. All our new (at
>that time) applications were coded in it. That was probably around
>1977-1978).

Not heard of that, but XPL for the /360 was around in 1969,
and there had been some versions on even earlier systems.

On Jun 28, 7:03=A0pm, Lynn McGuire <l...@winsim.com> wrote:
> > What can Fortran do that C, C++, C# can't?
>
> > Along similar lines where would Fortran be a superior chice over C, C+
> > +, or C#
>
> None that I know of. =A0Here is a dated (1992) paper comparing F77,
> F90, C and C++ for engineering pgrograms:
> =A0 =A0http://www.leshatton.org/Documents/JSX_0192.pdf
>
> Me, myself and I, we all prefer C++. =A0I like strong typing and
> mandatory function prototypes. =A0I also like function overloading.
>

Umm.  I guess I have to get my .02 cents in.  I program in both, but
lately I find myself liking the F2003 standard more and more.  The
simple reason being the "batteries included" of Fortran.  Simply being
able to express array addition as:

A  =3D B + C

and performing array slicing right out of the box like

A(1:5:2) =3D B(2:6:2)

is nice for those who want to hit the ground running.  Also, blocks
like "where" and "forall" provided on the fly masks for selective
access to arrays.  The list goes on.  I'm a little confused about the
strongly typed comment since I consider Fortran to be strongly typed.
Also, function overloading has been in since F90.  Just use a generic
interface.  Both languages are excellent.  I just find that Fortran
seems to get an undeserved bad wrap, but I find it to be an excellent
language for scientific computing.  Just read "The Fortran 2003
Handbook" of which Richard Maine is a co-author to get a full
appreciation for the new standard.

-David

In article <db54d0f2-aa49-4388-8c44-47c866a18fda@j13g2000yqj.googlegroups.com>,
card  <david.car7@gmail.com> wrote:
>On Jun 28, 7:03=A0pm, Lynn McGuire <l...@winsim.com> wrote:
>> > What can Fortran do that C, C++, C# can't?
>>
>> > Along similar lines where would Fortran be a superior chice over C, C+
>> > +, or C#
>>
>> None that I know of. =A0Here is a dated (1992) paper comparing F77,
>> F90, C and C++ for engineering pgrograms:
>> =A0 =A0http://www.leshatton.org/Documents/JSX_0192.pdf
>>
>> Me, myself and I, we all prefer C++. =A0I like strong typing and
>> mandatory function prototypes. =A0I also like function overloading.

All available in Fortran 90, let alone 2003.

>Umm.  I guess I have to get my .02 cents in.  I program in both, but
>lately I find myself liking the F2003 standard more and more.  The
>simple reason being the "batteries included" of Fortran.  Simply being
>able to express array addition as:
>
>A  = B + C
>
>and performing array slicing right out of the box like
>
>A(1:5:2) = B(2:6:2)
>
>is nice for those who want to hit the ground running.  ...

C++'s array handling is dire, as with all such languages.  If you
need to do a lot of non-trivial matrix work, there is simply no
competition - Fortran beats C++ into a cocked hat.

The main other areas where Fortran has facilities that C++ lacks
that I can think of are debuggability and optimisability (which
are closely related).  Even modern Fortran is poor, but C++ is
hopeless - on the former, if either you or the implementor makes
a mistake, heaven help you - on the latter, that's why OpenMP
Fortran is much better than the C version and the C++ version
is really just the C one with brass knobs on.  Complex arithmetic
is a lot better, too.

Of course, there are many things that C++ has that Fortran lacks,
some of which cause even diehard Fortran programmers to have
trouble.  Free-format input (and I/O flexibility, generally) and
flexible, lightweight character string handling, to name but two.


Regards,
Nick Maclaren.

On 29 Jun, 00:25, rfengineer55 <rfenginee...@aol.com> wrote:

> What can Fortran do that C, C++, C# can't?

Nothing, except save the numerical programmer from pain and suffering.

And for anything else there is Python.

>>> Me, myself and I, we all prefer C++. =A0I like strong typing and
>>> mandatory function prototypes. =A0I also like function overloading.
>
> All available in Fortran 90, let alone 2003.

Are strong typing and function prototypes mandatory in Fortran 90 ?

You can force typing by adding "implicit none".  But is it strong
typing ?

> C++'s array handling is dire, as with all such languages.  If you
> need to do a lot of non-trivial matrix work, there is simply no
> competition - Fortran beats C++ into a cocked hat.

Can you give an example of this ?

> The main other areas where Fortran has facilities that C++ lacks
> that I can think of are debuggability and optimisability (which
> are closely related).  Even modern Fortran is poor, but C++ is
> hopeless - on the former, if either you or the implementor makes
> a mistake, heaven help you - on the latter, that's why OpenMP
> Fortran is much better than the C version and the C++ version
> is really just the C one with brass knobs on.

Can you give an example of this ?

Thanks,
Lynn

In article <i1kl9f$cub$1@news.eternal-september.org>,
Lynn McGuire  <lmc@winsim.com> wrote:
>>>> Me, myself and I, we all prefer C++.  I like strong typing and
>>>> mandatory function prototypes.  I also like function overloading.
>>
>> All available in Fortran 90, let alone 2003.
>
>Are strong typing and function prototypes mandatory in Fortran 90 ?
>
>You can force typing by adding "implicit none".  But is it strong
>typing ?

About as much as in C++ - i.e. not very, in both cases.  But there's
essentially no systematic difference, and only the details of what
you have to do differ.  However, the do differ (wildly) and both
have serious loopholes in their type systems.

>> C++'s array handling is dire, as with all such languages.  If you
>> need to do a lot of non-trivial matrix work, there is simply no
>> competition - Fortran beats C++ into a cocked hat.
>
>Can you give an example of this ?

Trivially.  I have a 10x10 matrix, and I want to pass the 4x4 centre
to a routine that expects a normal 4x4 matrix.  If you use entirely
modern Fortran (i.e. assumed-shape arrays), that doesn't even copy
the data when doing that.  C++ has no equivalent - and, no, gslice
does not cut the mustard.

>> The main other areas where Fortran has facilities that C++ lacks
>> that I can think of are debuggability and optimisability (which
>> are closely related).  Even modern Fortran is poor, but C++ is
>> hopeless - on the former, if either you or the implementor makes
>> a mistake, heaven help you - on the latter, that's why OpenMP
>> Fortran is much better than the C version and the C++ version
>> is really just the C one with brass knobs on.
>
>Can you give an example of this ?

While I can, if you need them, I doubt that it would help.

The debuggability issues are largely because the C++ standard has
a lot more ambiguities than the Fortran one (and what it inherits
from C has VASTLY more) and requires the compiler to diagnose a
smaller proportion of the potential errors.

The two main optimisability aspects are aliasing and serialisation,
which I will give very simple examples of:

In Fortran, if two arguments overlap IN ANY WAY and are not flagged
as potentially aliasing each other, neither may be written to.
That is not the case in C++, so it can't use that for optimisation.

C++ requires all function calls, implicit and explicit, to be executed
in some sequential order.  Fortran does not, and they may be reordered
or even omitted.


Regards,
Nick Maclaren.

Lynn McGuire <lmc@winsim.com> wrote:

> Are strong typing and function prototypes mandatory in Fortran 90 ?
> 
> You can force typing by adding "implicit none".  But is it strong
> typing ?

Yes. Of course, that's the kind of word that has different meanings to
different people, but it is strong typing by the definitions I've most
often seen. In particular, textually identical types are not considered
to be equivalent; you actually have to use the same type definition
rather than copy its text. (Sequence types are an exception, but one can
choose an easily enforceable style that avoids them; you have to avoid
them to use type extension. See below about style options.)

"Function prototypes" is a language-specific term rather than a general
concept. The analogue in Fortran would be an explicit interface.
Explicit interfaces are mandatory when you use pretty much anything
"interesting" in terms of procedure arguments. Perhaps more important
than being mandatory is that they are automatic as long as you make it a
policy to use modules. If you require that all procedures be module
procedures (an easy requirement to enforce), then there can't be a
procedure without an explicit interface.

Fortran does not go in for mandatory enforcement of programming style by
the language spec. It is much more about providing the programmer with
options. Many of those style options can be verified/enforced if that is
one's inclination.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

> Fortran does not go in for mandatory enforcement of programming style by
> the language spec. It is much more about providing the programmer with
> options. Many of those style options can be verified/enforced if that is
> one's inclination.

One area where we have had many problems is with programmers
failing to declare variables.  I also believe that the mandatory
enforcement of variable typing in C++ is a big plus.  Since we are
not using a F90+ compiler, we do not have interfaces but I also
think that mandatory function prototypes in C++ is a big plus from
my experience.  I cannot tell you how many times we have had trouble
with subroutine calls in our fortran code because a programmer gave
the wrong number of arguments or the wrong type of arguments.

So, yes, I think that strong variable types and interfaces (function
prototypes) should be mandatory in a computer language.

Lynn

>> You can force typing by adding "implicit none".  But is it strong
>> typing ?
>
> About as much as in C++ - i.e. not very, in both cases.  But there's
> essentially no systematic difference, and only the details of what
> you have to do differ.  However, the do differ (wildly) and both
> have serious loopholes in their type systems.

I disagree.  C++ forces the programmer to type and will devolve
that type into the lowest common denominator that it can.  If you
are using objects rather than base types (int, double, etc) as
types then C++ is very rigid about operations on those variables.
The programmer can always cheat by casting but that is very obvious
what is going on then.

> Trivially.  I have a 10x10 matrix, and I want to pass the 4x4 centre
> to a routine that expects a normal 4x4 matrix.  If you use entirely
> modern Fortran (i.e. assumed-shape arrays), that doesn't even copy
> the data when doing that.  C++ has no equivalent - and, no, gslice
> does not cut the mustard.

Thanks, yes, that is very true.

> In Fortran, if two arguments overlap IN ANY WAY and are not flagged
> as potentially aliasing each other, neither may be written to.
> That is not the case in C++, so it can't use that for optimisation.

Yes.  I have run into the memcpy overlap problem quite a few times.

> C++ requires all function calls, implicit and explicit, to be executed
> in some sequential order.  Fortran does not, and they may be reordered
> or even omitted.

I dont quite understand this example but that is OK.

Thanks,
Lynn

In article <i1knum$p0s$1@news.eternal-september.org>,
Lynn McGuire  <lmc@winsim.com> wrote:
>> Fortran does not go in for mandatory enforcement of programming style by
>> the language spec. It is much more about providing the programmer with
>> options. Many of those style options can be verified/enforced if that is
>> one's inclination.
>
>One area where we have had many problems is with programmers
>failing to declare variables.  I also believe that the mandatory
>enforcement of variable typing in C++ is a big plus.

That's essentially trivial to enforce in Fortran, provided that you
have adequate project management.  Remember that, UNLIKE C/C++, it
is trivial to parse Fortran well enough to check that IMPLICIT NONE
is used (as well as that people haven't used single precision by
accident, and several other such errors).  A very simple Python
script will do it.

>Since we are
>not using a F90+ compiler, we do not have interfaces but I also
>think that mandatory function prototypes in C++ is a big plus from
>my experience.  I cannot tell you how many times we have had trouble
>with subroutine calls in our fortran code because a programmer gave
>the wrong number of arguments or the wrong type of arguments.

Well, if it were the other way round, you would be comparing
Fortran 95 with K&R C (and no lint).

>So, yes, I think that strong variable types and interfaces (function
>prototypes) should be mandatory in a computer language.

I agree.  But they aren't properly, in either C++ or Fortran.
C++ and modern Fortran are a hell of a lot better than K&R C and
Fortran 77 in that respect, I agree :-)


Regards,
Nick Maclaren.

In article <i1koc0$r0g$1@news.eternal-september.org>,
Lynn McGuire  <lmc@winsim.com> wrote:
>>> You can force typing by adding "implicit none".  But is it strong
>>> typing ?
>>
>> About as much as in C++ - i.e. not very, in both cases.  But there's
>> essentially no systematic difference, and only the details of what
>> you have to do differ.  However, the do differ (wildly) and both
>> have serious loopholes in their type systems.
>
>I disagree.  C++ forces the programmer to type and will devolve
>that type into the lowest common denominator that it can.  If you
>are using objects rather than base types (int, double, etc) as
>types then C++ is very rigid about operations on those variables.
>The programmer can always cheat by casting but that is very obvious
>what is going on then.

I wish :-(

As a simple example of where C++ is much laxer than Fortran, consider
arrays versus pointers to scalars - in Fortran, they are distinct.
And, in a good compiler, array indices etc. are checked at run-time;
try NAG Fortran with -C=all.


Regards,
Nick Maclaren.

<nmm1@cam.ac.uk> wrote:

> In article <i1knum$p0s$1@news.eternal-september.org>,
> Lynn McGuire  <lmc@winsim.com> wrote:
> >> Fortran does not go in for mandatory enforcement of programming style by
> >> the language spec. It is much more about providing the programmer with
> >> options. Many of those style options can be verified/enforced if that is
> >> one's inclination.
> >
> >One area where we have had many problems is with programmers
> >failing to declare variables.  I also believe that the mandatory
> >enforcement of variable typing in C++ is a big plus.
> 
> That's essentially trivial to enforce in Fortran, provided that you
> have adequate project management. 

That was the point I was trying to make - that Fortran doesn't itself
mandate style, but that some style elements are easy enough to enforce.
Of course, if you want a style to be enforced but you don't have
management backing to do the enforcement, then maybe the lack of options
might be considered a plus in a way... until the lack of options forces
you into some choice that isn't one of the ones you wanted.

For example, I like many things about the F subset, but I find other
parts of it so annoying as to be unacceptable. As far as I can tell,
that's a fairly common reaction to F, with different people reacting to
different parts. In many ways, the F subset is just enforcement of a
particular set of style choices, with the enforcement built into a
compiler.

I'm of the opinion that looking to a language spec to make up for
management failures is not likely to work out well. I think of language
specs as facilitators rather than as straightjackets. They can
facilitate making the straightjacket if you want.

I find it slightly ironic, but then also understandable, that Lynn seems
to favor what I'd consider as having mandatory style enforcement built
into the language, yet the code that he (my short-term memory does still
sometimes work) works with seems to be full of things I would have been
most adamant about disallowing. This might plausibly be related in that
he gets to see a lot of the resulting problems and perhaps wishes that
there had been a way to keep that kind of mess from developing. Just
speculation on my part, but it seems a likely one.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

Lynn McGuire wrote:
....

> So, yes, I think that strong variable types and interfaces (function
> prototypes) should be mandatory in a computer language.


I would be realistic and I would consider separately what the standard 
allows/forbids and what an efficient programming style should/shouldn't 
enforce.

In different ways standards of C, C++ and Fortran are not completely 
rigid as far as strong typing is concerned. But standards have to take 
care of the whole history of a language.

Specific, efficient and up-to-date programming styles are different 
things. No one of my students faces problems with types or wrong 
number/type of arguments, once I require the presence of "implicit none" 
in every program and module subprograms only.

Giorgio

Richard Maine wrote:
....

> I find it slightly ironic, but then also understandable, that Lynn seems
> to favor what I'd consider as having mandatory style enforcement built
> into the language, yet the code that he (my short-term memory does still
> sometimes work) works with seems to be full of things I would have been
> most adamant about disallowing. This might plausibly be related in that
> he gets to see a lot of the resulting problems and perhaps wishes that
> there had been a way to keep that kind of mess from developing. Just
> speculation on my part, but it seems a likely one.

In Lynn's defense, I think most of the code that has such severe 
problems is _very_ old and the code base they currently have has "just 
growed" w/ time.

I do tend to agree, however, that it does seem that the fact that they 
have been constrained to the F77 dialect they have been/currently are 
owing to the idiosyncrasies of a particular compiler for the PC market 
(if not some of the other targets for which it builds; that I don't know 
about) has tended to keep his mindset that "Fortran" means that 
particular set of features.  While I know from other conversations over 
several years he is aware of F90+, I get the impression that it hasn't 
been anything he's used extensively and it isn't used elsewhere either 
(again I presume to keep code base at least reasonably consistent across 
platforms).  Consequently, I think that he has familiarity and has used 
C++ those features seem natural but since hasn't done extensive coding 
nor does there code use them, the similar features and 
advantages/disadvantages of current Fortran don't have the same level of 
intuitive cognizance.

_IF_ (the proverbial "big if") he can ever get the zero-init and SAVE 
issue resolved so this code will compile and run successfully on a 
modern Fortran compiler, _then_ I think if they will give it a fair 
chance they would discover much to be liked very much that would give 
C++ a run for its money.  Whether it will get that chance against 
corporate decree given my experience I don't know or feel much 
confidence about, though. :(

--

Lynn McGuire wrote:
....
> One area where we have had many problems is with programmers
> failing to declare variables.  I also believe that the mandatory
> enforcement of variable typing in C++ is a big plus.  Since we are
> not using a F90+ compiler, we do not have interfaces but I also
> think that mandatory function prototypes in C++ is a big plus from
> my experience.  I cannot tell you how many times we have had trouble
> with subroutine calls in our fortran code because a programmer gave
> the wrong number of arguments or the wrong type of arguments.
> 
> So, yes, I think that strong variable types and interfaces (function
> prototypes) should be mandatory in a computer language.

Question, Lynn...what (if any) static code analysis toolsets have you 
used on your codebase?

Several are supposed to be able to do such things as this I think.

I've used the Understand for XXX series on some really similar-looking 
code (also of roughly same age origin and also from a National Lab) in a 
former life of needing to modify/extend same and it was great for call 
trees and other such.  I didn't have a problem of there being functional 
problems w/ it so I don't recall about the argument mismatches otomh but 
I think it's supposed to be able to do so.  There's also f-lint and 
ftnchk and probably others.

--

>> So, yes, I think that strong variable types and interfaces (function
>> prototypes) should be mandatory in a computer language.
>
> Question, Lynn...what (if any) static code analysis toolsets have you used on your codebase?

None.  We have a hand-written perl script that we run occasionally
on the f77 code to check number of arguments and argument types.
However, we got nailed recently by a 0 in a call to a sub with a
double argument.  Replacing that with a 0.0 solved the crash.

> I've used the Understand for XXX series on some really similar-looking code (also of roughly same age origin and also from a National
> Lab) in a former life of needing to modify/extend same and it was great for call trees and other such. I didn't have a problem of
> there being functional problems w/ it so I don't recall about the argument mismatches otomh but I think it's supposed to be able to
> do so. There's also f-lint and ftnchk and probably others.

When your call trees are 50 levels deep, I'm not sure that they are
any good.  Ftnchk goes nuts on our code since we are really mostly
f66.  I have never seen f-lint.

Thanks,
Lynn

> In Lynn's defense, I think most of the code that has such severe problems is _very_ old and the code base they currently have has
> "just growed" w/ time.

Only since 1965 <g>.  As I've mentioned before, we have dragged it to
many platforms.  For instance, we only started using "implicit none"
and character strings a couple of years ago.

> I do tend to agree, however, that it does seem that the fact that they have been constrained to the F77 dialect they have
> been/currently are owing to the idiosyncrasies of a particular compiler for the PC market (if not some of the other targets for which
> it builds; that I don't know about) has tended to keep his mindset that "Fortran" means that particular set of features. While I know
> from other conversations over several years he is aware of F90+, I get the impression that it hasn't been anything he's used
> extensively and it isn't used elsewhere either (again I presume to keep code base at least reasonably consistent across platforms).
> Consequently, I think that he has familiarity and has used C++ those features seem natural but since hasn't done extensive coding nor
> does there code use them, the similar features and advantages/disadvantages of current Fortran don't have the same level of intuitive
> cognizance.

BTW, I have a lot of gripes and learning curve with C++ also.  You'll
see me frequently complaining over at comp.lang.c++.

> _IF_ (the proverbial "big if") he can ever get the zero-init and SAVE issue resolved so this code will compile and run successfully
> on a modern Fortran compiler, _then_ I think if they will give it a fair chance they would discover much to be liked very much that
> would give C++ a run for its money. Whether it will get that chance against corporate decree given my experience I don't know or feel
> much confidence about, though. :(

My "intern" is going to start working on the /save problem in a month
or two.  We are going to try the brute force approach of initializing
all local variables to zero using execution statements, not data statements.

Thanks,
Lynn

Lynn McGuire wrote:
>>> So, yes, I think that strong variable types and interfaces (function
>>> prototypes) should be mandatory in a computer language.
>>
>> Question, Lynn...what (if any) static code analysis toolsets have you 
>> used on your codebase?
> 
> None.  We have a hand-written perl script that we run occasionally
> on the f77 code to check number of arguments and argument types.
> However, we got nailed recently by a 0 in a call to a sub with a
> double argument.  Replacing that with a 0.0 solved the crash.
> 
>> I've used the Understand for XXX series on some really similar-looking 
>> code (also of roughly same age origin and also from a National
>> Lab) in a former life of needing to modify/extend same and it was 
>> great for call trees and other such. I didn't have a problem of
>> there being functional problems w/ it so I don't recall about the 
>> argument mismatches otomh but I think it's supposed to be able to
>> do so. There's also f-lint and ftnchk and probably others.
> 
> When your call trees are 50 levels deep, I'm not sure that they are
> any good.  Ftnchk goes nuts on our code since we are really mostly
> f66.  I have never seen f-lint.

My experience w/ the "Understand ..." folks was so positive given the 
size of your code base I'd think it money well invested.  At the time I 
did the above example, while it was smaller enough that I could move it 
to F95 and add modules within the time frame allotted, Understand for 
Fortran was still new enough w/ the F95 parser that a few things fouled 
it up as well as a couple of ideas for some additional facilities. 
Scitools <http://www.scitools.com/> even on a trial free copy did 
multiple builds and fixes on almost daily basis to resolve those.  I'd 
think based on that if your code found a limitation they'd seriously try 
to make a fix to handle it.  (Altho I guess if it were in the going 
backwards to F66-level that broke it rather than later versions or 
simply a limitation in assumed complexity they might not be so interested).

I believe it's still possible to download the functional version for 
trial; I don't know whether there's anything other than time expiration 
limits at the moment or not on its capabilities.

I don't really know f-lint other than the information on it--again given 
the problems it would seem the more toolsets even if none are perfect 
would be better (again recognizing the penchant of management to spend a 
gazillion manhours as opposed to a few thousand purchase dollars).

<http://legacy.cleanscape.net/products/fortranlint/fortran-lint_features.html>

It claims F66 thru F95 and there's a download for a trial there as well 
that claims is full-functioned only time limited.  Again I "know 
nuthink" really other than it seems like if it does what it says it 
could be a help...

--

dpb wrote:
> Lynn McGuire wrote:
....

>> However, we got nailed recently by a 0 in a call to a sub with a
>> double argument.  Replacing that with a 0.0 solved the crash.
....

BTW, that really should be 0.0D0 (as I'm sure you're aware) but just in 
case one might consider going back to the offending point and making 
sure rather than relying on a compiler switch to promote single/double.

--

dpb <none@non.net> wrote:

> dpb wrote:
> > Lynn McGuire wrote:
> ...
> 
> >> However, we got nailed recently by a 0 in a call to a sub with a
> >> double argument.  Replacing that with a 0.0 solved the crash.
> ...
> 
> BTW, that really should be 0.0D0 (as I'm sure you're aware) but just in
> case one might consider going back to the offending point and making 
> sure rather than relying on a compiler switch to promote single/double.

That's a case where I like to use a parameter ("parameter" as in "named
constant" - not as in a sloppy synonym for "procedure argument"). I like
to avoid real literal constants as actual arguments. I don't make it an
absolute rule; there are cases where real literals seem the best choice
(such as when you have about a zillion of them in close proximity). I am
pretty finicky about using a kind parameter whenever I do use a real
literal as an actual argument.

The specific case of real zero is common and basic enough that I have a
named constant (r_zero) for the real zero of my working precision (most
often double, but I've made it easy to change - something about having
wasted many, many hours/days/weeks of my youth working on changing
precision while porting code).

I'm not nearly as picky about literal constants for integers. The
cost/benefit of sticking kind numbers on every integer literal just
isn't there. The cost is high because there are a darned lot of integer
literals in code, even code that is nominally about floatting point
number crunching. The benefit is low because default integer is almost
always a good choice (and sometimes the only choice). I did just say
"almost" always. Exceptions exist, but those exceptions are where I use
kind numbers rathar than doing it everywhere.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

Richard Maine wrote:
> dpb <none@non.net> wrote:
> 
>> dpb wrote:
>>> Lynn McGuire wrote:
>> ...
>>
>>>> However, we got nailed recently by a 0 in a call to a sub with a
>>>> double argument.  Replacing that with a 0.0 solved the crash.
>> ...
>>
>> BTW, that really should be 0.0D0 (as I'm sure you're aware) but just in
>> case one might consider going back to the offending point and making 
>> sure rather than relying on a compiler switch to promote single/double.
> 
> That's a case where I like to use a parameter ("parameter" as in "named
> constant" - not as in a sloppy synonym for "procedure argument"). I like
> to avoid real literal constants as actual arguments. I don't make it an
> absolute rule; there are cases where real literals seem the best choice
> (such as when you have about a zillion of them in close proximity). I am
> pretty finicky about using a kind parameter whenever I do use a real
> literal as an actual argument.
> 
> The specific case of real zero is common and basic enough that I have a
> named constant (r_zero) for the real zero of my working precision (most
> often double, but I've made it easy to change - something about having
> wasted many, many hours/days/weeks of my youth working on changing
> precision while porting code).
....

Yes, I'd agree.  I started to mention the KIND parameter but didn't 
owing to the limitation of F77.  Then I didn't add the PARAMETERized 
named constant, either.

--

dpb <none@non.net> wrote:

> Richard Maine wrote:

> > I am
> > pretty finicky about using a kind parameter whenever I do use a real
> > literal as an actual argument.

> Yes, I'd agree.  I started to mention the KIND parameter but didn't 
> owing to the limitation of F77.  Then I didn't add the PARAMETERized 
> named constant, either.

Yeah. F77 was quite a PITA to make reasonably portable for things like
that. In the f77 days I did a lot of moving code between machines where
you really needed to change between single and double precision as part
of the move. In the later f77 days I started using some awkward hacks to
somewhat facilitate the process; made me greatly appreciate f90 kinds.

One hack I used with some regularity was to have a named constant with
the value 1.0 (or 1.0d0). It was usually named something innovative like
ONE. Then if I wanted to use a literal constant, say 1.2, for an actual
argument, I'd write it as 1.2*ONE. That was a bit awkward, but not as
awkward as defining a separate named constant for each such value. It
did get the effect I wanted of making the actual argument have the right
kind with only changing a single line of source code in the program.
(Yes, I used INCLUDE, which was nonstandard f77, but this was late
enough in f77 that pretty much all compilers of interest to be supported
it. If needed, I could hack an include preprocessor together pretty
easily in Fortran myself as a last resort.)

Of course this didn't get a value of 1.2 accurate to double precision,
but that was not typically important for the kinds of contexts where I'd
do this. The value needed to be double precision only for argument
agreement.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

Richard Maine <nospam@see.signature> wrote:
(snip)
 
> Fortran does not go in for mandatory enforcement of programming style by
> the language spec. It is much more about providing the programmer with
> options. Many of those style options can be verified/enforced if that is
> one's inclination.

Maybe, but it does seem that some rules, or rule changes, were
meant to discourage some uses.  One example is the removal of the
use of REAL varaibles in DO loops, added in Fortran 77, then removed
in Fortran 90.  Yes there can be problems in doing it, but, as
you say the language shouldn't enforce the style.  I could probably
think of some others, but that one comes to mind first.

-- glen 

In article <i1mca4$426$1@speranza.aioe.org>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:
>Richard Maine <nospam@see.signature> wrote:
> 
>> Fortran does not go in for mandatory enforcement of programming style by
>> the language spec. It is much more about providing the programmer with
>> options. Many of those style options can be verified/enforced if that is
>> one's inclination.
>
>Maybe, but it does seem that some rules, or rule changes, were
>meant to discourage some uses.  One example is the removal of the
>use of REAL varaibles in DO loops, added in Fortran 77, then removed
>in Fortran 90.  Yes there can be problems in doing it, but, as
>you say the language shouldn't enforce the style.  I could probably
>think of some others, but that one comes to mind first.

That's nothing - C99 has introduced complex time :-)


Regards,
Nick Maclaren.

"Lynn McGuire" <lmc@winsim.com> wrote in message 
news:i1l2f1$dqb$1@news.eternal-september.org...

>
> My "intern" is going to start working on the /save problem in a month
> or two.  We are going to try the brute force approach of initializing
> all local variables to zero using execution statements, not data 
> statements.
>

Then here's an idea, fwiw.

Surround each block of initializations with an IF DEBUG block. Eg:

      IF(DEBUG(304)) then
        xx1 = 0d0
        xx2 = 0d0
        :  (etc)
      endif

Declare the DEBUG array in common in an include file, dimension it to the 
number of routines in the program, and INCLUDE it in all the routines as 
you work on them. Of course, use a separate element of the array for every 
routine. You'll need to keep a list of numbers to names.

Arrange a way so you can set or clear selected (or all) elements of DEBUG 
at program start-up. Now you can investigate which routines actually need 
the initialzations, without having to recompile. This is useful because it 
lets you find the actual cause of the problem(s), and allows you to fix 
them properly.

If you do this you should leave the data statements extant.

You could also initialize to some global initial value instead of zero, 
again determined at run-time. (thus you can undo the effect of the data 
statements.)

Other possibilities will occur to you. Like...instead of 10 separate 
statements, try

      call init(xx1,xx2,xx3,xx4,xx5,xx6,xx7,xx8,xx9,xx10)

Fun and games!

-- 
Qolin

Email: my qname at domain dot com
Domain: qomputing 

>> My "intern" is going to start working on the /save problem in a month
>> or two.  We are going to try the brute force approach of initializing
>> all local variables to zero using execution statements, not data
>> statements.
>>
>
> Then here's an idea, fwiw.
>
> Surround each block of initializations with an IF DEBUG block. Eg:
>
>        IF(DEBUG(304)) then
>          xx1 = 0d0
>          xx2 = 0d0
>          :  (etc)
>        endif
>
> Declare the DEBUG array in common in an include file, dimension it to the
> number of routines in the program, and INCLUDE it in all the routines as
> you work on them. Of course, use a separate element of the array for every
> routine. You'll need to keep a list of numbers to names.
>
> Arrange a way so you can set or clear selected (or all) elements of DEBUG
> at program start-up. Now you can investigate which routines actually need
> the initialzations, without having to recompile. This is useful because it
> lets you find the actual cause of the problem(s), and allows you to fix
> them properly.
>
> If you do this you should leave the data statements extant.
>
> You could also initialize to some global initial value instead of zero,
> again determined at run-time. (thus you can undo the effect of the data
> statements.)
>
> Other possibilities will occur to you. Like...instead of 10 separate
> statements, try
>
>        call init(xx1,xx2,xx3,xx4,xx5,xx6,xx7,xx8,xx9,xx10)
>
> Fun and games!
>

Nice idea.  Did I mention the 3,000 subroutines and functions ?
650,000 lines of code ?

Thanks,
Lynn

"Lynn McGuire" <lmc@winsim.com> wrote in message 
news:i1noad$tqk$1@news.eternal-september.org...
>>> My "intern" is going to start working on the /save problem in a month
>>> or two.  We are going to try the brute force approach of initializing
>>> all local variables to zero using execution statements, not data
>>> statements.
>>>
>>
>> Then here's an idea, fwiw.
>>
>> Surround each block of initializations with an IF DEBUG block. Eg:
>>
>>        IF(DEBUG(304)) then
>>          xx1 = 0d0
>>          xx2 = 0d0
>>          :  (etc)
>>        endif
>>
>> Declare the DEBUG array in common in an include file, dimension it to 
>> the
>> number of routines in the program, and INCLUDE it in all the routines as
>> you work on them. Of course, use a separate element of the array for 
>> every
>> routine. You'll need to keep a list of numbers to names.
>>
>> Arrange a way so you can set or clear selected (or all) elements of 
>> DEBUG
>> at program start-up. Now you can investigate which routines actually 
>> need
>> the initialzations, without having to recompile. This is useful because 
>> it
>> lets you find the actual cause of the problem(s), and allows you to fix
>> them properly.
>>
>> If you do this you should leave the data statements extant.
>>
>> You could also initialize to some global initial value instead of zero,
>> again determined at run-time. (thus you can undo the effect of the data
>> statements.)
>>
>> Other possibilities will occur to you. Like...instead of 10 separate
>> statements, try
>>
>>        call init(xx1,xx2,xx3,xx4,xx5,xx6,xx7,xx8,xx9,xx10)
>>
>> Fun and games!
>>
>
> Nice idea.  Did I mention the 3,000 subroutines and functions ?
> 650,000 lines of code ?
>
> Thanks,
> Lynn

A 3000 element logical array is peanuts. (OK, you knew that...)

If you are prepared to use brute force (your term!) you may as well add a 
tiny bit of finesse... it costs very little extra if done from the start 
and may just pay you back nicely.

-- 
Qolin

Email: my qname at domain dot com
Domain: qomputing 

In article <i1mca4$426$1@speranza.aioe.org>,
 glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Richard Maine <nospam@see.signature> wrote:
> (snip)
>  
> > Fortran does not go in for mandatory enforcement of programming style by
> > the language spec. It is much more about providing the programmer with
> > options. Many of those style options can be verified/enforced if that is
> > one's inclination.
> 
> Maybe, but it does seem that some rules, or rule changes, were
> meant to discourage some uses.  One example is the removal of the
> use of REAL varaibles in DO loops, added in Fortran 77, then removed
> in Fortran 90.  Yes there can be problems in doing it, but, as
> you say the language shouldn't enforce the style.  I could probably
> think of some others, but that one comes to mind first.

I would say this issue is a little more than "style".  This was a 
mistake in the f77 standard, simple as that.  Not a fatal flaw, but a 
mistake nonetheless.  It should have been corrected shortly thereafter 
with a minor fortran revision (1980 or 1981), but that was delayed about 
a decade until f90, so that was the earliest that it could have been 
corrected.

I think of "style" issues as several functionally equivalent ways of 
doing something, but some are deemed "better" than others because of 
style preferences.  Integer and real do loop variables are not 
equivalent in this sense, the differences are more fundamental.

$.02 -Ron Shepard

On 15 Jul, 09:14, n...@cam.ac.uk wrote:

> That's nothing - C99 has introduced complex time :-)

I see that can be very useful.

On 2010-07-12, jfh <john.harper@vuw.ac.nz> wrote:
> On Jul 13, 12:35�am, mecej4 <mecej4.nyets...@operamail.com> wrote:
>
>> FORTRAN IV is more suggestive of a general or a pope than a numeral.
>
> A general??

Who is general failure, and why is he reading my hard disc?

On Jul 16, 5:41=A0am, Lynn McGuire <l...@winsim.com> wrote:
....
> Nice idea. =A0Did I mention the 3,000 subroutines and functions ?
> 650,000 lines of code ?
>
> Thanks,
> Lynn

I enjoyed going over this thread.

I noticed I couldn't follow the implications of suggestions made for
the newer compiler environments, but everything between "Fortran III"
and "F90" seemed to make sense.

I particulatly envy Lynn McGuire having a nice problem; I've been
bored resently, looking for something to program, and apart from
advising someone with few local resources, who mistook me for Richard,
on how to go from Fortran IV to something with a future, like F77
source (to get the new source compilable, not due to my preferences),
I'd like to find a new challenge.

Someone else was working on Hamming matrix generation, and still
another on DNA segment searching and matching, but I couldn't use the
results and so lost interest.

I've just been given a Mac Professional; I'd like to know what can be
suggested for sourcing a Forran compiler for native mode; my trusty
F77 compiler works fine in the MDSOS emulaion on the MAC, and the
resulting programs run execept for handling a tiny few of the function
and pad key keyboard combinations, but the programs are not new work.
Sigh.

And I've still got about 25 years more left to fill...

In article
<f2e04c74-9e7a-44e0-9924-84a2417f9991@s24g2000pri.googlegroups.com>,
Terence <tbwright@cantv.net> writes: 

> I noticed I couldn't follow the implications of suggestions made for
> the newer compiler environments, but everything between "Fortran III"
> and "F90" seemed to make sense.

F95 is what you want.  F95 is just a slight revision of F90, but all the 
additional stuff is really useful.  Also, I suspect that any compiler 
which supports F90 supports F95.

On 2010-07-24 08:15:56 -0300, Terence <tbwright@cantv.net> said:

> I've just been given a Mac Professional; I'd like to know what can be
> suggested for sourcing a Forran compiler for native mode; my trusty
> F77 compiler works fine in the MDSOS emulaion on the MAC, and the
> resulting programs run execept for handling a tiny few of the function
> and pad key keyboard combinations, but the programs are not new work.
> Sigh.

You can go commercial with NAG, Absoft and Intel the major vendors. Or
there ae the GNU "twins" of G95 and Gfortran. They all support F95 with
more and more F2003. Not to sure about "Forran".

For good debugging there is only one real choice - NAG. It will also
cure you of any inclination to try extensions so you code will almost
surely be portable.

Since your Mac Pro was a  gift you can show that you appreciate it by
going first class and paying for a NAG license. Install the GNU ones
to provide constructive demonstration of portability by compileing
with them once in a while.

In article <2010072411250216807-GordonSande@gmailcom>,
Gordon Sande  <Gordon.Sande@gmail.com> wrote:
>On 2010-07-24 08:15:56 -0300, Terence <tbwright@cantv.net> said:
>
>> I've just been given a Mac Professional; I'd like to know what can be
>> suggested for sourcing a Forran compiler for native mode; my trusty
>> F77 compiler works fine in the MDSOS emulaion on the MAC, and the
>> resulting programs run execept for handling a tiny few of the function
>> and pad key keyboard combinations, but the programs are not new work.
>> Sigh.
>
>You can go commercial with NAG, Absoft and Intel the major vendors. Or
>there ae the GNU "twins" of G95 and Gfortran. They all support F95 with
>more and more F2003. Not to sure about "Forran".
>
>For good debugging there is only one real choice - NAG. It will also
>cure you of any inclination to try extensions so you code will almost
>surely be portable.

It's also the only one that I know of that does array bound checking
across procedure calls - as far as I know, it's near bullet-proof in
that respect if you compile everything with -C=all and don't call C
or unchecked libraries.


Regards,
Nick Maclaren.

"Thomas Koenig" <tkoenig@netcologne.de> wrote in message 
news:i2a7gs$5og$1@newsreader5.netcologne.de...
> On 2010-07-12, jfh <john.harper@vuw.ac.nz> wrote:
>> On Jul 13, 12:35 am, mecej4 <mecej4.nyets...@operamail.com> wrote:
>>
>>> FORTRAN IV is more suggestive of a general or a pope than a numeral.
>>
>> A general??
>
> Who is general failure, and why is he reading my hard disc?

It says "Press any key to continue". ... Where's the "any" key?

On 7/26/10 3:15 PM, Colin Watters wrote:
> "Thomas Koenig"<tkoenig@netcologne.de>  wrote in message
> news:i2a7gs$5og$1@newsreader5.netcologne.de...
>> On 2010-07-12, jfh<john.harper@vuw.ac.nz>  wrote:
>>> On Jul 13, 12:35 am, mecej4<mecej4.nyets...@operamail.com>  wrote:
>>>
>>>> FORTRAN IV is more suggestive of a general or a pope than a numeral.
>>>
>>> A general??
>>
>> Who is general failure, and why is he reading my hard disc?
>
> It says "Press any key to continue". ... Where's the "any" key?
>
>
>
A search of google for "any key button" will lead you to
http://www.panicbuttons.com/
Unfortunately, the one I have only works on a desktop machine, unless 
you don't want to shut the lid on your laptop ;).

Dick Hendrickson

Most of your various recollections are incorrect.  Bob Freiburghouse
wrote the PL/I compiler and delivered both the subset G and the full ANSI
PL/I in 1978.  PLP was derived from the subset G compiler.  He also did
Fortran (written by David Levin, also ex Multics) and Bob wrote an extended
Pascal all of which used the common backend (actually there were 2, one for
Vmode and one for Imode architectures.)  Garth Conboy wrote a C compiler,  
1982,
(in C IIRC) which I think interfaced to the PL/I common backend, to which  
other
compilers were attached, such as Cobol.  Most of the OS up through 18 was
largely Fortran based, but 19 and on was a major revision and I do think  
large
new portions were in PLP.  There never was a SPL programming language at  
Prime
that I can recall, but I could be wrong, although
Siemens had several generations of a language by that name up through SPL  
IV
which ran on BS2000 which was the licensed version of the 360 knock-off  
from
RCA Spectra series sold to both Siemens and ICL (which they called the ICL  
4/72)

Computervision bought Prime, not the other way around, but was never able  
to
resurrect them after Ken Fisher drove the company into the ground.  Fisher  
went on
to form Encore Computers and managed to get Gordon Bell and a few others  
to join
him, but it was also a flop.

Tom

On Sun, 04 Jul 2010 03:59:06 -0700, Edward Feustel <efeustel@hughes.net>  
wrote:

>
> True. You can contact him on comp.sys.prime.  Not only does he have
> the emulated versions of the OS running, He has managed to collect
> many tools, languages, and I believe a few applications. I don't
> remember if he has the "ANSI PL1" but he needs SPL to compile pieces
> of the OS and many other utilities, etc.
>
> The OS versions are numbered 18 and up if I remember correctly.
> Ed
>
>
> On Wed, 30 Jun 2010 07:20:21 -0400, Peter Flass
> <Peter_Flass@Yahoo.com> wrote:
>
>> Edward Feustel wrote:
>>>  On Wed, 30 Jun 2010 12:34:21 +1000, "robin" <robin51@dodo.com.au>
>>> wrote:
>>>
>>>> "Lynn McGuire" <lmc@winsim.com> wrote in message  
>>>> news:i0do2r$pt4$1@news.eternal-september.org...
>>>> |> There are many Fortran compilers written in C, as far as I know,
>>>> | > no C compilers written in Fortran.
>>>> |
>>>> | If the old Prime computers had a C compiler, it was probably
>>>> | written in Fortran.  The whole operating system was written in
>>>> | a heavily extended fortran 66 until the 198? release which was
>>>> | rewritten in PL/1.
>>>>
>>>> That's interesting.
>>>>
>>> The original OS was in the public domain. It was written in the R-Mode
>>> instruction set, if I remember correctly.
>>>
>>> The PR1MOS system was written in the V-Mode instruction set.
>>>
>>> The C compiler did not get written until much later, in part because
>>> the Pr1me machine addressed to 16 bit quantities originally.
>>> Eventually a special instruction was added to permit easy byte
>>> addressing. Eventually C was done in the I-Mode and X-Mode instruction
>>> sets.
>>>
>>> The system programming language in the 80s was SPL a PL/1 variant
>>> a'la Multics. It had special system programming instructions and
>>> syntax. It was initially in V-Mode.
>>>
>>> There was an ANSI variant PL/1 as well.
>>>
>>> In the 90s work was begun on a Modula variant as the system
>>> programming language. A new OS was largely complete for an
>>> X-Mode instruction set, but the company bought Computervision
>>> and most development in the old Pr1me ceased.
>>>
>>> Ed Feustel
>>
>> Someone has a public-access PRIMOS system on emulated hardware -
>> actuallt three systems with different PRIMOS releases.


-- 
PL/I for OpenVMS
www.kednos.com

"Tom Linden" <tom@kednos.company> wrote in message news:op.vgx1dvzthv4qyg@murphus.hsd1.ca.comcast.net...
| Most of your various recollections are incorrect.  Bob Freiburghouse
| wrote the PL/I compiler

For what? 

"Tom Linden" <tom@kednos.company> wrote in message news:op.vgx1dvzthv4qyg@murphus.hsd1.ca.comcast.net...

| which ran on BS2000 which was the licensed version of the 360 knock-off
| from
| RCA Spectra series sold to both Siemens and ICL (which they called the ICL
| 4/72)

They sold it to the English Electric Co. who called it the 4-50 and 4-70.
Later, ICL acquired English Electric, and so the series became known as
the ICL 4-50 and 4-70.

There was also a model 4-30 that had only the integer instruction set,
plus DH (Divide Halfword, which the IBM S/370 lacked). 

robin wrote:
> "Tom Linden" <tom@kednos.company> wrote in message news:op.vgx1dvzthv4qyg@murphus.hsd1.ca.comcast.net...
> | Most of your various recollections are incorrect.  Bob Freiburghouse
> | wrote the PL/I compiler
> 
> For what? 
> 
> 

Pretty much everything;-)  IBM, of course, wrote their own, and I'm told 
Burroughs, but many other vendors had LPI do it for them.

http://www.multicians.org/pl1.html

On Wed, 04 Aug 2010 19:33:21 -0700, "Tom Linden" <tom@kednos.company>
wrote:


>
>Computervision bought Prime, not the other way around, but was never able  
>to
>resurrect them after Ken Fisher drove the company into the ground.  Fisher  
>went on
>to form Encore Computers and managed to get Gordon Bell and a few others  
>to join
>him, but it was also a flop.
>
>Tom
Tom,
My memory may be a bit shakey on the languages,
but I remember an SPL which was used in system programming.
I was in Engineering from 1980 through 1991.

I used Garth's original C and his later I-Mode version with byte
rather than half word characters which was used for Primix.

I think you are incorrect on the company's downfall.

Prime did buy Computervision which it kept as a division.
The leveraged buyout of Prime made Prime the cash cow
and Computervision the name of the survivor. Of course Computervision
was bought by PTC whose founders left Prime when Prime still
was vending its own CAD products.

I don't credit Ken Fisher with the flop. I'd give that "honor" to 
Joe Henson, his successor. We were to be all things to all customers
and lost focus.

Ed Feustel

On Wed, 04 Aug 2010 19:33:21 -0700, "Tom Linden" <tom@kednos.company>
wrote:

>Most of your various recollections are incorrect.  Bob Freiburghouse
>wrote the PL/I compiler and delivered both the subset G and the full ANSI
>PL/I in 1978.  PLP was derived from the subset G compiler.  He also did
>Fortran (written by David Levin, also ex Multics) and Bob wrote an extended
>Pascal all of which used the common backend (actually there were 2, one for
>Vmode and one for Imode architectures.)  Garth Conboy wrote a C compiler,  
>1982,
>(in C IIRC) which I think interfaced to the PL/I common backend, to which  
>other
>compilers were attached, such as Cobol.  Most of the OS up through 18 was
>largely Fortran based, but 19 and on was a major revision and I do think  
>large
>new portions were in PLP.  There never was a SPL programming language at  
>Prime
>that I can recall, but I could be wrong, although
>Siemens had several generations of a language by that name up through SPL  

Tom, 
See the wikipedia article on Prime.
It mentions SPL and the various buyouts.
Ed

On 5 Aug, 08:42, Edward Feustel <efeus...@hughes.net> wrote:
> On Wed, 04 Aug 2010 19:33:21 -0700, "Tom Linden" <t...@kednos.company>
> wrote:
>
>
>
> >Most of your various recollections are incorrect. =A0Bob Freiburghouse
> >wrote the PL/I compiler and delivered both the subset G and the full ANS=
I
> >PL/I in 1978. =A0PLP was derived from the subset G compiler. =A0He also =
did
> >Fortran (written by David Levin, also ex Multics) and Bob wrote an exten=
ded
> >Pascal all of which used the common backend (actually there were 2, one =
for
> >Vmode and one for Imode architectures.) =A0Garth Conboy wrote a C compil=
er, =A0
> >1982,
> >(in C IIRC) which I think interfaced to the PL/I common backend, to whic=
h =A0
> >other
> >compilers were attached, such as Cobol. =A0Most of the OS up through 18 =
was
> >largely Fortran based, but 19 and on was a major revision and I do think=
 =A0
> >large
> >new portions were in PLP. =A0There never was a SPL programming language =
at =A0
> >Prime
> >that I can recall, but I could be wrong, although
> >Siemens had several generations of a language by that name up through SP=
L =A0
>
> Tom,
> See the wikipedia article on Prime.
> It mentions SPL and the various buyouts.
> Ed

The SPL compiler was derived from the PL/1-G compiler that was
originally written by Bob Freiburghouse.  Most of the other languages
offered as Prime products in the 80's (Fortran-77, ANSI Cobol, ANSI PL/
1, Pascal, and even Modula-2) were all based on this technology.  They
all had to translate into the PL/1 abstract machine that was the core
of this compiler technology.  SPL was not released to customers.  It
was strictly an in-house development tool.

The PL/P compiler was not based on this technology.  From what I
understand, it was actually the result of a grad school project done
by Mark Johnson.  It was PL/1-like, but not strictly PL/1.  Some
products originally written in PL/P were subsequently upgraded to
SPL.  Others were not, so PL/P had to be supported as an in-house
tool.

The initial Prime operating system (and the system boot-up) were
written in Fortran-66, using the "Systems Programming Option".  You
would see sequences like this:
    =3D X // load the variable X into the accumulator
    CALL FOO
....
    SUBROUTINE FOO
    Y=3D  // retrieve the contents of the accumulator and store it into
Y
This is how they accomplished passing arguments "by value", since in
Fortran, everything is passed by reference, or value/result.  A
kludge, but effective.

Someone had mentioned XPL.  This was written as a compiler-writers
tool as described in the book "A Compiler Generator", by McKeeman,
Hornung and Wortman.  It is also PL/1-like, but wasn't really PL/1.
It wasn't even a proper subset.  The HAL/S language (used to program
the Space Shuttle guidance and navigation computers) was written in
XPL.  It was heavily dependent on 360-style addressing, so porting it
to a different technology required a lot of work.  There was never a
port of XPL onto the Prime system.

-AndyJ

"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message news:i3dpb3$qmd$1@news.eternal-september.org...
| robin wrote:
| > "Tom Linden" <tom@kednos.company> wrote in message news:op.vgx1dvzthv4qyg@murphus.hsd1.ca.comcast.net...
| > | Most of your various recollections are incorrect.  Bob Freiburghouse
| > | wrote the PL/I compiler
| >
| > For what?
|
| Pretty much everything;-)  IBM, of course, wrote their own, and I'm told
| Burroughs, but many other vendors had LPI do it for them.

There were quite a few PL/I compilers, and the LPI PL/I
came rather late.

OTOMH   PL/C, CIMS PL/I, CDC, Wang, Olivetti, Q1, Digital Research PL/I,
ICL (not released) were some of those that were produced relatively early. 

In <4c5ac9c3$0$34572$c30e37c6@exi-reader.telstra.net>, on 08/06/2010
   at 12:24 AM, "robin" <robin51@dodo.com.au> said:

>OTOMH   PL/C,

Not PL/I, although it was close.

>Digital Research PL/I,

Not even close.

If you're going to consider PL/I-like languages, there were als PL/CS
and XPL.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org