Subject: (Fwd) Multi-Language Programming on SGI

From: "Iraj Daizadeh" <[email-masked]>
Date: Thu, 31 Jul 1997 09:46:31 -0700

Hello.

There was a problem sending the message below to be posted on the CCl.  Would
you mind ensuring this.

Thanks.

Iraj.
--------------------------------------------------------------------------------
Hello.

The conversation on the CCL concerning OO led very nicely into a discussion of
mixing programming languages (for an incomplete summary, please see below).
 This methodology should merit considerable thought by the computational
chemistry society since it combines aspects in computational efficiency and
modern coding practices (viz., raw speed, dynamic memory allocation, and object
oriented design) with that of using old routines that are still very
functional. How to implement these ideas in a pragmatic manner, however, has
not been well-documented within these discussions bombarding our email
terminals.

We have been using multi-language programming ever since I began my
computational career here at UC Davis under the watchful eye of Prof.
Stuchebrukhov (circa. 3 academic years ago).  Thus, I thought it might be
useful to describe in detail a (probably) complicated procedure (for the
novice) which would allow the generation of an executable from a C code calling
a Fortran routine.  Generalization of the ideas presented (briefly) below
should suffice to enable any programmer using an SGI running IRIX 5.2 or above
(up to 6.2) (at least what we have used) to be able to create an executable
from C/Fortran (Fortran/C, Fortran/Pascal, etc.. (<-in a similar manner->) )
code.

 An outline of this procedure follows:

	(The methodology was suggested to us when we first started in this
direction ( see Fortran/C Interface in the Fortran 77 Programmer's Guide on the
insight pages by SGI (5.2) )...

1.  Here is an example C code:

#include <stdio.h>

extern double add_(double *,double *);

void main()
{
        double x,y;

        x=y=10.0;

        printf("%f  %f  %f\n", x, y, add_(&x,&y));

} /* end main */

This very easy program takes two doubles x,y and adds their assigned values.
 There exist a couple of items within the C code that are of particular
interest to us.  First, we have used an external function called add.  Add is
the fortran function (returns a value).  The fortran call must by followed by
an UNDERSCORE. Next notice that we have parameterized this function with
pointers and sent the  addresses of our variables to the fortran routine (This
is essential since fortran uses implicitly pointers (no more on this)).  That
is all there is to it.

2.  Next follows the fortran function:

      function add(x,y)
      double precision add,x,y
      add = x+y
      return
      end

Notice there is no underscore after the add function.  This is an intact code
without any changes (YEA!).

3.  Compile as follows:
	cc -c main.c   # main.c is the file that contains the c code
	f77 -c add.f   # add.f is the file that contains the fortran code
	cc -o add main.o add.o   # now link them with the compiler that
contains main

You are done!!!

A couple of notes:
	a.  Remember: c is case-sensitive, fortran is not.
	       What c does is convert the fortran statement to lowercase:
		  [function statement(arg-list) or subroutine name(arg-list)]
			Thus, the following are equivalent to the c call above:
				function ADD()		subroutine ADD()
				function Add()          subroutine Add()
				function add()   or     subroutine add
				function AdD()		subroutine AdD()
					      ...etc...

	b. Watch your datatype!
	c. For a fortran routine calling a C function a similar procedure
works.
		But keep in mind whichever code contains
			main
		should be the compiler that links all the object codes;

		e.g. if fortran code contained main
			use:	cc -c add.c
				f77 -c main.f
				f77 -o add add.o main.o
	d. There are some minor details for sending arrays and structures but
trial and error will allow you to figure this out on your own.
	e. remember it may be necessary to use the -lftn extension when there
exist some unresolved errors.

I would appreciate it if there were others in the field with this type of
programming experience would kindly send me their explicit methodologies for
muli-language implementations on other platforms.  We are in the process of
re-evaluating our computational hardware and are considering acquiring a Dec
\alpha or HP.  I will summarize all of them as is customary.

Any comments, concerns or questions, please do not hesitate to email.  If I am
too busy, I will say so.

Iraj.

--

Iraj Daizadeh
Department of Chemistry
University of California
One Shields Ave.
Davis, CA  95616-5295
Phone:  916.754.8695
Fax:    916.752.8995
email:  [email-masked]

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Alex Turner <[email-masked]) writes:

There seems to be one points that no-one has covered, especially when we
say FORTRAN has run its coarse.  If I am to spend a long time writing a
piece of code to perform a very complex task - I need to be 100% sure
that the code will be in a lagnuage that can be used in the future.  There
is only one language that can really offer that - FORTRAN.

---

Considering the amount of C code written in the last, oh, 5 years
(both commercial and non-commercial), I think C will be with us
for the forseeable future as well.  I suspect in the computational
chemistry arena, there has been (far?) more C code written over this
time than Fortran...

This doesn't mean that there are more lines of C out there in use
than Fortran, merely that times actually have changed a little, or
maybe more than a little.  Having written a fair amount of code in
both languages, I would hate to write anything BUT numerically-
intensive code in Fortran anymore.  Trying to do I/O, or interact
with the environment, etc. seems so much easier in C...

Also, while I cannot say for certain, there seems to be some platforms
for which a Fortran compiler is either unavailable or a relative newcommer.
C, however, seems available wherever one cares to look (although my
experience with supercomputers is not up to date).  While Fortran, on
the strength of some pre-preprocessors, might still hold a lead in
generating "fast" code, sections of "C-tran" seem to optimize as well
if some thought is given to "helping" the compiler.

