From: glen herrmannsfeldt on
Terence <tbwright(a)cantv.net> wrote:
(snip)

> I see a simple way to insert an integer variable (values 1,2,3) in
> the parameter list for the three uses of the routine which has
> multiple entry points (one to initialise, one to run and one to output
> all final matrices). These three calls will now first set this value
> to 1,2 or 3 and call the routine, where the first line will branch to
> the appropriate code section.

If you don't, the compiler will. At least that is what it looks
like gfortran does with ENTRY. Little routines for each entry
point, then call the big routine will all the possible arguments.

-- glen
From: Nick Maclaren on
In article <a3b5decf-b61a-40da-a1ef-33c6e334b807(a)w15g2000pro.googlegroups.com>,
Terence <tbwright(a)cantv.net> wrote:
>
>I checked Nick's web-site and advice there, but this code is way too
>far dedicated to the CDC 6400 to be able to use any parsing system to
>modify it. It is a form of Fortran IV so in theory rewriting it to F77
>as a first step does semm indicated. The alorithms used are clear and
>could be followed by using a huge print-out of the 3000 lines and
>writing code while looking sideways, and with cut-and paste tricks
>(with two half screens) to help with the typing.
>
>I am a great user of parsing methods, which I have ised for my own
>hand-built commercial compilers that solve some any-language
>omunication problems, so I have used parsing a lot since 1961, so my
>believe that parsing won't help is experience-based.

A pity about that. I wasn't meaning to deprecate your experience,
but other people's ideas often help. I would be surprised if you
couldn't fix up the syntax, but that's often only 10% of the job
in the sort of code you are describing.

The way that I have often done that is to use automatic parsing
to fix up the simplest issues, and then got in and manually edited
the rest - more-or-less as you say, but using one screen rather than
two. That's obviously just a matter of personal preference. 3,000
lines is tedious, but not too foul a job.

I don't know of a better method for such code.


Regards,
Nick Maclaren.
From: Terence on
Well, I even have a program I wrote, to parse Fortran loaded with
Hollerith assiments and format statements, that looks for DO loops
that terminate on an assignments, and so adds the appropriate later
CONTINUE statement, moving the label (after checking this is actually
logically correct), and also nests levels, producing a very readable
output new source, and as an option re-writing everything with
sequential labels (in separate sequences for Formats and executable
statements).

The "gotcha" is that it (I) didn't expect hollerith assigments to
variables that were not some multiple of 4 bytes; and this program is
so chock-full of 6-character integer arrays of messages. The use of
hollerith in format statements is just re-written as literals, and
control bytes concatenated if possible.

As for the program under conversion, I mentioned all the open
statements needed, and some care over 20 scratch files used.
At least what I have now compiles without detected errors (which is
what the old trusty compiler is VERY good at, whatever unrecognised
faults it might have).

There just aren't any "simple" issues in this. Interesting how
similar is the problem to my lng conversion of the BMD programs last
year, rescued as source from DEC historic CDC files...

From: Louis Krupp on
On 8/8/2010 12:23 AM, Terence wrote:
> One more problematic item of code.
> The program assigns variables in a very-frequently-met trick of the
> old days, to a common block of memory defined as
> COMMON X(1)
>
> Then a routine is called ADJUST, which is first called with
> IM=0.
> This use then sets LRUN to the value of LCM and dfurthe use takes a
> new branch where memory is divided up fbeginnig the first defined
> address NUMBER.
> Am I correct in thinking this first use sets LCM to 120000 bytes (a
> CDC use of Fortran) or would this be 120000 BITS? It cannot be a bit
> value because of that "2".
>
> Once I get this understood I code the routine properly and can begin
> tesring.
>
>
> SUBROUTINE
> ADJUST(LRUN,LCM,IFL,IM) ADJUST 2
>
> IFL=0
> ADJUST 3
> IF (IM)
> 10,10,20 ADJUST 4
> 10
> LCM=120000B
> ADJUST 5
> RETURN
>

None of that is readable with my newsreader (Thunderbird).

I take it that the "ADJUST n" bits are sequence numbers in columns
73-80. If you could remove those and repost, it will look a lot better.

Louis

From: Louis Krupp on
On 8/7/2010 11:05 PM, Terence wrote:
> OK.
> Now I've got down to a compilable version, with the three ENTRY
> points commented out.
>
> I've asked permission to post the (user-puchased and copyright) code,
> still wainting for that.
>
> I see a simple way to insert an integer variable (values 1,2,3) in
> the parameter list for the three uses of the routine which has
> multiple entry points (one to initialise, one to run and one to output
> all final matrices). These three calls will now first set this value
> to 1,2 or 3 and call the routine, where the first line will branch to
> the appropriate code section.
>
> I have more or less reworked every character-containing variable to
> be strings of 6,12,18 or 60 characters and re-worked the reporting
> format statements.
>
> I still have to open and control 1 to 20 work files ("Tapes") which
> shuld be straight-forward.
>
> Ho-hum.. At least I'm not being a coauch potato today.
>
> My compiler for this job is MS 3.31 of August 1985. Checked manual
> index; nor reference to ENTRY, which I have used somewhere else in the
> past; bit surprised! Not in Burroughs, or IBM Fortran manuals of same
> date that I have, either.
>
> Then if and when this works I will go to DVF V6.6c as last check,
> then try real life data (which I have).

If DVF V6.6c implements ENTRY, could you use it instead of MS 3.31 now?
Then you could leave the ENTRY part alone.

Louis