Thread: Re: [Dev-C++] Mixed Language Programming w/Dev-Cpp

That is really ugly code! I'm sorry but please give variables meaningful 
names! And use Whitespace!

Sorry, I've been reading Code Complete recently. Excellent book - by Steve 
McConnell. A bit dated in places but excellent for ALL programmers (language 
and experience independent).


>From: "Scott Williams" Reply-To: To: "Dev-Cpp-Users@Lists. Sourceforge. 
>Net" Subject: [Dev-C++] Mixed Language Programming w/Dev-Cpp Date: Tue, 29 
>Oct 2002 15:33:56 -0500
>
>Hi,
>
>Wondering if anyone has experience with mixed language programming and 
>whether it can be done with Dev-Cpp?
>
>In particular, I'm writing a mathematical simulation in C (using Dev-Cpp) 
>and would like to make using of some existing numerical routines in 
>Fortran. My C knowledge is necessity-based self-taught and so limited; 
>don't know anything about Fortran. Neither do I know much about using 
>compilers/linkers/etc in command line mode (which is why I use Dev-Cpp--I 
>let it worry about that stuff).
>
>Still, I know that built-in to the gcc interface is the g77 compiler so 
>there must be a way to compile the fortran source to an object with g77 and 
>then link to & call the routines from C. Could it be as simple as added 
>fortran source files to my Dev-Cpp project? If so, any thoughts on how to 
>prototype the Fortran functions & subfunctions to make them accessible to 
>the C calling routines?
>
>BTW, I've tried f2c but have been unable to make that work. That approach 
>is suboptimal anyway because the resulting C code is far less efficient 
>than the original Fortran source.
>
>Perhaps specifics would help. The fortran code I'm trying to use is a 
>single file ode.f The entry point is the subroutine ode. Here's how the 
>file is laid out:
>
>// ode.f
>
>subroutine ode(f,neqn,y,t,tout,relerr,abserr,iflag,work,iwork) implicit 
>real*8(a-h,o-z)
>
>c f -- double precision subroutine f(t,y,yp) to evaluate c derivatives 
>yp(i)=dy(i)/dt c neqn -- number of equations to be integrated (integer*4) c 
>y(*) -- solution vector at t (real*8) c t -- independent variable (real*8) 
>c tout -- point at which solution is desired (real*8) c relerr,abserr -- 
>relative and absolute error tolerances for local c error test (real*8). at 
>each step the code requires c dabs(local error) .le. dabs(y)*relerr + 
>abserr c for each component of the local error and solution vectors c iflag 
>-- indicates status of integration (integer*4) c work(*) (real*8) -- arrays 
>to hold information internal to c iwork(*) (integer*4) which is necessary 
>for subsequent calls
>
>. . . ode calls de: subroutine de(f,neqn,y,t,tout,relerr,abserr,iflag, 1 
>yy,wt,p,yp,ypout,phi,alpha,beta,sig,v,w,g,phase1,psi,x,h,hold, 2 
>start,told,delsgn,ns,nornd,k,kold,isnold) implicit real*8(a-h,o-z)
>
>. . . de calls step & intrp: subroutine step(x,y,f,neqn,h,eps,wt,start, 1 
>hold,k,kold,crash,phi,p,yp,psi, 2 alpha,beta,sig,v,w,g,phase1,ns,nornd) 
>implicit real*8(a-h,o-z)
>
>subroutine intrp(x,y,xout,yout,ypout,neqn,kold,phi,psi) implicit 
>real*8(a-h,o-z) // end ode.f
>
>The derivative function f is written in C (and that's where I was having 
>probs with the f2c route).
>
>All help is appreciated (sorry for the long post).
>
>Scott
>
>
>
>------------------------------------------------------- This sf.net email 
>is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf 
>_______________________________________________ Dev-cpp-users mailing list 
>Dev...@li... TO UNSUBSCRIBE: 
>http://www.noicys.cjb.net/devcpp/ub.htm 
>https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

_________________________________________________________________
Surf the Web without missing calls! Get MSN Broadband. 
http://resourcecenter.msn.com/access/plans/freeactivation.asp

LOL oh yes! Quite right, I apologise. Still, in my browser it looks a little 
difficult to read.
It's early here lol. Once again sorry about that.

Still, Code Complete is a very good book ;)

>From: "Scott Williams" <se...@al...>
>Reply-To: <se...@al...>
>To: "Daniel Glenfield" 
><sp...@ho...>,<dev...@li...>
>Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp
>Date: Wed, 30 Oct 2002 03:23:17 -0500
>
>Well. . . there wasn't any 'code' in my message, just a sketch of the
>fortran subroutine prototypes I'm trying to call from c.  If you read my
>message, you'll note the source of the 'code' is an existing numerical
>package.  The author's standards of variable naming/white space use are of
>little concern to me and certainly have nothing to do with the question
>posed.
>
>Scott
>
>-----Original Message-----
>From: Daniel Glenfield [mailto:sp...@ho...]
>Sent: Wednesday, October 30, 2002 3:08 AM
>To: se...@al...; dev...@li...
>Subject: Re: [Dev-C++] Mixed Language Programming w/Dev-Cpp
>
>
>That is really ugly code! I'm sorry but please give variables meaningful
>names! And use Whitespace!
>
>Sorry, I've been reading Code Complete recently. Excellent book - by Steve
>McConnell. A bit dated in places but excellent for ALL programmers 
>(language
>and experience independent).
>
>
> >From: "Scott Williams" Reply-To: To: "Dev-Cpp-Users@Lists. Sourceforge.
> >Net" Subject: [Dev-C++] Mixed Language Programming w/Dev-Cpp Date: Tue, 
>29
> >Oct 2002 15:33:56 -0500
> >
> >Hi,
> >
> >Wondering if anyone has experience with mixed language programming and
> >whether it can be done with Dev-Cpp?
> >
> >In particular, I'm writing a mathematical simulation in C (using Dev-Cpp)
> >and would like to make using of some existing numerical routines in
> >Fortran. My C knowledge is necessity-based self-taught and so limited;
> >don't know anything about Fortran. Neither do I know much about using
> >compilers/linkers/etc in command line mode (which is why I use Dev-Cpp--I
> >let it worry about that stuff).
> >
> >Still, I know that built-in to the gcc interface is the g77 compiler so
> >there must be a way to compile the fortran source to an object with g77 
>and
> >then link to & call the routines from C. Could it be as simple as added
> >fortran source files to my Dev-Cpp project? If so, any thoughts on how to
> >prototype the Fortran functions & subfunctions to make them accessible to
> >the C calling routines?
> >
> >BTW, I've tried f2c but have been unable to make that work. That approach
> >is suboptimal anyway because the resulting C code is far less efficient
> >than the original Fortran source.
> >
> >Perhaps specifics would help. The fortran code I'm trying to use is a
> >single file ode.f The entry point is the subroutine ode. Here's how the
> >file is laid out:
> >
> >// ode.f
> >
> >subroutine ode(f,neqn,y,t,tout,relerr,abserr,iflag,work,iwork) implicit
> >real*8(a-h,o-z)
> >
> >c f -- double precision subroutine f(t,y,yp) to evaluate c derivatives
> >yp(i)=dy(i)/dt c neqn -- number of equations to be integrated (integer*4) 
>c
> >y(*) -- solution vector at t (real*8) c t -- independent variable 
>(real*8)
> >c tout -- point at which solution is desired (real*8) c relerr,abserr --
> >relative and absolute error tolerances for local c error test (real*8). 
>at
> >each step the code requires c dabs(local error) .le. dabs(y)*relerr +
> >abserr c for each component of the local error and solution vectors c 
>iflag
> >-- indicates status of integration (integer*4) c work(*) (real*8) -- 
>arrays
> >to hold information internal to c iwork(*) (integer*4) which is necessary
> >for subsequent calls
> >
> >. . . ode calls de: subroutine de(f,neqn,y,t,tout,relerr,abserr,iflag, 1
> >yy,wt,p,yp,ypout,phi,alpha,beta,sig,v,w,g,phase1,psi,x,h,hold, 2
> >start,told,delsgn,ns,nornd,k,kold,isnold) implicit real*8(a-h,o-z)
> >
> >. . . de calls step & intrp: subroutine step(x,y,f,neqn,h,eps,wt,start, 1
> >hold,k,kold,crash,phi,p,yp,psi, 2 alpha,beta,sig,v,w,g,phase1,ns,nornd)
> >implicit real*8(a-h,o-z)
> >
> >subroutine intrp(x,y,xout,yout,ypout,neqn,kold,phi,psi) implicit
> >real*8(a-h,o-z) // end ode.f
> >
> >The derivative function f is written in C (and that's where I was having
> >probs with the f2c route).
> >
> >All help is appreciated (sorry for the long post).
> >
> >Scott
> >
> >
> >
> >------------------------------------------------------- This sf.net email
> >is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
> >_______________________________________________ Dev-cpp-users mailing 
>list
> >Dev...@li... TO UNSUBSCRIBE:
> >http://www.noicys.cjb.net/devcpp/ub.htm
> >https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>
>_________________________________________________________________
>Surf the Web without missing calls! Get MSN Broadband.
>http://resourcecenter.msn.com/access/plans/freeactivation.asp
>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Dev-cpp-users mailing list
>Dev...@li...
>TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
>https://lists.sourceforge.net/lists/listinfo/dev-cpp-users


_________________________________________________________________
Get faster connections -- switch to MSN Internet Access! 
http://resourcecenter.msn.com/access/plans/default.asp

To Ioannis,

Funny thing is I was reading an old Turbo C reference guide I have lying
around that mentioned linking Turbo C and Turbo Fortran (was it called
that?). Borland seemed to very proud of this cross language linking. There
are some difficulties with function name decoration and what-not that you
need to be aware of. I can't quite recall what they were, but I'll try to
remember to take a look this evening.

I'm not sure if the same advice will apply here since it is clearly
different compilers, but it may give you an idea. I'd still look on the net
for info specific to the compilers you want to use.

To Per,
Is there anything you don't know anything about? (LOL).

I don't recall if the above mentioned book mentioned any difficulties with
multi-dimensional arrays. Besides, as far as I'm aware, C uses arrays of
arrays and not multi-dimensional arrays, so would the trick not be to set
your arrays up in the same way that Fortran does?

_____________________________
Marc Heiligers


-----Original Message-----
From: Per Westermark [mailto:pw...@ia...] 
Sent: 30 October 2002 11:40 AM
To: Ioannis Vranos
Cc: Dev-C++ Mailing List
Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp


I think there might be acoule of gotchas more to think about.

Doesn't fortran have the reversed row/column order for multi-dimensional
arrays?

Anyway, I assume that there already exists excellent FAQ documents for this
kind of problems.

/Per W

On Wed, 30 Oct 2002, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: dev...@li...
> > [mailto:dev...@li...] On Behalf 
> > Of Scott Williams
> > Sent: Tuesday, October 29, 2002 10:34 PM
> > To: Dev-Cpp-Users@Lists. Sourceforge. Net
> > Subject: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> > 
> > 
> > Hi,
> > 
> > Wondering if anyone has experience with mixed language programming 
> > and whether it can be done with Dev-Cpp?
> > 
> > In particular, I'm writing a mathematical simulation in C
> > (using Dev-Cpp)
> > and would like to make using of some existing numerical 
> > routines in Fortran.
> > My C knowledge is necessity-based self-taught and so limited; 
> > don't know
> > anything about Fortran.  Neither do I know much about using
> > compilers/linkers/etc in command line mode (which is why I 
> > use Dev-Cpp--I
> > let it worry about that stuff).
> > 
> > Still, I know that built-in to the gcc interface is the g77
> > compiler so
> > there must be a way to compile the fortran source to an 
> > object with g77 and
> > then link to & call the routines from C.  Could it be as 
> > simple as added
> > fortran source files to my Dev-Cpp project?  If so, any 
> > thoughts on how to
> > prototype the Fortran functions & subfunctions to make them 
> > accessible to
> > the C calling routines?
> 
> 
> Well if you download the whole MINGW distribution it contains a 
> Fortran compiler. In theory as i can think of it, if you compile your 
> fortran source code files to .o files and use C-style declarations of 
> those functions in your C source code, you should be able to use them.
> 
> 
> Ioannis
> 
> * Ioannis Vranos
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL: http://run.to/noicys
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf 
> _______________________________________________
> Dev-cpp-users mailing list Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> 

When you have declared
double a[10][10]
it is quite important to know in which order the individual values are
stored in memory, when trying to interface between two languages.

If your C program does a[x][y] and your Fortran program has do do
a[z][y] to reach the same entry. No problem when you have all three
index variables available.

However, when you take a pointer to a an entry inside the array, the
operation might be seen as a projection down to an array with fewer
dimensions. Obviously, if the entry order in memory has been transposed,
the such a projection will fail misserably when switching languages. The 
sender thought it sent a row, but the receiver got a column.

When people originally started to push for the C language, the above
problem gave rise to a related problem. When referencing large memory
structures, it is important to assure that the code uses locality of
reference and doesn't jump around everywhere in the data. Large linear
packages are always implemented so that they process entries in the same
order that they are stored in memory. When converting such an algorithm -
might be thousands uppon thousands of lines of code - it isn't s easy to
just try and adjust for row/column switches. The result is that a C
translation of a Fortran algorithm might loose 10-30% or maybe more of the
speed when the same Fortran algorithm was run.
The mathematical world decided that C was a slower language :-) Nowadays,
there are a lot of good algorithms originally written for C, so this issue
shouldn't be a problem anymore. But still, there are some billion
Fortran lines of optimized and very advanced mathematics algorithms out
there.

/Per W

On Wed, 30 Oct 2002, Marc Heiligers wrote:

> To Ioannis,
> 
> Funny thing is I was reading an old Turbo C reference guide I have lying
> around that mentioned linking Turbo C and Turbo Fortran (was it called
> that?). Borland seemed to very proud of this cross language linking. There
> are some difficulties with function name decoration and what-not that you
> need to be aware of. I can't quite recall what they were, but I'll try to
> remember to take a look this evening.
> 
> I'm not sure if the same advice will apply here since it is clearly
> different compilers, but it may give you an idea. I'd still look on the net
> for info specific to the compilers you want to use.
> 
> To Per,
> Is there anything you don't know anything about? (LOL).
> 
> I don't recall if the above mentioned book mentioned any difficulties with
> multi-dimensional arrays. Besides, as far as I'm aware, C uses arrays of
> arrays and not multi-dimensional arrays, so would the trick not be to set
> your arrays up in the same way that Fortran does?
> 
> _____________________________
> Marc Heiligers
> 
> 
> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...] 
> Sent: 30 October 2002 11:40 AM
> To: Ioannis Vranos
> Cc: Dev-C++ Mailing List
> Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> 
> 
> I think there might be acoule of gotchas more to think about.
> 
> Doesn't fortran have the reversed row/column order for multi-dimensional
> arrays?
> 
> Anyway, I assume that there already exists excellent FAQ documents for this
> kind of problems.
> 
> /Per W
> 
> On Wed, 30 Oct 2002, Ioannis Vranos wrote:
> 
> > > -----Original Message-----
> > > From: dev...@li...
> > > [mailto:dev...@li...] On Behalf 
> > > Of Scott Williams
> > > Sent: Tuesday, October 29, 2002 10:34 PM
> > > To: Dev-Cpp-Users@Lists. Sourceforge. Net
> > > Subject: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> > > 
> > > 
> > > Hi,
> > > 
> > > Wondering if anyone has experience with mixed language programming 
> > > and whether it can be done with Dev-Cpp?
> > > 
> > > In particular, I'm writing a mathematical simulation in C
> > > (using Dev-Cpp)
> > > and would like to make using of some existing numerical 
> > > routines in Fortran.
> > > My C knowledge is necessity-based self-taught and so limited; 
> > > don't know
> > > anything about Fortran.  Neither do I know much about using
> > > compilers/linkers/etc in command line mode (which is why I 
> > > use Dev-Cpp--I
> > > let it worry about that stuff).
> > > 
> > > Still, I know that built-in to the gcc interface is the g77
> > > compiler so
> > > there must be a way to compile the fortran source to an 
> > > object with g77 and
> > > then link to & call the routines from C.  Could it be as 
> > > simple as added
> > > fortran source files to my Dev-Cpp project?  If so, any 
> > > thoughts on how to
> > > prototype the Fortran functions & subfunctions to make them 
> > > accessible to
> > > the C calling routines?
> > 
> > 
> > Well if you download the whole MINGW distribution it contains a 
> > Fortran compiler. In theory as i can think of it, if you compile your 
> > fortran source code files to .o files and use C-style declarations of 
> > those functions in your C source code, you should be able to use them.
> > 
> > 
> > Ioannis
> > 
> > * Ioannis Vranos
> > * Programming pages: http://www.noicys.freeurl.com
> > * Alternative URL: http://run.to/noicys
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf 
> > _______________________________________________
> > Dev-cpp-users mailing list Dev...@li...
> > TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> > 
> 
> 
> 

> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...] 
> Sent: Wednesday, October 30, 2002 2:11 PM
> To: Marc Heiligers
> Cc: Ioannis Vranos; Dev-C++ Mailing List
> Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> 
> 
> When you have declared
> double a[10][10]
> it is quite important to know in which order the individual values are
> stored in memory, when trying to interface between two languages.
> 
> If your C program does a[x][y] and your Fortran program has do do
> a[z][y] to reach the same entry. No problem when you have all three
> index variables available.


It's a syntax matter. As far as i can guess Fortran implementation is
not required to store them in that order.



> However, when you take a pointer to a an entry inside the array, the
> operation might be seen as a projection down to an array with fewer
> dimensions. Obviously, if the entry order in memory has been 
> transposed,
> the such a projection will fail misserably when switching 
> languages. The 
> sender thought it sent a row, but the receiver got a column.
> 
> When people originally started to push for the C language, the above
> problem gave rise to a related problem. When referencing large memory
> structures, it is important to assure that the code uses locality of
> reference and doesn't jump around everywhere in the data. Large linear
> packages are always implemented so that they process entries 
> in the same
> order that they are stored in memory. When converting such an 
> algorithm -
> might be thousands uppon thousands of lines of code - it 
> isn't s easy to
> just try and adjust for row/column switches. The result is that a C
> translation of a Fortran algorithm might loose 10-30% or 
> maybe more of the
> speed when the same Fortran algorithm was run.

Why?

> The mathematical world decided that C was a slower language 
> :-) 


Well, one of the reasons that Fortran is fast is because it is heavily
optimised during those years and not because its syntax is close to the
metal. Now this doesn't apply anymore.

Check the following: 

http://csweb1.cs.tamu.edu/seminars/dlecture/abstracts/stroustrup.MPP-sli
des.pdf


where it has the graphh with the title "Uncompromising Performance".



> Nowadays,
> there are a lot of good algorithms originally written for C, 
> so this issue
> shouldn't be a problem anymore. But still, there are some billion
> Fortran lines of optimized and very advanced mathematics 
> algorithms out
> there.


Yes there are indeed.


Btw, Fortran has the notion of pointers?


Ioannis

* Ioannis Vranos
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

The speed issue isn't in this case a question about the efficiency of
Fortran or C, but the efficiency of porting an algorithm written for one
language to another language.

The array index  order of a language - many languages, but not all - may
not be changed in the language implementation, but are specified in the
description of the language.

The internal cache lines in the processor have a lot wider access path
than the primary memory. For a 32-bit processor, the memory access path
might be 64 bit, but the cache-lines might be 128 bit, 256 bit or even
wider. Everytime the processor doesn't find it's data in a cache line, it
has to wait for the data to be fetched from primary memory. That takes a
lot of time. Obviously, any memory-intensive algorithm should make sure
that the access pattern matches the physical storage of the data. Data
here isn't just integers and floats to perform math on, but just as
well the generated object code.

When programming in a high-level language, you normally doesn't have to
think so much about generated object code. That's up to the compiler.

However, the data layout is important. If I know that a specific processor
always loads at least 16 bytes from memory, whenever a cache line fails, I
may decide to place my 16 byte of "favorite" data first in any used
struct, so that the processor loads all the data from memory at a single
time, thereby reducing number of cache stalls.

On a bigger scale, when solving linear equations, the used matrices might
very well be 10000x10000 entries large. If each entry is a 8-byte double,
such a matrix will then consume 800 MB memory. If the machine hasn't that
amount of memory, it will start to swap out data to disk. A typical swap
block size might be 4kB, or 500 double numbers. If the program accesses
the entries in a sequential way, each disk load will guarantee 500
successful accesses before a new disk load is needed. If the program
accesses the entries in a random order (or with row/column swapped), EVERY
new accessed entry will require a disk load operation...

This isn't a problem for script languages etc, but a reason why few
"efficiency-oriented" programming languages leaves the definition
of array index order up to the implementation. For small structures, a
row/column transpose might double the execution time because of cache
trashing. For large structures, where swapping is needed, the speed
difference might be a factor of several thousand.

Most good Fortran algorithms contains thousands of thousands of lines of
code specifically designed to access the needed data in optimum order.
That is an important reason why it takes thousands of thousands of lines
of C code to match the performance. The same goes with just about any
programming language. Understanding of language and target machine might
be the difference between being able to solve a problem, or having to wait
a couple of years for faster machines to be released.

/Per W

On Wed, 30 Oct 2002, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Per Westermark [mailto:pw...@ia...] 
> > Sent: Wednesday, October 30, 2002 2:11 PM
> > To: Marc Heiligers
> > Cc: Ioannis Vranos; Dev-C++ Mailing List
> > Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> > 
> > 
> > When you have declared
> > double a[10][10]
> > it is quite important to know in which order the individual values are
> > stored in memory, when trying to interface between two languages.
> > 
> > If your C program does a[x][y] and your Fortran program has do do
> > a[z][y] to reach the same entry. No problem when you have all three
> > index variables available.
> 
> 
> It's a syntax matter. As far as i can guess Fortran implementation is
> not required to store them in that order.
> 
> 
> 
> > However, when you take a pointer to a an entry inside the array, the
> > operation might be seen as a projection down to an array with fewer
> > dimensions. Obviously, if the entry order in memory has been 
> > transposed,
> > the such a projection will fail misserably when switching 
> > languages. The 
> > sender thought it sent a row, but the receiver got a column.
> > 
> > When people originally started to push for the C language, the above
> > problem gave rise to a related problem. When referencing large memory
> > structures, it is important to assure that the code uses locality of
> > reference and doesn't jump around everywhere in the data. Large linear
> > packages are always implemented so that they process entries 
> > in the same
> > order that they are stored in memory. When converting such an 
> > algorithm -
> > might be thousands uppon thousands of lines of code - it 
> > isn't s easy to
> > just try and adjust for row/column switches. The result is that a C
> > translation of a Fortran algorithm might loose 10-30% or 
> > maybe more of the
> > speed when the same Fortran algorithm was run.
> 
> Why?
> 
> > The mathematical world decided that C was a slower language 
> > :-) 
> 
> 
> Well, one of the reasons that Fortran is fast is because it is heavily
> optimised during those years and not because its syntax is close to the
> metal. Now this doesn't apply anymore.
> 
> Check the following: 
> 
> http://csweb1.cs.tamu.edu/seminars/dlecture/abstracts/stroustrup.MPP-sli
> des.pdf
Very good document. Exactly my point. A language is efficient when it is
used in the correct way. One interesting note.
On page 7, the "bumpines" of the curves clearly display how the different
algorithms and compiler optimization has managed to optimize the memory
accesses.

> 
> 
> where it has the graphh with the title "Uncompromising Performance".
> 
> 
> 
> > Nowadays,
> > there are a lot of good algorithms originally written for C, 
> > so this issue
> > shouldn't be a problem anymore. But still, there are some billion
> > Fortran lines of optimized and very advanced mathematics 
> > algorithms out
> > there.
> 
> 
> Yes there are indeed.
> 
> 
> Btw, Fortran has the notion of pointers?
Call by reference is an important concept, and one where the index order
is significant, if you only send a reference to a part of a larger matrix.
> 
> 
> Ioannis
> 
> * Ioannis Vranos
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL: http://run.to/noicys
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future 
> of Java(TM) technology. Join the Java Community 
> Process(SM) (JCP(SM)) program now. 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> 

> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...] 
> Sent: Wednesday, October 30, 2002 11:49 PM
> To: Ioannis Vranos
> Cc: 'Dev-C++ Mailing List'
> Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> 
> 
> The speed issue isn't in this case a question about the efficiency of
> Fortran or C, but the efficiency of porting an algorithm 
> written for one
> language to another language.
> 
> The array index  order of a language - many languages, but 
> not all - may
> not be changed in the language implementation, but are 
> specified in the
> description of the language.
> 
> The internal cache lines in the processor have a lot wider access path
> than the primary memory. For a 32-bit processor, the memory 
> access path
> might be 64 bit, but the cache-lines might be 128 bit, 256 bit or even
> wider. Everytime the processor doesn't find it's data in a 
> cache line, it
> has to wait for the data to be fetched from primary memory. 
> That takes a
> lot of time. Obviously, any memory-intensive algorithm should 
> make sure
> that the access pattern matches the physical storage of the data. Data
> here isn't just integers and floats to perform math on, but just as
> well the generated object code.
> 
> When programming in a high-level language, you normally 
> doesn't have to
> think so much about generated object code. That's up to the compiler.
> 
> However, the data layout is important. If I know that a 
> specific processor
> always loads at least 16 bytes from memory, whenever a cache 
> line fails, I
> may decide to place my 16 byte of "favorite" data first in any used
> struct, so that the processor loads all the data from memory 
> at a single
> time, thereby reducing number of cache stalls.
> 
> On a bigger scale, when solving linear equations, the used 
> matrices might
> very well be 10000x10000 entries large. If each entry is a 
> 8-byte double,
> such a matrix will then consume 800 MB memory. If the machine 
> hasn't that
> amount of memory, it will start to swap out data to disk. A 
> typical swap
> block size might be 4kB, or 500 double numbers. If the 
> program accesses
> the entries in a sequential way, each disk load will guarantee 500
> successful accesses before a new disk load is needed. If the program
> accesses the entries in a random order (or with row/column 
> swapped), EVERY
> new accessed entry will require a disk load operation...


