I'm trying to get an MS/Compaq Fortran program to compile with HP-UX
f90 and I'm getting the message:

     "too many continuation lines"

in a module where a character array is being initialized with 99 
lines of character data. Each line represents one 80 character
string in an array that has 100, 80 character elements. Each line
has a continuation symbol (&) at the end of the line. The compiler
wants to quit after about 90 lines.

Is there a switch or compilation setting anyone knows of to 
correct this. I know how to get around it but it will save time 
if I can leave it as is because there's quite a bit of this 
silliness going on in this program.

Thanks, 

James Kimble

James Kimble wrote:
> I'm trying to get an MS/Compaq Fortran program to compile with HP-UX
> f90 and I'm getting the message:
> 
>      "too many continuation lines"
> 
> in a module where a character array is being initialized with 99 
> lines of character data. Each line represents one 80 character
> string in an array that has 100, 80 character elements. Each line
> has a continuation symbol (&) at the end of the line. The compiler
> wants to quit after about 90 lines.

Wow. 90? I thought 39 lines was the maximum allowed by the standard?

M&R tells me the same thing (pg 12 2nd ed.) As well as pointing out that interspersed 
continuation lines don't count towards the 39! Cool. I did not know that. :o)

> Is there a switch or compilation setting anyone knows of to 
> correct this. I know how to get around it but it will save time 
> if I can leave it as is because there's quite a bit of this 
> silliness going on in this program.

Sorry, I've used HP-UX fortran90 about twice in my life. I never found that sort of switch 
on other compilers (although, truth be told, I haven't looked too hard.)

cheers,

paulv

Paul Van Delst <paul.vandelst@noaa.gov> writes:

> Wow. 90? I thought 39 lines was the maximum allowed by the standard?

It is, but allowing more is a common extension.  I've seen
samples of a few hundred lines on occasion.  Most compilers have
an option to allow more.  Sorry, but I don't know the hp-ux
incantation.  Doesn't it have a man page?  This is the kind of
switch typically mentioned in man pages.

Btw, the standard number is 255 in the f2003 draft.

-- 
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

Richard Maine <nospam@see.signature> wrote in message news:<m1hdvm2mo7.fsf@macfortran.local>...
> Paul Van Delst <paul.vandelst@noaa.gov> writes:
> 
> > Wow. 90? I thought 39 lines was the maximum allowed by the standard?
> 
> It is, but allowing more is a common extension.  I've seen
> samples of a few hundred lines on occasion.  Most compilers have
> an option to allow more.  Sorry, but I don't know the hp-ux
> incantation.  Doesn't it have a man page?  This is the kind of
> switch typically mentioned in man pages.
> 
> Btw, the standard number is 255 in the f2003 draft.

Yeah, I did search the man page and the release notes that came with
the compiler, no joy. Oh well, as I said I can certainly work around
it. Thanks for your help.

jk

Richard Maine wrote:

> Btw, the standard number is 255 in the f2003 draft.

*boggle*

I thought the ten continuation lines I had to initialise an array were 
excessive.....

Richard

Richard Edgar <rge21@astro.su.se> writes:

> Richard Maine wrote:
> 
> > Btw, the standard number is 255 in the f2003 draft.
> 
> *boggle*
> 
> I thought the ten continuation lines I had to initialise an array were
> excessive.....

I've seen people limited to 10 because their convention for
continuation characters failed there.  :-)  (The digit 0 is not
valid as a continuation character).

In the cases I've observed, the huge numbers of continuation lines
most commonly come from initializing large data tables.  For example,
you might see all the aerodynamic data for a simulator in some
large arrays.

I tend to recommend that such large tables be initialized by reading
them from a data file (as most flight simulators do) instead of by
using huge data statements.  But people don't always take my
recommendations.  :-) And in rare cases, I can even be convinced that
the balance of the arguments tilts against using a data file.

I also recall a few cases of format statements get up to a hundred or
2 lines.  I would not have written them that way myself, but I've seen
it.  They basically formatted a whole screen full of labels and
values, all in one format statement.

