Fortran - basic question

Author

basic question

mats_trash@hotmail.com

2005-05-10, 8:58 am

I'd just like some quick advice:

I'm starting to learn Fortran and I'd like to know how one goes about
designing a program such that once compiled it is possible to later add
further functions or modules and expose them to the original program
without having to recompile the whole lot. i.e. is it possible to use
function pointers passed as command line arguments to tell a program to
use a function in a module that was not compiled at the same time?

If this is not the case what is/are the general methods by which
programs are made 'updateable'/'upgradeable'. My intention was to
write some signal processing software and code a central program that
would allow me to add more functions as and when I find the time.

I suppose this is a generic issue in programming and as such a sketch
of any suitable scheme(s) would be useful (i.e. no one has to write me
the exact code!)

glen herrmannsfeldt

2005-05-10, 8:58 am

mats_trash@hotmail.com wrote:

> I'm starting to learn Fortran and I'd like to know how one goes about
> designing a program such that once compiled it is possible to later add
> further functions or modules and expose them to the original program
> without having to recompile the whole lot. i.e. is it possible to use
> function pointers passed as command line arguments to tell a program to
> use a function in a module that was not compiled at the same time?

There are some system dependent tricks, often using dynamic linking,
for adding functions to a running program. I have seen them used in
Mathematica, and in Java.

> If this is not the case what is/are the general methods by which
> programs are made 'updateable'/'upgradeable'. My intention was to
> write some signal processing software and code a central program that
> would allow me to add more functions as and when I find the time.

> I suppose this is a generic issue in programming and as such a sketch
> of any suitable scheme(s) would be useful (i.e. no one has to write me
> the exact code!)

Other than such tricks, it is not unusual for the program itself to
compile an expression to some internal form and interpret that form.
That is the way programs called interpreters work, and is not unusual
for other types of programs. As an example, Mathematica is a program
that accepts programs written in its own language and executes them.
A function can be supplied, and, for example, Mathematica will generate
a graph of that function. The process is slower than compiling to
native machine code by a factor of three or more, but otherwise works
well.

-- glen

meek@skyway.usask.ca

2005-05-10, 3:59 pm

In a previous article, mats_trash@hotmail.com wrote:
>I'd just like some quick advice:
>
>I'm starting to learn Fortran and I'd like to know how one goes about
>designing a program such that once compiled it is possible to later add
>further functions or modules and expose them to the original program
>without having to recompile the whole lot. i.e. is it possible to use
>function pointers passed as command line arguments to tell a program to
>use a function in a module that was not compiled at the same time?
>
The usual way I do it is use an IDE (WATCOM specifically)
- Integrated Development Environment - just add files and stir :)
or you could use a batch file ... whatever , to link
previously compiled sub-programs (.obj ) with a main that
you will modify and recompile to add new features.

.. I'm sure that most other compilers/languages have
equivalent capabilities; nothing to do specifically with Fortran.
Chris

Janne Blomqvist

2005-05-10, 8:58 pm

mats_trash@hotmail.com wrote:
> I'd just like some quick advice:
>
> I'm starting to learn Fortran and I'd like to know how one goes about
> designing a program such that once compiled it is possible to later add
> further functions or modules and expose them to the original program
> without having to recompile the whole lot. i.e. is it possible to use
> function pointers passed as command line arguments to tell a program to
> use a function in a module that was not compiled at the same time?
>
> If this is not the case what is/are the general methods by which
> programs are made 'updateable'/'upgradeable'. My intention was to
> write some signal processing software and code a central program that
> would allow me to add more functions as and when I find the time.
>
> I suppose this is a generic issue in programming and as such a sketch
> of any suitable scheme(s) would be useful (i.e. no one has to write me
> the exact code!)

As Glen H. said, more dynamic languages where the distinction between
code and data is less strict than in say Fortran or C, dynamically
loadable code is in general pretty easy.

No such dynamic loading thing exists for Fortran (or C for that
matter) as such, but the operating system usually provides some
dynamic loading functionality for C code which you probably can use
from Fortran too. On Unix/Linux you can use the
dlopen/dlsym/dlblahblah functions for dynamically loading library
code; I guess Windows has something similar. I would however
discourage you from using it. Apart from being non-portable, it's also
somewhat fragile (no compile time argument checking) and IMHO slightly
cumbersome to use.