All these are true. However all these that you say apply to dedicated
machines. In a regular whatever PC with whatever multitasking OS you
can't control the cache etc. So regarding the question of the fellow,
there can not be an impact in speed.



> 
> This isn't a problem for script languages etc, but a reason why few
> "efficiency-oriented" programming languages leaves the definition
> of array index order up to the implementation. For small structures, a
> row/column transpose might double the execution time because of cache
> trashing. For large structures, where swapping is needed, the speed
> difference might be a factor of several thousand.
> 
> Most good Fortran algorithms contains thousands of thousands 
> of lines of
> code specifically designed to access the needed data in optimum order.
> That is an important reason why it takes thousands of 
> thousands of lines
> of C code to match the performance. 

I disagree. If you mean C algorithms accessing Fortran structures i can
agree, only when talking about a dedicated system.
On non-dedicated systems, and C structures C code can be the same
efficient (and sometimes even more).




> The same goes with just about any
> programming language. Understanding of language and target 
> machine might
> be the difference between being able to solve a problem, or 
> having to wait
> a couple of years for faster machines to be released.

Yes.


Ioannis

* Ioannis Vranos
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

On Thu, 31 Oct 2002, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Per Westermark [mailto:pw...@ia...] 
> > Sent: Wednesday, October 30, 2002 11:49 PM
> > To: Ioannis Vranos
> > Cc: 'Dev-C++ Mailing List'
> > Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> > 
> > 
> > The speed issue isn't in this case a question about the efficiency of
> > Fortran or C, but the efficiency of porting an algorithm 
> > written for one
> > language to another language.
> > 
> > The array index  order of a language - many languages, but 
> > not all - may
> > not be changed in the language implementation, but are 
> > specified in the
> > description of the language.
> > 
> > The internal cache lines in the processor have a lot wider access path
> > than the primary memory. For a 32-bit processor, the memory 
> > access path
> > might be 64 bit, but the cache-lines might be 128 bit, 256 bit or even
> > wider. Everytime the processor doesn't find it's data in a 
> > cache line, it
> > has to wait for the data to be fetched from primary memory. 
> > That takes a
> > lot of time. Obviously, any memory-intensive algorithm should 
> > make sure
> > that the access pattern matches the physical storage of the data. Data
> > here isn't just integers and floats to perform math on, but just as
> > well the generated object code.
> > 
> > When programming in a high-level language, you normally 
> > doesn't have to
> > think so much about generated object code. That's up to the compiler.
> > 
> > However, the data layout is important. If I know that a 
> > specific processor
> > always loads at least 16 bytes from memory, whenever a cache 
> > line fails, I
> > may decide to place my 16 byte of "favorite" data first in any used
> > struct, so that the processor loads all the data from memory 
> > at a single
> > time, thereby reducing number of cache stalls.
> > 
> > On a bigger scale, when solving linear equations, the used 
> > matrices might
> > very well be 10000x10000 entries large. If each entry is a 
> > 8-byte double,
> > such a matrix will then consume 800 MB memory. If the machine 
> > hasn't that
> > amount of memory, it will start to swap out data to disk. A 
> > typical swap
> > block size might be 4kB, or 500 double numbers. If the 
> > program accesses
> > the entries in a sequential way, each disk load will guarantee 500
> > successful accesses before a new disk load is needed. If the program
> > accesses the entries in a random order (or with row/column 
> > swapped), EVERY
> > new accessed entry will require a disk load operation...
> 
> 
> All these are true. However all these that you say apply to dedicated
> machines. In a regular whatever PC with whatever multitasking OS you
> can't control the cache etc. So regarding the question of the fellow,
> there can not be an impact in speed.
No, the concept is just about the same for any machine. It is just the
width of the memory interface, the cache line sizes, the number of cache
lines etc that are different. A Fortran (or C, Pascal etc) program
optimized for locality of reference of data accesses will will gain speed
on just about any computer architecture. It doesn't matter if we talk
about Von Neuman, SIMD, MIMD or whatever kind of machine. The physical
properties of memory still applies, i.e. cache is faster than primary
memory, primary memory is faster than disk.
The original Fortran algorithms might have been written for a Vax machine,
but the same optimizations still improves the speed on a Xeon processor.
> 
> 
> > 
> > This isn't a problem for script languages etc, but a reason why few
> > "efficiency-oriented" programming languages leaves the definition
> > of array index order up to the implementation. For small structures, a
> > row/column transpose might double the execution time because of cache
> > trashing. For large structures, where swapping is needed, the speed
> > difference might be a factor of several thousand.
> > 
> > Most good Fortran algorithms contains thousands of thousands 
> > of lines of
> > code specifically designed to access the needed data in optimum order.
> > That is an important reason why it takes thousands of 
> > thousands of lines
> > of C code to match the performance. 
> 
> I disagree. If you mean C algorithms accessing Fortran structures i can
> agree, only when talking about a dedicated system.
> On non-dedicated systems, and C structures C code can be the same
> efficient (and sometimes even more).
You disagree, while still agreeing :-) I am talking about algorithmig
optimization, not language optimization, and I am talking about the
problem of just translating an algorithm from one language to another
while still keeping the speed. Take a C++ template solution with sort. I
can't easily convert that code to another language. However, I can still
get the same speed in a Pascal program by doing a full rewrite, doing a
hand-coded qsort with inline comparison. The same goes the other way. I
can't take an optimized  Fortran program and convert statement for
statement to a C++ program and match the speed.

Since we are talking about algorithmic efficiency, and locality of
reference of data accesses, it shouldn't matter so much about which
computer architecture. The location of the break points in your referenced
document moves a bit to the left or right because of cache sizes, but htey
wouldn't even be there if locality of reference wasn't an issue, since
these break points isn't about code generation, but about data access
patterns of the algorithm.
> 
> 
> 
> > The same goes with just about any
> > programming language. Understanding of language and target 
> > machine might
> > be the difference between being able to solve a problem, or 
> > having to wait
> > a couple of years for faster machines to be released.
> 
> Yes.
> 
> 
> Ioannis
> 
> * Ioannis Vranos
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL: http://run.to/noicys
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future 
> of Java(TM) technology. Join the Java Community 
> Process(SM) (JCP(SM)) program now. 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> 

> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...] 
> Sent: Thursday, October 31, 2002 11:02 AM
> To: Ioannis Vranos
> Cc: 'Dev-C++ Mailing List'
> Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> 
> No, the concept is just about the same for any machine. It is just the
> width of the memory interface, the cache line sizes, the 
> number of cache
> lines etc that are different. A Fortran (or C, Pascal etc) program
> optimized for locality of reference of data accesses will 
> will gain speed
> on just about any computer architecture. It doesn't matter if we talk
> about Von Neuman, SIMD, MIMD or whatever kind of machine. The physical
> properties of memory still applies, i.e. cache is faster than primary
> memory, primary memory is faster than disk.
> The original Fortran algorithms might have been written for a 
> Vax machine,
> but the same optimizations still improves the speed on a Xeon 
> processor.

Yes i agree. However those same types of optimisations can be performed
in C code even if it accesses the array backwards (like Fortran does as
you say).



> You disagree, while still agreeing :-) I am talking about algorithmig
> optimization, not language optimization, and I am talking about the
> problem of just translating an algorithm from one language to another
> while still keeping the speed.

Algorthmically speaking, general algorithms (natively & beautifully
supported by C++ templates) are the same for all types and languages
(for example bubble sort etc). And the cost in Big-Oh notation is the
same. And every compiler can perform optimisations.



> Take a C++ template solution 
> with sort. I
> can't easily convert that code to another language.

Regarding templates yes, you have to create type specialisations.
However for a specific type why not?



> However, 
> I can still
> get the same speed in a Pascal program by doing a full 
> rewrite, doing a
> hand-coded qsort with inline comparison. The same goes the 
> other way. I
> can't take an optimized  Fortran program and convert statement for
> statement to a C++ program and match the speed.


Why? C++ has also close to the metal facilities for hand-coding that
Fortran lacks.


 
> Since we are talking about algorithmic efficiency, and locality of
> reference of data accesses, it shouldn't matter so much about which
> computer architecture. The location of the break points in 
> your referenced
> document moves a bit to the left or right because of cache 
> sizes, but htey
> wouldn't even be there if locality of reference wasn't an issue, since
> these break points isn't about code generation, but about data access
> patterns of the algorithm.


I don't understand clearly. For example,  I assume that GCC's fortran
however-are-called integer types and GCC's C++ equivallents are the same
implementation.


Are you talking for Fortran strings (if they exist!) etc vs C++ high
level constructs? Like C++'s complex STL type? Yes these things are not
easy to be used from inside another language, i am talking only about
built in types.


Ioannis

* Ioannis Vranos
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

Please. Life is too short to religious wars about which language is the
best. I have never ever said that a C or C++ program is slower than a
Fortran program. Only that because of changes in the memory layout of the
different languages, a direct translation of a Fortran program will be 
slower in C, just as a direct translation of a C program will be slower in
Fortran.

The following link is quite good at discussing differences between array
definitions for a couple of languages:
http://www.compaq.com/fortran/docs/vf-html/pg/pgwarray.htm

It isn't possible to just swap index order of a multi-dimensional array,
since large lin-pack code often perform evaluation of subsets of the
array.

The attached source code displays exactly this behaviour. It contains two
test cases, using same algorithm but different memory layout.
- Array access in correct and incorrect order.
- Access speed for optimal and non-uptimal struct.

The speed difference between the two alternatives applies for just about
all programming languages, and just about all all computer architectures
and compilers. The only thing that differs is the amount of speed
difference between good and bad access patterns.

Small memory (< 80MB) on Linux, 1GHz PIII, 512MB
  Processing array out of order  31.3 seconds (50.1 ns/iteration)
  Processing array in order      16.5 seconds (26.5 ns/iteration)
  Improvement factor             1.89
  Non-optimum struct access      24.4 seconds (488 ns/iteration)
  Optimum struct access          12.5 seconds (250 ns/iteration)
  Improvement factor             1.95
  Total user time                46.3 seconds
  Total system time              0.5 seconds

Small memory (< 80MB) on WinXP, 1.2GHz AMD, 512MB
  Processing array out of order 46.3 seconds (74.1 ns/iteration)
  Processing array in order     7.76 seconds (12.4 ns/iteration)
  Improvement factor            5.97
  Non-optimum struct access     11.2 seconds (224 ns/iteration)
  Optimum struct access         10.2 seconds (204 ns/iteration)
  Improvement factor            1.1
  Total user time               68.9 seconds
  Total system time             0.371 seconds

Large memory (< 800MB) on Linux, 1GHz PIII, 512MB
  Processing array out of order  2.83e+03 seconds (28.3e+03 ns/iteration)
  Processing array in order      175 seconds (1.75e+03 ns/iteration)
  Improvement factor             16.2
  Non-optimum struct access      354 seconds (35.4e+03 ns/iteration)
  Optimum struct access          225 seconds (22.5e+03 ns/iteration)
  Improvement factor             1.57
  Total user time                23.7 seconds
  Total system time              646 seconds

Large memory (< 800MB) on WinXP, 1.2GHz AMD, 512MB
  Processing array out of order  1.13e+003 seconds (11.3e+03 ns/iteration)
  Processing array in order      455 seconds (4.55e+03 ns/iteration)
  Improvement factor             2.49
  Non-optimum struct access      120 seconds (12e+03 ns/iteration)
  Optimum struct access          106 seconds (10.6e+03 ns/iteration)
  Improvement factor             1.14
  Total user time                46.1 seconds
  Total system time              29.8 seconds

Linux machine: gcc 2.95.4, -O2
WinXP machine, gcc 2.95.3-6, -O2
The small case was run without memory swapping.
The large case was run with memory swapping.

/Per W

On Thu, 31 Oct 2002, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Per Westermark [mailto:pw...@ia...] 
> > Sent: Thursday, October 31, 2002 11:02 AM
> > To: Ioannis Vranos
> > Cc: 'Dev-C++ Mailing List'
> > Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> > 
> > No, the concept is just about the same for any machine. It is just the
> > width of the memory interface, the cache line sizes, the 
> > number of cache
> > lines etc that are different. A Fortran (or C, Pascal etc) program
> > optimized for locality of reference of data accesses will 
> > will gain speed
> > on just about any computer architecture. It doesn't matter if we talk
> > about Von Neuman, SIMD, MIMD or whatever kind of machine. The physical
> > properties of memory still applies, i.e. cache is faster than primary
> > memory, primary memory is faster than disk.
> > The original Fortran algorithms might have been written for a 
> > Vax machine,
> > but the same optimizations still improves the speed on a Xeon 
> > processor.
> 
> Yes i agree. However those same types of optimisations can be performed
> in C code even if it accesses the array backwards (like Fortran does as
> you say).
> 
> 
> 
> > You disagree, while still agreeing :-) I am talking about algorithmig
> > optimization, not language optimization, and I am talking about the
> > problem of just translating an algorithm from one language to another
> > while still keeping the speed.
> 
> Algorthmically speaking, general algorithms (natively & beautifully
> supported by C++ templates) are the same for all types and languages
> (for example bubble sort etc). And the cost in Big-Oh notation is the
> same. And every compiler can perform optimisations.
> 
> 
> 
> > Take a C++ template solution 
> > with sort. I
> > can't easily convert that code to another language.
> 
> Regarding templates yes, you have to create type specialisations.
> However for a specific type why not?
> 
> 
> 
> > However, 
> > I can still
> > get the same speed in a Pascal program by doing a full 
> > rewrite, doing a
> > hand-coded qsort with inline comparison. The same goes the 
> > other way. I
> > can't take an optimized  Fortran program and convert statement for
> > statement to a C++ program and match the speed.
> 
> 
> Why? C++ has also close to the metal facilities for hand-coding that
> Fortran lacks.

When moving Fortran algorithm to C, you must rewrite all data structures
and array references, since the Fortran algorithm is written specifically
for the Fortran memory model. Yes it can be done, but if it took several
man years to write the Fortran code, don't expect less than several man
months to do it in C/C++.

> 
> 
>  
> > Since we are talking about algorithmic efficiency, and locality of
> > reference of data accesses, it shouldn't matter so much about which
> > computer architecture. The location of the break points in 
> > your referenced
> > document moves a bit to the left or right because of cache 
> > sizes, but htey
> > wouldn't even be there if locality of reference wasn't an issue, since
> > these break points isn't about code generation, but about data access
> > patterns of the algorithm.
> 
> 
> I don't understand clearly. For example,  I assume that GCC's fortran
> however-are-called integer types and GCC's C++ equivallents are the same
> implementation.
An integer for an integer or a double for a double isn't a problem.
Keeping the integers or doubles placed in the correct memory order for a
translated program is hard.
> 
> 
> Are you talking for Fortran strings (if they exist!) etc vs C++ high
> level constructs? Like C++'s complex STL type? Yes these things are not
> easy to be used from inside another language, i am talking only about
> built in types.

Strings normally never consume any time in a real program. 0.1 seconds or
0.2 seconds to open a dialog hardly matters. Fortran programs are normally
performing brutal math, where the run times may be everything from minutes
up to months or more. A factor 2 speed loss for a program requiring 1
month would result in wasted month... To solve such a problem with
another language, you can't just translate the program, since a
translation will not use the optimal features and memory layouts of the
new language.

> 
> 
> Ioannis
> 
> * Ioannis Vranos
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL: http://run.to/noicys
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future 
> of Java(TM) technology. Join the Java Community 
> Process(SM) (JCP(SM)) program now. 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> 

Hi all,
I suggest we are missing the point of the original question.

The original question was about mixed-language programming.
 i.e. a compiler that is capable of compiling a single program, one part
of which is written in C and another oart in FORTRAN. GCC IS a mixed
compiler.

What you seem to  be dealing with below is CONVERTING a program written in
FORTRAN to an equivalent C/C++ program.

 Converting a FORTRAN program is difficult because of the fundamental
differences in the way FARTRAN and C/C++ stores multi-dimentional arrays,
the way parameters are passed to functions, and the way arrays are indexed
(C arrays start with index zero, FORTRAN starts with 1). You have to
re-write a program to convert it or use a program like 'f2C' (which in my
experience works poorly)

A MIXED compiler (if working correctly) is well-aware of the FORTRAN vs
C/C++ differences and should compile object code for mixed programs
correctly. The only thing that one has to learn is how to place, in the
source code, a compiler instruction or 'switch' that tells the gcc
compiler to begin and end the processing FORTRAN source code statements.
 I not sure how to do this with gcc.

 