-- 
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

In a previous article, Richard Maine <nospam@see.signature> wrote:
>Richard Edgar <rge21@astro.su.se> writes:
> 
>> Richard Maine wrote:
>> 
>> > Btw, the standard number is 255 in the f2003 draft.
>> 
>> *boggle*
>> 
>> I thought the ten continuation lines I had to initialise an array were
>> excessive.....
> 
>I've seen people limited to 10 because their convention for
>continuation characters failed there.  :-)  (The digit 0 is not
>valid as a continuation character).
> 
>In the cases I've observed, the huge numbers of continuation lines
>most commonly come from initializing large data tables.  For example,
>you might see all the aerodynamic data for a simulator in some
>large arrays.

<snip> 

 ALthough I'm happy with Fortran 77 as is ... (WATCOM anyway) - I've
  often thought it would be nice to have an internal read from a 
  source program segment instead of a separate data file. E.g. the 
  compiler tags the data sections and stores them verbatim.That way
  everything required is still in the source and it can be
  organized in a more readable, and probably more efficient, way 
  than with data statements.

 Chris

meek@skyway.usask.ca wrote:
(snip)

>>In the cases I've observed, the huge numbers of continuation lines
>>most commonly come from initializing large data tables.  For example,
>>you might see all the aerodynamic data for a simulator in some
>>large arrays.

It would make some sense for compilers to have a different limit
for continuation lines for DATA statements and related initialization
statements, than other types of statements.

> <snip> 
> 
>  ALthough I'm happy with Fortran 77 as is ... (WATCOM anyway) - I've
>   often thought it would be nice to have an internal read from a 
>   source program segment instead of a separate data file. E.g. the 
>   compiler tags the data sections and stores them verbatim.That way
>   everything required is still in the source and it can be
>   organized in a more readable, and probably more efficient, way 
>   than with data statements.

Well, one could do in internal read off an array of CHARACTER
variables.  I don't think that helps much, though.
(If I understand it right, an array is read as multiple
records of input, just like a multiple line data file.)
I would expect it to be less efficient, as the character
to numeric value is done at run time instead of compile time.

In the F66 days, with static allocation, compilers I knew compiled
DATA to initialize the static data.  Pretty efficient where
the numbers varied, not so efficient if they are all the same.
With dynamically allocated arrays it will need to be copied from
a static array at run time.

I did once initialize a large array to zero in a DATA statement
and then punch out the object deck on real cards.  A large number
of cards were needed for those zeros.  Most likely a loop to
initialize an array is faster than the process of loading the
executable file from disk.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> In the F66 days, with static allocation, compilers I knew compiled
> DATA to initialize the static data.

They still do.  And anything with initialization is automatically
"static".  Well, technically it is SAVEd, which doesn't *HAVE* to
mean static - I have worked on systems where it didn't, but I
know of no systems today where SAVE isn't implemented as static.

> Pretty efficient where
> the numbers varied, not so efficient if they are all the same.
.....
> I did once initialize a large array to zero in a DATA statement
> and then punch out the object deck on real cards.  A large number
> of cards were needed for those zeros.  Most likely a loop to
> initialize an array is faster than the process of loading the
> executable file from disk.

I have seen compilation of an otherwise modest program crash a
server-class system by running it out of temporary disk space.
That's just compilation.  Large static arrays can be *VERY*
inefficient aand often are on current architectures.  I made a
trivial change to that code to initialize the arrays with loops
instead of DATA statements (this case wasn't huge aero tables,
which would have had different values all over - these arrays were
mostly initialized to simple patterns - not quite all zeros, but
simple enough to express in trivial loops.)  Reduced the size of
the executable image from 30 mb down to about 1.  Compile time
dropped by a few orders of magnitude also - I forget how many,
but more than one (and I'm not counting the cases of "infinite"
compile times from when the compilation crashed the system).

-- 
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

Richard Maine wrote:

> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

>>In the F66 days, with static allocation, compilers I knew compiled
>>DATA to initialize the static data.

> They still do.  And anything with initialization is automatically
> "static".  Well, technically it is SAVEd, which doesn't *HAVE* to
> mean static - I have worked on systems where it didn't, but I
> know of no systems today where SAVE isn't implemented as static.

I wss never too sure about SAVE.  The easy answer is to still
statically allocate everything, and not worry about SAVE.
In C, which allows recursion, automatic variables must be
generated for each instance, and the initial values copied in.

>>Pretty efficient where
>>the numbers varied, not so efficient if they are all the same.

>>I did once initialize a large array to zero in a DATA statement
>>and then punch out the object deck on real cards.  A large number
>>of cards were needed for those zeros.  Most likely a loop to
>>initialize an array is faster than the process of loading the
>>executable file from disk.

> I have seen compilation of an otherwise modest program crash a
> server-class system by running it out of temporary disk space.
> That's just compilation.  Large static arrays can be *VERY*
> inefficient aand often are on current architectures.  I made a
> trivial change to that code to initialize the arrays with loops
> instead of DATA statements (this case wasn't huge aero tables,
> which would have had different values all over - these arrays were
> mostly initialized to simple patterns - not quite all zeros, but
> simple enough to express in trivial loops.)  Reduced the size of
> the executable image from 30 mb down to about 1.  Compile time
> dropped by a few orders of magnitude also - I forget how many,
> but more than one (and I'm not counting the cases of "infinite"
> compile times from when the compilation crashed the system).

So it was about 29MB of static data?  In the F66 days I don't
think anyone would think about doing that, except possibly
on a Cray-1.

The worst I had was a C compiler on an Alpha, which would
happily allocate many gigabytes dynamically, but refused
to even compile 100K of static data.  It didn't crash
the compiler, but it wouldn't compile it, either.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Richard Maine wrote:
> 
> > glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> 
> >>In the F66 days, with static allocation, compilers I knew compiled
> >>DATA to initialize the static data.
> 
> > They still do.  And anything with initialization is automatically
> > "static".  Well, technically it is SAVEd, which doesn't *HAVE* to
> > mean static - I have worked on systems where it didn't, but I
> > know of no systems today where SAVE isn't implemented as static.
> 
> I wss never too sure about SAVE.  The easy answer is to still
> statically allocate everything, and not worry about SAVE.
> In C, which allows recursion, automatic variables must be
> generated for each instance, and the initial values copied in.

Briefly confused me in talking about the easy answer until I
deduced that you must be talking about an answer for compilers,
as opposed to for programmers; otherwise, you've lost me.

Note that Fortran also has recursion these days.  Non-saved
variables in recursive procedures are not allowed to be static.

I know of no current Fortran compilers that implement saved variables
or common (even unsaved common) as anything other than static (well,
at the virtual address level, which isn't as static as static used to
be).

There are plenty of current compilers that, at least by default,
implement non-saved local variables nonstatically.

In the realm of non-current compilers, memory was precious enough
in some older environments that even SAVED variables and COMMON
weren't necessarily static; they might be overlayed and copied
out to disk, while the same memory address was used for something
else.  And it was not as transparent as virtual memory; if you
managed, through some tricks, to reference the address at a time
when the data wasn't there, you'd just get the wrong stuff,
rather than causing swapping.

> > Reduced the size of
> > the executable image from 30 mb down to about 1.

> So it was about 29MB of static data?  In the F66 days I don't
> think anyone would think about doing that, except possibly
> on a Cray-1.

I didn't add up the arrays, but yes, I conclude that's about how
large they must have been.  This wasn't in f66 days.  I forget
the exact date, but sometime in the 90's - probably mid 90's.

Though I noted that the programmer was using an identifiably
60's era style in many ways, not just language constructs.
For example, the source code was explicitly designed to be
printed out; the source code documentation was mostly keyed to
page numbers of the printed listing.  Somewhat random mix of
f66 and f77 coding styles...with the occasional small bit of
f90, mostly where it was using my library modules.

