From: Lynn McGuire on
>> I think that our code needs zeroing upon EACH entry of our subroutines.
>> I have been trying this out and have gotten several benchmark files to run
>> to completion now by adding the zeroing of a few key variables (the indexes
>> for the arrays variables have been killers).
> ...
>
> If that's the case, it's been wrong w/ the /SAVE option because it does _NOT_ do that at all.

I do not disagree with that statement. That is why I think that the explicit
zeroing of our local variables will be better for the code as that initial value
of zero in each subroutine call will be much more consistent with the
resultant calculations.

Thanks,
Lynn


From: dpb on
dpb wrote:
> Lynn McGuire wrote:
> ...
>
>> I think that our code needs zeroing upon EACH entry of our subroutines.
>> I have been trying this out and have gotten several benchmark files to
>> run
>> to completion now by adding the zeroing of a few key variables (the
>> indexes
>> for the arrays variables have been killers).
> ...
>
> If that's the case, it's been wrong w/ the /SAVE option because it does
> _NOT_ do that at all.
>
> >> type wat.for
>
> program wat
> x = 1.0
>
> call foo(x)
> call foo(x)
> end
>
> Subroutine foo(x)
>
> x = x+1.
>
> print *, y
>
> y = y+1.0
> End
>
>
> C:\Temp> wfl386 /save wat.for
> Watcom F77/32 Compile and Link Utility Version 11.0
> Copyright by Sybase, Inc., and its subsidiaries, 1990, 1997.
> All rights reserved. Watcom is a trademark of Sybase, Inc.
> wfc386 wat.for /save
> Watcom FORTRAN 77/32 Optimizing Compiler Version 11.0 2010/07/05 18:15:38
> Copyright by Sybase, Inc., and its subsidiaries, 1984, 1997.
> All rights reserved. Watcom is a trademark of Sybase, Inc.
> wat.for: 11 statements, 72 bytes, 1 extensions, 0 warnings, 0 errors
>
> WATCOM Linker Version 11.0
> Copyright by Sybase, Inc., and its subsidiaries, 1985, 1997.
> All rights reserved. Watcom is a trademark of Sybase, Inc.
> loading object files
> searching libraries
> creating a Windows NT character-mode executable
>
> C:\Temp> wat
> 0.0000000
> 1.0000000
>
> C:\Temp>

And,

C:\Temp> wfl386 /quiet wat.for

C:\Temp> wat
0.0000000
0.0000000

C:\Temp>

W/O /SAVE, y is zero on entry; with it retains its previous value.

So, if as I understand it, you've had global /SAVE and think the results
are correct, wherever there's an uninitialized variable it's not been
being reset and so adding that in will definitely be a change. Now,
whether that's important or not is indeterminate from here, but it
surely will be a different code behavior if do so.

As noted earlier by somebody, the DATA statement has the same
initialization effect as /SAVE and implicitly will cause /SAVE

C:\Temp> *type wat.for
program watfor
x = 1.0

call foo(x)
call foo(x)
end

Subroutine foo(x)
data y /0.0/

x = x+1.
print *, y
y = y+1.0
End

C:\Temp> wfl386 /quiet wat.for

C:\Temp> wat
0.0000000
1.0000000

C:\Temp>

--
From: dpb on
Lynn McGuire wrote:
>>> I think that our code needs zeroing upon EACH entry of our subroutines.
>>> I have been trying this out and have gotten several benchmark files to run
>>> to completion now by adding the zeroing of a few key variables (the indexes
>>> for the arrays variables have been killers).
>> ...
>>
>> If that's the case, it's been wrong w/ the /SAVE option because
>> it does _NOT_ do that at all.
>
> I do not disagree with that statement. That is why I think that the explicit
> zeroing of our local variables will be better for the code as that initial value
> of zero in each subroutine call will be much more consistent with the
> resultant calculations.

I'm truly confused now about what you think is the right answer...and
how you know whether the answer is, in fact, correct.

It makes no sense to me as the 2nd sentence of the first paragraph seems
to completely negate the assertion that the code has been running w/ OW
owing to /SAVE and its initialization (which is one-time only).

--
From: Lynn McGuire on
> C:\Temp> wfl386 /quiet wat.for
>
> C:\Temp> wat
> 0.0000000
> 0.0000000

> W/O /SAVE, y is zero on entry; with it retains its previous value.

That is not the behavior that I am seeing when the /save is dropped from
OW 1.9. I see that the y variable has a totally random, but consistent,
value upon usage. I see that you are using Watcom 11.0, not OW 1.9.

C:\dii>wfl386 /quiet wat.for

C:\dii>wat
6.0233654E+036
6.0233654E+036

> As noted earlier by somebody, the DATA statement has the same initialization effect as /SAVE and implicitly will cause /SAVE

Since I do not want that behavior, explicit initialization of the local variables
will be much better for me.

Thanks,
Lynn


From: Richard Maine on
dpb <none(a)non.net> wrote:

> Lynn McGuire wrote:
> >>> I think that our code needs zeroing upon EACH entry of our subroutines.

> I'm truly confused now about what you think is the right answer...and
> how you know whether the answer is, in fact, correct.
>
> It makes no sense to me as the 2nd sentence of the first paragraph seems
> to completely negate the assertion that the code has been running w/ OW
> owing to /SAVE and its initialization (which is one-time only).

I'm a little confused as well, but a possibility does occur to me. It
could be that the code runs ok now with zero-init+save because each
subroutine where this applies is called only once, but that it would
need zeroing on each entry if the code ended up being called multiple
times.

Just a guess as to what might be meant. I have run into situations like
that in the past, where a code was once a standalone program, but then
gets converted to run in a loop or otherwise do multiple cases. It can
be a pain if the original code assumed zero initialization. Been there.
Done that.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain