From: robin on
"robin" <robin_v(a)bigpond.com> wrote in message news:O9Zkn.11769$pv.9113(a)news-server.bigpond.net.au...
| "monir" <monirg(a)mondenet.com> wrote in message
news:d2e296f5-92c8-4f23-b6cd-6b574d6d254c(a)f8g2000yqn.googlegroups.com...

| >d) if X, m, n are dummy arguments, then one can't use Data statement,

Correct.

| >but maybe:
| >...Real :: X(m,n) = 0.0
|
| That's right.

Correction: that's wrong.
You must use a separate assignment statement.

In other words,

REAL :: X(m,n)
X = 0

is OK.


From: JB on
On 2010-03-08, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:
> Ron Shepard <ron-shepard(a)nospam.comcast.net> wrote:
> (snip)
>
>> Most compilers put the initialized values in static storage in the
>> executable file. For a large array this means that the exe file is
>> large, and it will take a long time to load from disk. The
>> executable statement will execute many thousands of times faster
>> than the equivalent disk i/o, and without the static storage the exe
>> file will be smaller and will load faster.
>
> It seems that many now don't put arrays of zeros into the file,
> but anything else they do. I have gfortran on Scientific Linux 5.3.
>
> integer x(1000000)
> data x/1000000*0/
> print *,x(12345)
> end
>
> Results in a small object file and small executable file.
> As far as I can tell, the system initializes static storage
> to zero, and the compiler knows that.

Yes, in the object format there is a special segment for zeroed
variables called bss where each individual element is not repeated

http://en.wikipedia.org/wiki/.bss

Presumably this is a C-ism as C requires static variables to be zero
initialized; the designers of the object format evidently thought that
large static arrays were common enough in C programs that it was worth
special-casing them and thus keeping binary size smaller.

gfortran piggybacks on this and initializes uninitialized
saved/common/data/?/ variables to zero. This is, of course, merely an
implementation trick and programs relying on this behavior are
non-standard and might cause WWIII.

> integer x(1000000)
> data x(12346)/1/
> print *,x(12345)
> end
>
> In this case, the object file isn't big, as it can initialize many
> zeros in one line, but the executable (a.out) file is big.
> Unlike the standard requires, the other array elements are zero.

Hmm, interesting. I haven't investigated, but presumably setting one
element then forces the entire array to go into the .data section
rather than .bss, thus causing the large executable size. I don't know
why the object file isn't similarly large. Anyways, you can use the
"size" command to check the size of the text (code), data and bss
sections of a file.

> On the other hand, many systems use the executable file as backing
> store for the virtual memory, with copy on write status. If it
> isn't modified, the data is fetched from the file itself, instead
> of from the swap file. On systems that do this, a running program
> will crash if you recompile it (and write over the executable file)
> while it is running.

This applies to the (typically read-only) text section as well. The
file is usually memory mapped, and if the OS is under memory pressure
these pages can simply be discarded rather than swapped out, as the OS
can simply reread them from the file when needed.

When upgrading programs/libraries on POSIX this situation is usually
avoided by not overwriting the existing file, but rather by writing
the new file to a temporary name, then renaming it on top of the
correct name. Due to the delete on last close semantics of POSIX
filesystems, and the fact that rename() is atomic within a filesystem,
this ensures that existing running programs won't be disturbed.

--
JB
From: glen herrmannsfeldt on
JB <foo(a)bar.invalid> wrote:
(snip, I wrote)

>> On the other hand, many systems use the executable file as backing
>> store for the virtual memory, with copy on write status. If it
>> isn't modified, the data is fetched from the file itself, instead
>> of from the swap file. On systems that do this, a running program
>> will crash if you recompile it (and write over the executable file)
>> while it is running.

> This applies to the (typically read-only) text section as well. The
> file is usually memory mapped, and if the OS is under memory pressure
> these pages can simply be discarded rather than swapped out, as the OS
> can simply reread them from the file when needed.

> When upgrading programs/libraries on POSIX this situation is usually
> avoided by not overwriting the existing file, but rather by writing
> the new file to a temporary name, then renaming it on top of the
> correct name.

It was HP-UX that I had problems with some years ago. I got
used to doing this manually to avoid the problem. It might be
that Windows systems lock the file such that it can't be changed
while a program is still running.

-- glen

From: robin on
"Richard Maine" <nospam(a)see.signature> wrote in message news:1jezwx8.1bjcz2sz7xlpN%nospam(a)see.signature...
|I think you got the other points right, but...
|
| monir <monirg(a)mondenet.com> wrote:
|
| > d) if X, m, n are dummy arguments, then one can't use Data statement,
| > but maybe:
| > ...Real :: X(m,n) = 0.0
|
| No. If X is a dummy argument, then you can't initialize it at all. That
| isn't a matter of syntax, but is more fundamental than that. Fiddling
| with different statement forms won't help. The closest you could come
| would be default initialization for an intent(out) dummy argument of
| derived type, but that's pretty far from your case.
|
| You can use an assignment statement, as in
|
| x = 0.0
|
| but that isn't initialization, as defined by Fortran.

In programmming, it is called "initialization".

| It is very
| important to understand the distinction. In particular, initialization
| happens once, at the first call (or you can think of it that way). If
| you want the zeroing to happen on every call, then you don't want
| initialization.

You do want initialization, in the general sense.
Initializing a variable can take place once,
or it can take place on every call.

Whether the initialization is done once,
or whether it is done on every call,
is determined by how you write the code.