--- Per Westermark <pw...@ia...> wrote:
> When you have declared
> double a[10][10]
> it is quite important to know in which order the individual values are
> stored in memory, when trying to interface between two languages.
> 
> If your C program does a[x][y] and your Fortran program has do do
> a[z][y] to reach the same entry. No problem when you have all three
> index variables available.
> 
> However, when you take a pointer to a an entry inside the array, the
> operation might be seen as a projection down to an array with fewer
> dimensions. Obviously, if the entry order in memory has been transposed,
> the such a projection will fail misserably when switching languages. The
> 
> sender thought it sent a row, but the receiver got a column.
> 
> When people originally started to push for the C language, the above
> problem gave rise to a related problem. When referencing large memory
> structures, it is important to assure that the code uses locality of
> reference and doesn't jump around everywhere in the data. Large linear
> packages are always implemented so that they process entries in the same
> order that they are stored in memory. When converting such an algorithm
> -
> might be thousands uppon thousands of lines of code - it isn't s easy to
> just try and adjust for row/column switches. The result is that a C
> translation of a Fortran algorithm might loose 10-30% or maybe more of
> the
> speed when the same Fortran algorithm was run.
> The mathematical world decided that C was a slower language :-)
> Nowadays,
> there are a lot of good algorithms originally written for C, so this
> issue
> shouldn't be a problem anymore. But still, there are some billion
> Fortran lines of optimized and very advanced mathematics algorithms out
> there.
> 
> /Per W
> 
> On Wed, 30 Oct 2002, Marc Heiligers wrote:
> 
> > To Ioannis,
> > 
> > Funny thing is I was reading an old Turbo C reference guide I have
> lying
> > around that mentioned linking Turbo C and Turbo Fortran (was it called
> > that?). Borland seemed to very proud of this cross language linking.
> There
> > are some difficulties with function name decoration and what-not that
> you
> > need to be aware of. I can't quite recall what they were, but I'll try
> to
> > remember to take a look this evening.
> > 
> > I'm not sure if the same advice will apply here since it is clearly
> > different compilers, but it may give you an idea. I'd still look on
> the net
> > for info specific to the compilers you want to use.
> > 
> > To Per,
> > Is there anything you don't know anything about? (LOL).
> > 
> > I don't recall if the above mentioned book mentioned any difficulties
> with
> > multi-dimensional arrays. Besides, as far as I'm aware, C uses arrays
> of
> > arrays and not multi-dimensional arrays, so would the trick not be to
> set
> > your arrays up in the same way that Fortran does?
> > 
> > _____________________________
> > Marc Heiligers
> > 
> > 
> > -----Original Message-----
> > From: Per Westermark [mailto:pw...@ia...] 
> > Sent: 30 October 2002 11:40 AM
> > To: Ioannis Vranos
> > Cc: Dev-C++ Mailing List
> > Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> > 
> > 
> > I think there might be acoule of gotchas more to think about.
> > 
> > Doesn't fortran have the reversed row/column order for
> multi-dimensional
> > arrays?
> > 
> > Anyway, I assume that there already exists excellent FAQ documents for
> this
> > kind of problems.
> > 
> > /Per W
> > 
> > On Wed, 30 Oct 2002, Ioannis Vranos wrote:
> > 
> > > > -----Original Message-----
> > > > From: dev...@li...
> > > > [mailto:dev...@li...] On Behalf 
> > > > Of Scott Williams
> > > > Sent: Tuesday, October 29, 2002 10:34 PM
> > > > To: Dev-Cpp-Users@Lists. Sourceforge. Net
> > > > Subject: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > Wondering if anyone has experience with mixed language programming
> 
> > > > and whether it can be done with Dev-Cpp?
> > > > 
> > > > In particular, I'm writing a mathematical simulation in C
> > > > (using Dev-Cpp)
> > > > and would like to make using of some existing numerical 
> > > > routines in Fortran.
> > > > My C knowledge is necessity-based self-taught and so limited; 
> > > > don't know
> > > > anything about Fortran.  Neither do I know much about using
> > > > compilers/linkers/etc in command line mode (which is why I 
> > > > use Dev-Cpp--I
> > > > let it worry about that stuff).
> > > > 
> > > > Still, I know that built-in to the gcc interface is the g77
> > > > compiler so
> > > > there must be a way to compile the fortran source to an 
> > > > object with g77 and
> > > > then link to & call the routines from C.  Could it be as 
> > > > simple as added
> > > > fortran source files to my Dev-Cpp project?  If so, any 
> > > > thoughts on how to
> > > > prototype the Fortran functions & subfunctions to make them 
> > > > accessible to
> > > > the C calling routines?
> > > 
> > > 
> > > Well if you download the whole MINGW distribution it contains a 
> > > Fortran compiler. In theory as i can think of it, if you compile
> your 
> > > fortran source code files to .o files and use C-style declarations
> of 
> > > those functions in your C source code, you should be able to use
> them.
> > > 
> > > 
> > > Ioannis
> > > 
> > > * Ioannis Vranos
> > > * Programming pages: http://www.noicys.freeurl.com
> > > * Alternative URL: http://run.to/noicys
> > > 
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf 
> > > _______________________________________________
> > > Dev-cpp-users mailing list Dev...@li...
> > > TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> > > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> > > 
> > 
> > 
> > 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users


__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

weren't there also issues on some platforms with ordering of arguments to
functions on the stack ... and issues with semantics on how stuff got popped
off the stack when the call returned ?

"PASCAL calling convention" semantics ?

I thought maybe this same set of issues applied to COBOL and FORTRAN libs as
well.

Tony

--- Marc Heiligers <ma...@e-...> wrote:
> To Ioannis,
> 
> Funny thing is I was reading an old Turbo C reference guide I have lying
> around that mentioned linking Turbo C and Turbo Fortran (was it called
> that?). Borland seemed to very proud of this cross language linking. There
> are some difficulties with function name decoration and what-not that you
> need to be aware of. I can't quite recall what they were, but I'll try to
> remember to take a look this evening.
> 
> I'm not sure if the same advice will apply here since it is clearly
> different compilers, but it may give you an idea. I'd still look on the net
> for info specific to the compilers you want to use.
> 
> To Per,
> Is there anything you don't know anything about? (LOL).
> 
> I don't recall if the above mentioned book mentioned any difficulties with
> multi-dimensional arrays. Besides, as far as I'm aware, C uses arrays of
> arrays and not multi-dimensional arrays, so would the trick not be to set
> your arrays up in the same way that Fortran does?
> 
> _____________________________
> Marc Heiligers
> 
> 
> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...] 
> Sent: 30 October 2002 11:40 AM
> To: Ioannis Vranos
> Cc: Dev-C++ Mailing List
> Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> 
> 
> I think there might be acoule of gotchas more to think about.
> 
> Doesn't fortran have the reversed row/column order for multi-dimensional
> arrays?
> 
> Anyway, I assume that there already exists excellent FAQ documents for this
> kind of problems.
> 
> /Per W
> 
> On Wed, 30 Oct 2002, Ioannis Vranos wrote:
> 
> > > -----Original Message-----
> > > From: dev...@li...
> > > [mailto:dev...@li...] On Behalf 
> > > Of Scott Williams
> > > Sent: Tuesday, October 29, 2002 10:34 PM
> > > To: Dev-Cpp-Users@Lists. Sourceforge. Net
> > > Subject: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> > > 
> > > 
> > > Hi,
> > > 
> > > Wondering if anyone has experience with mixed language programming 
> > > and whether it can be done with Dev-Cpp?
> > > 
> > > In particular, I'm writing a mathematical simulation in C
> > > (using Dev-Cpp)
> > > and would like to make using of some existing numerical 
> > > routines in Fortran.
> > > My C knowledge is necessity-based self-taught and so limited; 
> > > don't know
> > > anything about Fortran.  Neither do I know much about using
> > > compilers/linkers/etc in command line mode (which is why I 
> > > use Dev-Cpp--I
> > > let it worry about that stuff).
> > > 
> > > Still, I know that built-in to the gcc interface is the g77
> > > compiler so
> > > there must be a way to compile the fortran source to an 
> > > object with g77 and
> > > then link to & call the routines from C.  Could it be as 
> > > simple as added
> > > fortran source files to my Dev-Cpp project?  If so, any 
> > > thoughts on how to
> > > prototype the Fortran functions & subfunctions to make them 
> > > accessible to
> > > the C calling routines?
> > 
> > 
> > Well if you download the whole MINGW distribution it contains a 
> > Fortran compiler. In theory as i can think of it, if you compile your 
> > fortran source code files to .o files and use C-style declarations of 
> > those functions in your C source code, you should be able to use them.
> > 
> > 
> > Ioannis
> > 
> > * Ioannis Vranos
> > * Programming pages: http://www.noicys.freeurl.com
> > * Alternative URL: http://run.to/noicys
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf 
> > _______________________________________________
> > Dev-cpp-users mailing list Dev...@li...
> > TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> > 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users


