Prev: Don't understand what my program is doing
Next: problem in interface
From: Richard Maine on 24 May 2010 12:50
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:

> Richard Maine <nospam(a)see.signature> wrote:

> > There *HAVE* been compilers that made unsaved COMMON blocks lose
> > values, which is a simillar issue.
>
> As far as I know, that happened with overlays.

And with the CDC segloader. It had some characteristics simillar to
overlays, but was not quite the same thing. In particular, you did not
need to modify the Fortran source code to use the segloader, which is
why I used it.

> It seems likely to me that if you did move a
> COMMON block (or MODULE) into an overlay that its values would
> not stay saved, even with the SAVE attribute. At that point, it
> is the programmer's responsibility to get it right, not the compiler's.

Your guess as to the behavior with SAVE is wrong, at least in the case
of the segloader, if my recollection is correct. (And though my
recollection isn't as good as it used to be, I'll trust my recollection
of how things were above a speculation about how you would have thought
things likely to be.) The values were saved as appropriate.

If one insists on thinking of SAVE as meaning static, then it will lead
you to guessing incorrectly like that. But that's not how the standard
defines SAVE. It does not guarantee that SAVEd common blocks will remain
staticly in memory for all time. It just requires that the saved values
will be in the variables at the "appropriate" times (discussed elsewhere
and not repeated here).

As I recall, the segloader wrote SAVE'd common blocks out to disk when
the segment was swapped out, and then read them back in from disk when
the segment was swapped back in. It was perhaps a little like a virtual
memory system in that regard. In fact, when I first saw virtual memory
systems, I recall thinking that they were somewhat like the segloader,
but all done automatically.

Yes, it was up to the programmer to "get it right", but getting it right
meant sticking to the Fortran standard. The compiler mostly took it from
there, sort of like one might expect. (Yes, it was possible to mess up
the manually written segloader directives, it is true; you also had to
get those right). In fact, it so much matched the requirements of the
standard that one might think the vendor had some input into that part
of the standard. I wasn't there, but I'd guess that to have been the
case.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Gordon Sande on 24 May 2010 13:53
On 2010-05-24 13:50:02 -0300, nospam(a)see.signature (Richard Maine) said:

> glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:
>
>> Richard Maine <nospam(a)see.signature> wrote:
>
>>> There *HAVE* been compilers that made unsaved COMMON blocks lose
>>> values, which is a simillar issue.
>>
>> As far as I know, that happened with overlays.
>
> And with the CDC segloader. It had some characteristics simillar to
> overlays, but was not quite the same thing. In particular, you did not
> need to modify the Fortran source code to use the segloader, which is
> why I used it.

The overlay processors circa F66 did not require any modification of the
source. Some were completely automatic and constructed a dependency
tree which became the overlay structure. Such overlays were very fine
grained with much reloading of code segments as a result. Others used
user control caards to define the tree so could be less fine grained and
match what the programmer knew. The COMMONs were like any other other
code segment so the only way to achieve SAVE was to reference the COMMON in
the main program, there being no SAVE at that time. Other overlay processors
had multiple trees in multiple regions so that popular low level utilities
did not get pushed close to the root as they would with a single tree.

There was a scheme for Fortran II called chain which had multiple core images
like your segments but without the protection of blank (the only kind) common.
It required explicit calls to a chain loader. I have a vague memory that the
chain loader may have used the same memory as blank common. Chain was history
by the time Fortran IV arrived with loaders that could construct overlays.

Overlays may come back on tablets with only 256MB main memory. It is
interesting
how one eras problems go away only to come back. Optimization for
rotating (drum
or delay line) memory became cache optimization many years later.




From: glen herrmannsfeldt on 24 May 2010 15:04
Richard Maine <nospam(a)see.signature> wrote:
> glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:
>> Richard Maine <nospam(a)see.signature> wrote:

>> > There *HAVE* been compilers that made unsaved COMMON blocks lose
>> > values, which is a simillar issue.

>> As far as I know, that happened with overlays.

> And with the CDC segloader. It had some characteristics simillar to
> overlays, but was not quite the same thing. In particular, you did not
> need to modify the Fortran source code to use the segloader, which is
> why I used it.

That sounds like some from of overlay. The overlay systems I
have used: OS/360, RT-11, and Watcom, are all link time systems.
They don't require any changes to the source code, though you need
to know something about the source structure to make it work right.

>> It seems likely to me that if you did move a
>> COMMON block (or MODULE) into an overlay that its values would
>> not stay saved, even with the SAVE attribute. At that point, it
>> is the programmer's responsibility to get it right, not the compiler's.

> Your guess as to the behavior with SAVE is wrong, at least in the case
> of the segloader, if my recollection is correct. (And though my
> recollection isn't as good as it used to be, I'll trust my recollection
> of how things were above a speculation about how you would have thought
> things likely to be.) The values were saved as appropriate.