For what you apparently are trying to do, I'd recommend that you write
your "extra functionality" code just like any other code, and use a
config file to determine which parts to run when the program is
executed. That approach is relatively simple, portable and robust. If
you're lazy and use Fortran 90+, you can even use the namelist
functionality to parse your config file instead of writing your own
parser.

--
Janne Blomqvist

Gordon Sande

2005-05-10, 8:58 pm

Janne Blomqvist wrote:
> mats_trash@hotmail.com wrote:
>
>
>
> As Glen H. said, more dynamic languages where the distinction between
> code and data is less strict than in say Fortran or C, dynamically
> loadable code is in general pretty easy.
>
> No such dynamic loading thing exists for Fortran (or C for that
> matter) as such, but the operating system usually provides some
> dynamic loading functionality for C code which you probably can use
> from Fortran too. On Unix/Linux you can use the
> dlopen/dlsym/dlblahblah functions for dynamically loading library
> code; I guess Windows has something similar. I would however
> discourage you from using it. Apart from being non-portable, it's also
> somewhat fragile (no compile time argument checking) and IMHO slightly
> cumbersome to use.
>
> For what you apparently are trying to do, I'd recommend that you write
> your "extra functionality" code just like any other code, and use a
> config file to determine which parts to run when the program is
> executed. That approach is relatively simple, portable and robust. If
> you're lazy and use Fortran 90+, you can even use the namelist
> functionality to parse your config file instead of writing your own
> parser.
>

For someone starting perhaps it is better to go back to some very
simple facts.

For small programs compilation is not expensive. I routinely recompile
50,000 line programs in less than a minute. At a couple thousand lines
the response is much faster than I can type. The technical schemes to
avoid recompiling are not for the first w

of programming. Given the
cost of compilation they are not cost effective in many realistic
situations. (If you ask the wrong question by accident you will be
snowed under by many complicated answers to those who are willing
to display their technical ability.)

Adding a new function to an existing program usually consists of writing
the new code as a SUBROUTINE or FUNCTION, this time function is a
Fortran buzzword, and adding a small amount of code to call the new
function. After that it can be made a bit more complicated by calling
it under some sort of logic control.

If you get to where recompilation becomes a noticeable bottleneck then
you should take the time to understand configuration control and
similar software engineering issues. You may also want to look at issues
of how you can combine things dynamically. (The regulars here operate
at this level which is why you get the answers you did.)

If you are adding things to somebody else's huge system then you will
have to learn how to fight these battles sooner rather than later.
But they may provide you with canned procedures to help get past the
hurdles. Often you will be able to follow the recipe even if you
could not develop it yourself. At least until something goes wrong. :-(

When things are small upgradeable mostly just means keeping sensible
backup copies as you add various new features. When it is not longer
small then read the above.

glen herrmannsfeldt

2005-05-10, 8:58 pm

Gordon Sande wrote:

(snip)

(big snip)[color=darkred]

(another big snip)
[color=darkred]
> For someone starting perhaps it is better to go back to some very
> simple facts.

> For small programs compilation is not expensive. I routinely recompile
> 50,000 line programs in less than a minute. At a couple thousand lines
> the response is much faster than I can type. The technical schemes to
> avoid recompiling are not for the first w

of programming. Given the
> cost of compilation they are not cost effective in many realistic
> situations. (If you ask the wrong question by accident you will be
> snowed under by many complicated answers to those who are willing
> to display their technical ability.)

(snip)

I was unsure what the OP wanted, and I am still not sure.

In signal processing, one might want to graph user supplied functions,
for example, or apply a user supplied filter to some data. For those
types of problems it is much nicer not to have to modify the program
source and recompile it. This is what I believe the OP wanted, though
I wasn't so sure about it.

For normal program evolution, recompiling would seem to be the
usual solution. Separate compilation and linking was meant to
speed up the process, but for most size programs and processors
recompiling the whole program is usually fast enough.

-- glen

Richard E Maine

2005-05-10, 8:58 pm

In article <aW8ge.35934$0X6.21511@edtnps90>,
Gordon Sande <g.sande@worldnet.att.net> wrote:

> For someone starting perhaps it is better to go back to some very
> simple facts....

Thank you for replying in this vein. Saves me the trouble, :-) as I was
beginning to wonder whether someone was going to provide the simple
advice instead of just answering the literal question asked.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