-- 
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

Richard Maine wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

(snip)

>>I wss never too sure about SAVE.  The easy answer is to still
>>statically allocate everything, and not worry about SAVE.
>>In C, which allows recursion, automatic variables must be
>>generated for each instance, and the initial values copied in.

> Briefly confused me in talking about the easy answer until I
> deduced that you must be talking about an answer for compilers,
> as opposed to for programmers; otherwise, you've lost me.

Easy for compiler writers, yes.

> Note that Fortran also has recursion these days.  Non-saved
> variables in recursive procedures are not allowed to be static.

I think I knew that, but I forgot which version it arrived in.
I know that F77 didn't have it, though, so I could never figure
out what SAVE was needed for.

> I know of no current Fortran compilers that implement saved variables
> or common (even unsaved common) as anything other than static (well,
> at the virtual address level, which isn't as static as static used to
> be).

> There are plenty of current compilers that, at least by default,
> implement non-saved local variables nonstatically.

Some of those might be written using the back end of C compilers.

> In the realm of non-current compilers, memory was precious enough
> in some older environments that even SAVED variables and COMMON
> weren't necessarily static; they might be overlayed and copied
> out to disk, while the same memory address was used for something
> else.  And it was not as transparent as virtual memory; if you
> managed, through some tricks, to reference the address at a time
> when the data wasn't there, you'd just get the wrong stuff,
> rather than causing swapping.

I did write some programs with overlays for RT-11, though that
was F66 and I tried to keep all the important data in the root
segment.

>>>Reduced the size of
>>>the executable image from 30 mb down to about 1.

>>So it was about 29MB of static data?  In the F66 days I don't
>>think anyone would think about doing that, except possibly
>>on a Cray-1.

> I didn't add up the arrays, but yes, I conclude that's about how
> large they must have been.  This wasn't in f66 days.  I forget
> the exact date, but sometime in the 90's - probably mid 90's.

> Though I noted that the programmer was using an identifiably
> 60's era style in many ways, not just language constructs.
> For example, the source code was explicitly designed to be
> printed out; the source code documentation was mostly keyed to
> page numbers of the printed listing. 

Is there a way to control the page boundaries?  In C you can put
form-feed characters in the file, though I don't like to do it
for about the same reason as tabs.  Some assemblers have a directive
that says to start a new page, too.

I don't know that is is part of the language, but IBM's PL/I
compilers default is to use columns 2 through 72.  You can
then tell the compiler to use column 1 as carriage control for
the source listing.   I did it once, with page eject in strategic
places, and some comments were overprinted to make them darker
(in the days of impact printers where that worked).

> Somewhat random mix of
> f66 and f77 coding styles...with the occasional small bit of
> f90, mostly where it was using my library modules.


-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> I know that F77 didn't have it [recursion], though, so I could never figure
> out what SAVE was needed for.

F77 *PARTICULARLY* needed save exactly for the reasons I mentioned.
Memory was too precious for everything to be implemented statically
in many large apps.  I've never seen an f90 implementation where
save made any difference in common.  I *DID* work with f77
implementations where it made a difference, both for common and
for local variables.

