On Monday 25 July 2005 04:35 pm, David A. Case wrote:
> On Thu, Jul 21, 2005, M. L. Dodson wrote:
> >
> > I need to use some fortran functions in a (fairly large) project
> > written in nab. There is a lot of trig, and due to the diffences
> > in angle representation (degrees in nab, radians in fortran), I
> > decided to convert the fortran to nab. My problem is that the
> > fortran uses named common blocks to pass around global variables.
> > I have not been able to come up with a way to implement an
> > equivalent using nab. Has anyone done something similar to this
> > or does anyone have a suggestion? Thanks,
> >
> Hi Bud:
>
> Strange: I've just been doing a similar thing: removing all fortran
> routines from the main NAB code. But this involved converting to C,
> not to NAB, and you might think about that. C has structures, which can
> act like named common blocks in Fortran.
>
> If you do want to go with nab, variables that are placed outside any routines,
> they will be written as static variables, and be available to any routines
> inside that file. For example:
>
>
> int a,b;
>
> int sub1(){
>
> a = 1;
> b = 3;
> printf( %d %d\n", a,b );
> }
>
> int sub2(){
>
> x = a;
> y = b;
> printf( %d %d\n", x,y );
> }
>
>
> Look at the C code the above creates. Basically, a, b are "global" variables
> that are available to any subroutine in the file. Note that "a" and "b" may
> not be next to each other in memory, as would be the case for common blocks.
>
> ....hope this helps....dac
Thanks for answering! Actually, I was aware of the way nab treats
a,b in your example, as I did that experiment several years ago.
In fact, I thought about solving the problem I described with some
make "fu" involving a sed script to convert the emitted static
declarations for, e.g., a and b, to the C extern storage class
specifier. A few minutes reflection cured me of that disease (too
cute by half, impossible to maintain, and a few thousand other
reasons).
So I rethought my design to keep nab only in the mainline and in
the modules that need to handle molecular mechanics; I kept the
fortran in other words. I have an aversion to f2c for some silly
reason and try to keep its use to a minimum, but I WILL use it: I
figured out a funky way to do the communication back and forth
using f2c on a fortran module containing all the common block
definitions and not much else, then customizing the resulting C
code. In its latest incarnation, I believe it is reasonably
maintainable and fast, but not the most transparent code I have
ever written.
The radian/degree issue I handled by just using a state variable
reflecting the current representation in the arrays containing
angles. Then I became afraid that the fortran would link to the
nab definitions of the trig functions, but an experiment
demonstrated the compiler/linker combo (gcc/g77 version 3.4.2) can
handle this without confusion (because the fortran trig functions
are intrinsics?).
Thanks again!
Bud
PS, I have a suggestion for an extension of the nab language which
would make this kind of programming issue more transparent and, I
believe, make code written in nab more modular and make using
problematic C library functions more straightforward. Think
getopt(3). I will email you separately about it when I get some
time.
PPS, I apologize again to the list for the off topic discussion,
but if it results in one or two nab converts among you, I won't be
disappointed!
--
M. L. Dodson bdodson.scms.utmb.edu
409-772-2178 FAX: 409-747-8608
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Tue Jul 26 2005 - 15:53:01 PDT