=====

Hi everybody

Long time ago (1994)  I worked in a simulation program using Borland C++ 3=
.1 and 
Microsoft Fortran 5.1.

The way I found to work fine was making a windows DLL from the Fortran cod=
e (with 
Microsoft Fortran was possible) and using the DLL in a standard way from m=
y C++ 
code.

I don=B4t know if it=B4s possible with gnu Fortran compiler to make a DLL,=
 but if you can=B4t 
do it, you will have some problems with the function calling beteween C an=
d Fortran, 
the byte ordering, etc.

If you need some other help I will review my program because I don=B4t rem=
ember the 
details

Roger

Send reply to:  	<se...@al...>
From:           	"Scott Williams" <se...@al...>
To:             	"Dev-Cpp-Users@Lists. Sourceforge. Net" <dev-cpp-
us...@li...>
Subject:        	[Dev-C++] Mixed Language Programming w/Dev-Cpp
Date sent:      	Tue, 29 Oct 2002 15:33:56 -0500

> Hi,
> 
> Wondering if anyone has experience with mixed language programming and
> whether it can be done with Dev-Cpp?
> 
> In particular, I'm writing a mathematical simulation in C (using
> Dev-Cpp) and would like to make using of some existing numerical
> routines in Fortran. My C knowledge is necessity-based self-taught and
> so limited; don't know anything about Fortran.  Neither do I know much
> about using compilers/linkers/etc in command line mode (which is why I
> use Dev-Cpp--I let it worry about that stuff).
> 
> Still, I know that built-in to the gcc interface is the g77 compiler
> so there must be a way to compile the fortran source to an object with
> g77 and then link to & call the routines from C.  Could it be as
> simple as added fortran source files to my Dev-Cpp project?  If so,
> any thoughts on how to prototype the Fortran functions & subfunctions
> to make them accessible to the C calling routines?
> 
> BTW, I've tried f2c but have been unable to make that work.  That
> approach is suboptimal anyway because the resulting C code is far less
> efficient than the original Fortran source.
> 
> Perhaps specifics would help.  The fortran code I'm trying to use is a
> single file ode.f  The entry point is the subroutine ode.  Here's how
> the file is laid out:
> 
> // ode.f
> 
>       subroutine ode(f,neqn,y,t,tout,relerr,abserr,iflag,work,iwork)
>       implicit real*8(a-h,o-z)
> 
> c      f -- double precision subroutine f(t,y,yp) to evaluate
> c                derivatives yp(i)=3Ddy(i)/dt
> c      neqn -- number of equations to be integrated (integer*4)
> c      y(*) -- solution vector at t                 (real*8)
> c      t -- independent variable                    (real*8)
> c      tout -- point at which solution is desired   (real*8)
> c      relerr,abserr -- relative and absolute error tolerances for
> local c           error test (real*8).  at each step the code requires
> c             dabs(local error) .le. dabs(y)*relerr + abserr c        
>   for each component of the local error and solution vectors c     
> iflag -- indicates status of integration     (integer*4) c     
> work(*)  (real*8)  -- arrays to hold information internal to c     
> iwork(*) (integer*4)    which is necessary for subsequent calls
> 
> . . . ode calls de:
>       subroutine de(f,neqn,y,t,tout,relerr,abserr,iflag,
>      1  yy,wt,p,yp,ypout,phi,alpha,beta,sig,v,w,g,phase1,psi,x,h,hold,
>      2  start,told,delsgn,ns,nornd,k,kold,isnold)
>       implicit real*8(a-h,o-z)
> 
> . . . de calls step & intrp:
>       subroutine step(x,y,f,neqn,h,eps,wt,start,
>      1  hold,k,kold,crash,phi,p,yp,psi,
>      2  alpha,beta,sig,v,w,g,phase1,ns,nornd)
>       implicit real*8(a-h,o-z)
> 
>       subroutine intrp(x,y,xout,yout,ypout,neqn,kold,phi,psi)
>       implicit real*8(a-h,o-z)
> // end ode.f
> 
> The derivative function f is written in C (and that's where I was
> having probs with the f2c route).
> 
> All help is appreciated (sorry for the long post).
> 
> Scott
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

> -----Original Message-----
> From: Ioannis Vranos [mailto:no...@ho...] 
> Sent: Thursday, October 31, 2002 12:22 AM
> To: 'Dev-C++ Mailing List'
> Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> 
> 
> I disagree. If you mean C algorithms accessing Fortran 
> structures i can agree, only when talking about a dedicated system.
> On non-dedicated systems, and C structures C code can be the 
> same efficient (and sometimes even more).


That is: "For Fortran structures at non-dedicated systems, and C/C++
structures in every type of system, C/C++ code can be the same efficient
(and sometimes even more)".



Ioannis

* Ioannis Vranos
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys

EMA System        email: pw...@ia...
Per Westermark    web: http://iapetus.neab.net
Vargvaegen 174B   phone: +46 8 410 17 198
S-906 42 Umeaa
Sweden


On Thu, 31 Oct 2002, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Ioannis Vranos [mailto:no...@ho...] 
> > Sent: Thursday, October 31, 2002 12:22 AM
> > To: 'Dev-C++ Mailing List'
> > Subject: RE: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> > 
> > 
> > I disagree. If you mean C algorithms accessing Fortran 
> > structures i can agree, only when talking about a dedicated system.
> > On non-dedicated systems, and C structures C code can be the 
> > same efficient (and sometimes even more).
> 
> 
> That is: "For Fortran structures at non-dedicated systems, and C/C++
> structures in every type of system, C/C++ code can be the same efficient
> (and sometimes even more)".
Once more you agree with me. C/C++ code can be as efficient as Fortran,
but only if the code is written to take advantage of the C/C++ language.
Dedicated machines is a side issue. Whatever processor or machine, you
can't simly translate a program from one language to another and get
optimum performance. The require often requires algorithmic changes to fit
the other language.
>
>
> 
> Ioannis
> 
> * Ioannis Vranos
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL: http://run.to/noicys
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future 
> of Java(TM) technology. Join the Java Community 
> Process(SM) (JCP(SM)) program now. 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> 

Well. . . there wasn't any 'code' in my message, just a sketch of the
fortran subroutine prototypes I'm trying to call from c.  If you read my
message, you'll note the source of the 'code' is an existing numerical
package.  The author's standards of variable naming/white space use are of
little concern to me and certainly have nothing to do with the question
posed.

Scott

-----Original Message-----
From: Daniel Glenfield [mailto:sp...@ho...]
Sent: Wednesday, October 30, 2002 3:08 AM
To: se...@al...; dev...@li...
Subject: Re: [Dev-C++] Mixed Language Programming w/Dev-Cpp


That is really ugly code! I'm sorry but please give variables meaningful
names! And use Whitespace!

Sorry, I've been reading Code Complete recently. Excellent book - by Steve
McConnell. A bit dated in places but excellent for ALL programmers (language
and experience independent).