Something called "Fortran" will be around for a while.  So will something
called "C"...  Neither language is probably the best-choice when
developer effort is the concern, but both seem rather good for heavy
lifting.  It's just that given the annoyances of multi-language software,
there has to be SIGNIFICANT performance issues to get me to mix in
Fortran anymore.

Joe Leonard
[email-masked]

P.S. FWIW, I live in the workstation environment, usually working on
code which is either heavy-lifting or personal/throwaway...

---
Administrivia: This message is automatically appended by the mail exploder:
[email-masked]: Everybody | [email-masked]: Coordinator
[email-masked]: HELP CHEMISTRY or HELP SEARCH | Gopher: www.ccl.net 73
Anon. ftp: www.ccl.net   | [email-masked] -- archive search
             Web: http://www.ccl.net/chemistry.html

----------------------------------------------------------------------------------------------------------------------------------------------------------------
It idea of mixed language programming is to use languages most
appropriate for the task at hand, not just for speed, but for ease of
implementation.  Such decisions are usually fairly coarse-grained.
For example, you might prefer to use C code to implement operations on
a fairly complex data structure, while a computationally-intensive
section might better be written in Fortran.

If the code is well encapsulated, there should be little problem
(conceptually) and no performance degredation from hooking up code
written in multiple languages.  Of course that's different from making
a poor choice of programming language to implement a given component.

It is true that interlanguage programming is not standardized (yet),
but as a practical matter, on a given platform you can expect that
most languages (from the same vendor at least) will follow a similar
underlying structure and _will_ be able to interface.  It is also true
that relatively little documentation of these interfaces is
available, but in most cases it is really fairly straightforward.

Some things, like mixed Fortran77 and C, are now so common that there
is a community of people out there who understand pretty well how to
do this and even some packages/templates to help you do it in a
platform-independent way.  If you seek out such people, you can
probably find them without too much trouble.

I can't recall a case where I had to know more about the
"processor-dependent nitty-gritty of numerical computation" to do
mixed-language programming than I needed to do a good job of
scientific programming in one language -- the interfaces are rarely so
fine-grained as that.

> Ultimately, most folks are more concerned with optimizing their time
> use than the computer's :-) .

In my opinion, this is the reason _to_ use mixed language
programming.  If I wanted to write a robust input parser for a large
chemistry software package, I'm sure I could write it in Fortran, but
it would take a lot of work.  These days, there are tools to do this
quite easily in C (lex, yacc, etc.).  For many people, the time
required to write the parser in C _and_ the time to sort out the
interface to Fortran would be shorter than writing it in scratch from
Fortran.  And the C-Fortran interfacing skills learned during the
exercise could easily be reused for other projects.
--
David E. Bernholdt                      | Email:  [email-masked]
Northeast Parallel Architectures Center | Phone:  +1 315 443 3857
111 College Place, Syracuse University  | Fax:    +1 315 443 1973
Syracuse, NY 13244-4100                 | URL:    http://www.npac.syr.edu
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>   Some things, like mixed Fortran77 and C, are now so common that there
>   is a community of people out there who understand pretty well how to
>
>Are you offering your services? :-) Perhaps it's not as bad as it
>looks from my end, but if I had to rely on the kindness of unpaid
 [...snip ...]

 Hmm.  How about mixed tcl/C ?  The tcl interpreter is done in C,
 so rebuilding the interpreter is not mixed-language.  But the
 result would be -- use tcl (slow as molasses, but lots of
 high level constructs like hashes, regular expressions, flow
 control) for the putting-together-the-tools part, and let
 C (or fortran) do the heavy lifting.

 Someone could provide a toolkit of tcl commands written in C,
 and anyone could put the tools together in new ways using
 a highlevel scripting language.  I think perl and python
 would also work as scripting languages here.  This is
 not just object-oriented (for the programmer) but also
 somewhat component-oriented (for the application builder or
 end user).

   bobg
----------------------------------------------------------------------------------------------------------------------------------------------------------------

David E. Bernholdt:

> It idea of mixed language programming is to use languages most
> appropriate for the task at hand, not just for speed, but for ease of
> implementation.  Such decisions are usually fairly coarse-grained.

Exactly!

> > Ultimately, most folks are more concerned with optimizing their time
> > use than the computer's :-) .
>
> In my opinion, this is the reason _to_ use mixed language
> programming.  If I wanted to write a robust input parser for a large

I couldn't agree more!

> One can DESIGN software based on these principles (OOD) regardless of
> what language the software is to be implemented in.

Right. But implementing an OO design in a non-OO language requires
a lot of experience and discipline - to be expected of a professional
programmer, but not of a programming scientist.

Of course the more basic problem is that scientists tend to skip
the design phase altogether. Which is why big projects ought to
be started in collaboration with software engineering experts.

> I disagree with the person who proposed C++ is "the" langauge for
> future work because it is an OOL.  There are a lot of other
> considerations that (should) factor into the decision of which
> language to use.  However I think that ALL projects should consider
> object-oriented DESIGN regardless of implementation language.

Again I agree completely.

--------------------------------------------------
Lestaw K. Bieniasz:

> If you need a program for individual purpose, use Fortran if you like it.

Of course. However, don't do one of the following:

1) Force your students and postdocs to use Fortran even if they know
   and prefer something else.

2) Teach your students nothing but Fortran.

Unfortunately, both are standard practice today.

--------------------------------------------------

OK, that's it, sorry for the long post, and back to work...
--
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: [email-masked]
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

--
Iraj Daizadeh
Department of Chemistry
University of California
One Shields Ave.
Davis, CA  95616-5295
Phone:  916.754.8695
Fax:    916.752.8995
email:  [email-masked]