With CDC f77 compilers, SAVED variables and commons were written
out and restored from a file at appropriate times when using the
segloader (which you needed to do to access more than the equivalent
of about 1 megabyte of memory - well, either the segloader or
overlays or level 2 memory; the segloader was the only one of these
that didn't require nonstandard coding).  If you put your common
in a segment and didn't save it, the data would indeed get "lost"
when the segment went inactive - just like the standard allows...
and I'm sure that implementations like that were exactly why the
feature was added to the standard.  Not that I was aware of J3
activities at the time, but I certainly noticed and made use of
the result - yes it mattered.

-- 
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

Richard Maine wrote:

> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

>>I know that F77 didn't have it [recursion], though, so I could never figure
>>out what SAVE was needed for.

> F77 *PARTICULARLY* needed save exactly for the reasons I mentioned.
> Memory was too precious for everything to be implemented statically
> in many large apps.  I've never seen an f90 implementation where
> save made any difference in common.  I *DID* work with f77
> implementations where it made a difference, both for common and
> for local variables.

For the algorithms I was used to at the time, usually there were
some number of large arrays that you needed most or all of the
time, and usually those were in COMMON.   Many algorithms are
carefully designed to work in place to save against temporary
arrays.  All the implementations of matrix inversion and FFT
that I know of work in place.

Then, if you have two or more arrays of similar size that aren't used
at the same time you can EQUIVALENCE them.   Also, library subroutines
required a work array to be passed for their temporary arrays.
You could then reuse the work arrays between different routines.

So, SAVE, and not saving temporary arrays, allows them to be reused 
without explicit EQUIVALENCE and the problems it can cause.

Since actual arrays declarators must have constant dimensions in F77,
to me there wasn't so much savings.  The only way you could write
general purpose routines was to pass the arrays as arguments, anyway.


(snip)

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Richard Maine wrote:
> 
> > glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> 
> >>I know that F77 didn't have it [recursion], though, so I could never figure
> >>out what SAVE was needed for.
> 
> > F77 *PARTICULARLY* needed save exactly for the reasons I mentioned.
> > Memory was too precious for everything to be implemented statically
> > in many large apps.  I've never seen an f90 implementation where
> > save made any difference in common.  I *DID* work with f77
> > implementations where it made a difference, both for common and
> > for local variables.
> 
> For the algorithms I was used to at the time, usually there were
> some number of large arrays that you needed most or all of the
> time, and usually those were in COMMON.   Many algorithms are
> carefully designed to work in place to save against temporary
> arrays.  All the implementations of matrix inversion and FFT
> that I know of work in place.

I'm talking about whole programs - not just algorithms.  Major (or
even moderate) programs often involve many algorithms.  One example I
recall was a program that did a bunch of calculations and then some
plotting.  The calculation and plotting were quite separate.  Could
presumably have been done in separate programs, communicating via a
data file - but that's not the way it was done.  Both used a lot (for
the time) of memory.  Making them use the same memory via common or
equivalence tricks would have required major recoding just to achieve
that - a pretty severe violation of what I regard as good design
principles.  There were a bunch of other programs that I know of that
used save vs nonsave distinctions usefully, but anyway...

I have no doubt that this could all have been done other ways.  Most
things can be done multiple ways.  I was simply trying to make the
point that yes, SAVE was a useful thing and it did get used.  That was
my only reason for posting.  My definition of "useful" does not imply
that it would have been impossible to do the job some other way.
It does, however, mean that I found it a lot simpler this way.

-- 
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

Richard Maine wrote:

(snip)

> I'm talking about whole programs - not just algorithms.  Major (or
> even moderate) programs often involve many algorithms.  One example I
> recall was a program that did a bunch of calculations and then some
> plotting.  The calculation and plotting were quite separate.  Could
> presumably have been done in separate programs, communicating via a
> data file - but that's not the way it was done.  Both used a lot (for
> the time) of memory.  Making them use the same memory via common or
> equivalence tricks would have required major recoding just to achieve
> that - a pretty severe violation of what I regard as good design
> principles.  There were a bunch of other programs that I know of that
> used save vs nonsave distinctions usefully, but anyway...

Yes, my use of the word algorithm was a little too general.

One program I worked on around that time used Calcomp subroutines
to write a 7 track tape to be sent to a Calcomp plotter.
Those routines didn't do much processing before writing the tape.

I replaced most of the calls with a single unformatted write each,
which wrote the appropriate data to disk.  Somewhat interesting,
as they write the length of an array, and use it in two implied
DOs, in the same statement.

It was then relatively easy to read back and write to the
appropriate graphics device.

Other people do like to integrate the graphics as you say.
I like the device independence of the disk file, and the ability
to plot it multiple times on the same or different device.

-- glen