>From: "Scott Williams" Reply-To: To: "Dev-Cpp-Users@Lists. Sourceforge.
>Net" Subject: [Dev-C++] Mixed Language Programming w/Dev-Cpp Date: Tue, 29
>Oct 2002 15:33:56 -0500
>
>Hi,
>
>Wondering if anyone has experience with mixed language programming and
>whether it can be done with Dev-Cpp?
>
>In particular, I'm writing a mathematical simulation in C (using Dev-Cpp)
>and would like to make using of some existing numerical routines in
>Fortran. My C knowledge is necessity-based self-taught and so limited;
>don't know anything about Fortran. Neither do I know much about using
>compilers/linkers/etc in command line mode (which is why I use Dev-Cpp--I
>let it worry about that stuff).
>
>Still, I know that built-in to the gcc interface is the g77 compiler so
>there must be a way to compile the fortran source to an object with g77 and
>then link to & call the routines from C. Could it be as simple as added
>fortran source files to my Dev-Cpp project? If so, any thoughts on how to
>prototype the Fortran functions & subfunctions to make them accessible to
>the C calling routines?
>
>BTW, I've tried f2c but have been unable to make that work. That approach
>is suboptimal anyway because the resulting C code is far less efficient
>than the original Fortran source.
>
>Perhaps specifics would help. The fortran code I'm trying to use is a
>single file ode.f The entry point is the subroutine ode. Here's how the
>file is laid out:
>
>// ode.f
>
>subroutine ode(f,neqn,y,t,tout,relerr,abserr,iflag,work,iwork) implicit
>real*8(a-h,o-z)
>
>c f -- double precision subroutine f(t,y,yp) to evaluate c derivatives
>yp(i)=dy(i)/dt c neqn -- number of equations to be integrated (integer*4) c
>y(*) -- solution vector at t (real*8) c t -- independent variable (real*8)
>c tout -- point at which solution is desired (real*8) c relerr,abserr --
>relative and absolute error tolerances for local c error test (real*8). at
>each step the code requires c dabs(local error) .le. dabs(y)*relerr +
>abserr c for each component of the local error and solution vectors c iflag
>-- indicates status of integration (integer*4) c work(*) (real*8) -- arrays
>to hold information internal to c iwork(*) (integer*4) which is necessary
>for subsequent calls
>
>. . . ode calls de: subroutine de(f,neqn,y,t,tout,relerr,abserr,iflag, 1
>yy,wt,p,yp,ypout,phi,alpha,beta,sig,v,w,g,phase1,psi,x,h,hold, 2
>start,told,delsgn,ns,nornd,k,kold,isnold) implicit real*8(a-h,o-z)
>
>. . . de calls step & intrp: subroutine step(x,y,f,neqn,h,eps,wt,start, 1
>hold,k,kold,crash,phi,p,yp,psi, 2 alpha,beta,sig,v,w,g,phase1,ns,nornd)
>implicit real*8(a-h,o-z)
>
>subroutine intrp(x,y,xout,yout,ypout,neqn,kold,phi,psi) implicit
>real*8(a-h,o-z) // end ode.f
>
>The derivative function f is written in C (and that's where I was having
>probs with the f2c route).
>
>All help is appreciated (sorry for the long post).
>
>Scott
>
>
>
>------------------------------------------------------- This sf.net email
>is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
>_______________________________________________ Dev-cpp-users mailing list
>Dev...@li... TO UNSUBSCRIBE:
>http://www.noicys.cjb.net/devcpp/ub.htm
>https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

_________________________________________________________________
Surf the Web without missing calls! Get MSN Broadband.
http://resourcecenter.msn.com/access/plans/freeactivation.asp

And besides, the function prototypes below are of the normal fortran
quality, since - at least for all old fortran standrds - the language
haven't been known to support very long symbol names. I'm a but rusty, but
isn't it somewhere around 6 characters that's the limit?

There isn't many people tht would call Fortran code beautiful, but that's
the language.

/Per W

On Wed, 30 Oct 2002, Scott Williams wrote:

> Well. . . there wasn't any 'code' in my message, just a sketch of the
> fortran subroutine prototypes I'm trying to call from c.  If you read my
> message, you'll note the source of the 'code' is an existing numerical
> package.  The author's standards of variable naming/white space use are of
> little concern to me and certainly have nothing to do with the question
> posed.
> 
> Scott
> 
> -----Original Message-----
> From: Daniel Glenfield [mailto:sp...@ho...]
> Sent: Wednesday, October 30, 2002 3:08 AM
> To: se...@al...; dev...@li...
> Subject: Re: [Dev-C++] Mixed Language Programming w/Dev-Cpp
> 
> 
> That is really ugly code! I'm sorry but please give variables meaningful
> names! And use Whitespace!
> 
> Sorry, I've been reading Code Complete recently. Excellent book - by Steve
> McConnell. A bit dated in places but excellent for ALL programmers (language
> and experience independent).
> 
> 
> >From: "Scott Williams" Reply-To: To: "Dev-Cpp-Users@Lists. Sourceforge.
> >Net" Subject: [Dev-C++] Mixed Language Programming w/Dev-Cpp Date: Tue, 29
> >Oct 2002 15:33:56 -0500
> >
> >Hi,
> >
> >Wondering if anyone has experience with mixed language programming and
> >whether it can be done with Dev-Cpp?
> >
> >In particular, I'm writing a mathematical simulation in C (using Dev-Cpp)
> >and would like to make using of some existing numerical routines in
> >Fortran. My C knowledge is necessity-based self-taught and so limited;
> >don't know anything about Fortran. Neither do I know much about using
> >compilers/linkers/etc in command line mode (which is why I use Dev-Cpp--I
> >let it worry about that stuff).
> >
> >Still, I know that built-in to the gcc interface is the g77 compiler so
> >there must be a way to compile the fortran source to an object with g77 and
> >then link to & call the routines from C. Could it be as simple as added
> >fortran source files to my Dev-Cpp project? If so, any thoughts on how to
> >prototype the Fortran functions & subfunctions to make them accessible to
> >the C calling routines?
> >
> >BTW, I've tried f2c but have been unable to make that work. That approach
> >is suboptimal anyway because the resulting C code is far less efficient
> >than the original Fortran source.
> >
> >Perhaps specifics would help. The fortran code I'm trying to use is a
> >single file ode.f The entry point is the subroutine ode. Here's how the
> >file is laid out:
> >
> >// ode.f
> >
> >subroutine ode(f,neqn,y,t,tout,relerr,abserr,iflag,work,iwork) implicit
> >real*8(a-h,o-z)
> >
> >c f -- double precision subroutine f(t,y,yp) to evaluate c derivatives
> >yp(i)=dy(i)/dt c neqn -- number of equations to be integrated (integer*4) c
> >y(*) -- solution vector at t (real*8) c t -- independent variable (real*8)
> >c tout -- point at which solution is desired (real*8) c relerr,abserr --
> >relative and absolute error tolerances for local c error test (real*8). at
> >each step the code requires c dabs(local error) .le. dabs(y)*relerr +
> >abserr c for each component of the local error and solution vectors c iflag
> >-- indicates status of integration (integer*4) c work(*) (real*8) -- arrays
> >to hold information internal to c iwork(*) (integer*4) which is necessary
> >for subsequent calls
> >
> >. . . ode calls de: subroutine de(f,neqn,y,t,tout,relerr,abserr,iflag, 1
> >yy,wt,p,yp,ypout,phi,alpha,beta,sig,v,w,g,phase1,psi,x,h,hold, 2
> >start,told,delsgn,ns,nornd,k,kold,isnold) implicit real*8(a-h,o-z)
> >
> >. . . de calls step & intrp: subroutine step(x,y,f,neqn,h,eps,wt,start, 1
> >hold,k,kold,crash,phi,p,yp,psi, 2 alpha,beta,sig,v,w,g,phase1,ns,nornd)
> >implicit real*8(a-h,o-z)
> >
> >subroutine intrp(x,y,xout,yout,ypout,neqn,kold,phi,psi) implicit
> >real*8(a-h,o-z) // end ode.f
> >
> >The derivative function f is written in C (and that's where I was having
> >probs with the f2c route).
> >
> >All help is appreciated (sorry for the long post).
> >
> >Scott
> >
> >
> >
> >------------------------------------------------------- This sf.net email
> >is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
> >_______________________________________________ Dev-cpp-users mailing list
> >Dev...@li... TO UNSUBSCRIBE:
> >http://www.noicys.cjb.net/devcpp/ub.htm
> >https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> 
> _________________________________________________________________
> Surf the Web without missing calls! Get MSN Broadband.
> http://resourcecenter.msn.com/access/plans/freeactivation.asp
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> 

Thanks to everyone who responded to my question about mixed language
programming (particularly to Horst for the references).  Persistence has
paid off!  For the record . .

Turns out Dev-Cpp works quite nicely with mixing Fortran and C.  At compile,
gcc implicitly invokes g77 for any Fortran source files and the resulting
object files are linked without a problem; So including Fortran source files
in a Dev-Cpp project appears to be seamless.

Actually using the Fortran subroutines takes a little more work.  First, the
Mingw libraries libg2c and libm must be linked, i.e., Project Options :
Linker Options : -lg2c -lm (in that order!).  Next, the Mingw header file
g2c.h must be included in any C source file that will call C.

libg2c and g2c.h are gcc's versions of f2c.  However, as near as I can tell,
this isn't an f2c operation (translating Fortran to C then compiling from C
source), rather, the Fortran source files are compiled with g77 and so
retain the native efficiencies of their Fortran implementation; the library
and header files merely provide the interface for C.

Prototyping the Fortran subroutines is a little tricky but I found a use for
f2c after all!  When used with the -P switch, it produces a file with
subroutine prototypes to be used in C.

After that, it took some trial & error to figure out how to correctly
declare & pass the variables from C.  Biggest problem I had was with the C
function passed to and called from the Fortran routines (using their own
internally declared variables).  Essentially I had to create a shell of the
C routine to be called by the Fortran routines where I adjusted array
indexing and then call the real C routine.

Hope that is helpful anyone else interested in the issue.  Thanks again for
the feedback.

Scott