mats_trash@hotmail.com

2005-05-11, 4:00 am

> In signal processing, one might want to graph user supplied
functions,
> for example, or apply a user supplied filter to some data. For those
> types of problems it is much nicer not to have to modify the program
> source and recompile it. This is what I believe the OP wanted,
though
> I wasn't so sure about it.

This is exactly what I had envisaged, writing a core program that would
use a standard interface for applying filters and other processing to
matrices which would allow me to simply write new algorithms and plug
them in as required.

I take on board that recompiling is not really an issue for most
programs - that's not really what bugs me. It simply seems to me
inelegant that to add and utilise new filters or something I should
have to create a funtion with a long SELECT CASE control with each of
my filters as a CASE to allocate a function pointer to the desired
filter. Then each time I add a filter I would need to alter the SELECT
CASE in the core/main program. It's not that is is any great problem I
just wonder if there isn't a better way of doing it.

The other reason I can't believe there is another way is that I'm sure
this issue must have cropped up in other programs - particularly where
people might want to share different 'plug-ins' to a core program.
While you might be happy to try a third-party plug-in on the basis that
it might only screw up your data or cause the program to crash once if
it is badly coded, to have to accept someone's recoding of the 'core'
program to utilise that plug-in lays you open to having the whole
program become permanently unusuable (or worse) if you yourself aren't
adept at programming and able to correct any error.

I accept that I may have got this completely upside down and can't see
the obvious solution - in which case I'd be grateful if someone could
point it out!

Cheers

Charles LaCour

2005-05-27, 4:01 am

mats_trash@hotmail.com wrote:
>
> functions,
>
>
> though
>
>
>
> This is exactly what I had envisaged, writing a core program that would
> use a standard interface for applying filters and other processing to
> matrices which would allow me to simply write new algorithms and plug
> them in as required.
>
> I take on board that recompiling is not really an issue for most
> programs - that's not really what bugs me. It simply seems to me
> inelegant that to add and utilise new filters or something I should
> have to create a funtion with a long SELECT CASE control with each of
> my filters as a CASE to allocate a function pointer to the desired
> filter. Then each time I add a filter I would need to alter the SELECT
> CASE in the core/main program. It's not that is is any great problem I
> just wonder if there isn't a better way of doing it.
>
I don't know which operating system you are using, but it seems to me
that the best way to achieve what you want is to is to "pipe" or
redirect your output to the program that you want to process your data
or to store the output of the main program to a file and then use your
filter program or graphing program to read the data from the file.

Unix-like systems and Windows will allow you to chain the output from
one program to another doing something like this:

dspprog | plotdata

or if you have you input data stored in text file, you can redirect your
input from standard input and pipe it to another program this way.

dspprog < inputdata.txt | dspfilter > outputdata.txt
dspprog < inputdata.txt | dspfilter | plotdata

The first example reads your input data from a file instead of standard
input. That data is processed and the output is directed toward the
filter progam. The filter program does its job and sends the output to
outputdata.txt instead of to the screen or standard output. The
downside to this approach is that you have to maintain a high degree of
consistency on how you read and write your data to and from standard
input and output. Also, since the number of pipes is only limited by
your operating system, you could easily get tired of typing.

e.g.
dspprog < inputdata.txt | filter1 | filter2 | filter3 | filter4

> The other reason I can't believe there is another way is that I'm sure
> this issue must have cropped up in other programs - particularly where
> people might want to share different 'plug-ins' to a core program.
> While you might be happy to try a third-party plug-in on the basis that
> it might only screw up your data or cause the program to crash once if
> it is badly coded, to have to accept someone's recoding of the 'core'
> program to utilise that plug-in lays you open to having the whole
> program become permanently unusuable (or worse) if you yourself aren't
> adept at programming and able to correct any error.
>
> I accept that I may have got this completely upside down and can't see
> the obvious solution - in which case I'd be grateful if someone could
> point it out!
>
> Cheers
>

Sponsored Links