Overlay normally works well with code, which (except for self
modifying code) doesn't change. It is also faster not to have
to write back to disk, but I have known systems to work both ways.

> If one insists on thinking of SAVE as meaning static, then it will lead
> you to guessing incorrectly like that. But that's not how the standard
> defines SAVE. It does not guarantee that SAVEd common blocks will remain
> staticly in memory for all time. It just requires that the saved values
> will be in the variables at the "appropriate" times (discussed elsewhere
> and not repeated here).

Well, static usually means that the address is constant. In the
case of overlays, different segments share the same address.

> As I recall, the segloader wrote SAVE'd common blocks out to disk when
> the segment was swapped out, and then read them back in from disk when
> the segment was swapped back in. It was perhaps a little like a virtual
> memory system in that regard. In fact, when I first saw virtual memory
> systems, I recall thinking that they were somewhat like the segloader,
> but all done automatically.

> Yes, it was up to the programmer to "get it right", but getting it right
> meant sticking to the Fortran standard. The compiler mostly took it from
> there, sort of like one might expect. (Yes, it was possible to mess up
> the manually written segloader directives, it is true; you also had to
> get those right). In fact, it so much matched the requirements of the
> standard that one might think the vendor had some input into that part
> of the standard. I wasn't there, but I'd guess that to have been the
> case.

The three I mentioned above work in similar ways. Many only do
overlay on CALL, and not RETURN, such that it is the programmers
responsibility to make sure that the calling routine is still in
memory on return. Also, all three are generally considered
static overlays, where the addresses are determined at link time.
I remember reading about, but not using, the Borland overlay system
that was more dynamic, and sounds more like the segloader.

All of which explains code, but not data. For OS/360 Fortran
compilers, and many other Fortran compilers, local variables
are static and in the same control section as code. They would
then be overwritten on overlay, but then there was no SAVE in
Fortran 66. Usually the important variables end up in COMMON
(or as subroutine arguments) so you might not even notice local
variables not being saved.

Static overlays work very well for programs the spend much time
on one part of the code, and then much time in another part, but
not so much switching between the two. Easiest if you can put
all the data in the root segment, otherwise carefully select
which arrays can go into overlays.

-- glen

From: Richard Maine on 24 May 2010 15:04
Gordon Sande <Gordon.Sande(a)gmail.com> wrote:

> On 2010-05-24 13:50:02 -0300, nospam(a)see.signature (Richard Maine) said:
>
> > glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:
> >
> >> Richard Maine <nospam(a)see.signature> wrote:
> >
> >>> There *HAVE* been compilers that made unsaved COMMON blocks lose
> >>> values, which is a simillar issue.
> >>
> >> As far as I know, that happened with overlays.
> >
> > And with the CDC segloader. It had some characteristics simillar to
> > overlays, but was not quite the same thing. In particular, you did not
> > need to modify the Fortran source code to use the segloader, which is
> > why I used it.
>
> The overlay processors circa F66 did not require any modification of the
> source....Others used
> user control caards to define the tree so could be less fine grained and
> match what the programmer knew.

Yes, come to think of it, I recall such overlay schemes from when I was
using an IBM mainframe at Dryden (well, it wasn't named Dryden yet then
- just the Flight Research Center, FRC) circa 1970-1973. Then when FRC
switched to a CDC in 1973, the overlay scheme there was a different one,
which involved changing subroutine statements to OVERLAY statements and
corresponding call statements to call the overlay manager. I wasn't fond
of that idea, but eventually found the segloader, which was more like
the overlay scheme I had used on the IBM in that I could use control
cards to define the tree, as you describe.

I used the Dryden/FRC CDC machines for longer (1973-1985) and more
recently than the IBMs, so I recall a bit more detail about them.

I don't recall what I did for COMMON blocks in the segloader pre-f77.
The dates imply that I must have done something, but I'm not recalling.
Maybe they all ended up in the root segment. I do, however, recall
putting them elsewhere once f77 and the SAVE statement came along, and I
recall the segloader being aware of SAVE. Among other things, there were
separate segments for saved and non-saved local variables in procedures.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Richard Maine on 24 May 2010 15:15
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:

> Many [overlay systems] only do
> overlay on CALL, and not RETURN, such that it is the programmers
> responsibility to make sure that the calling routine is still in
> memory on return.

One of the more esoteric features of the CDC segloader was that you
could call a procedure in a segment that "overlaid" the one you were
calling from. The argument list was copied into some temporary location
so that you didn't lose it when the calling procedure swapped out.

That feature of copying the argument list had some "nasty" consequences
if your actual and dummy argument lists did not agree on the number of
arguments. One of the worst debugging experiences I had in that era was
related. I had the wrong number of arguments for one call. That
particular call worked fine anyway. But the extra argument probably
trashed something when the argument list was too long for the temporary
location that it got copied to. The symptoms showed up in some
completely unrelated call in a far distant part of the program that was
executed far later. That was a very frustrating debugging experience.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Don't understand what my program is doing
Next: problem in interface