From: Nick Maclaren on
In article <rKGdnVw8GP01msLRnZ2dnUVZ_jqdnZ2d(a)supernews.com>,
Gary L. Scott <garylscott(a)sbcglobal.net> wrote:
>>>
>>>>> That doesn't tell me for sure whether it was f77 or f66 plus ENTRY as an
>>>>> externsion.
>>>
>>>> The preface says "includes full ANS FORTRAN (X3.9-1978) plus IBM
>>>> extensions".
>>>
>>> Ah. That's more explicit then.
>>
>> VS Fortran was the compiler I described the history of.
>
>I use it to this day, in fact last week...

Say hello to it from me, please :-)


Regards,
Nick Maclaren.
From: Ron Shepard on
In article <1jmwkol.1ngbt631cg29baN%nospam(a)see.signature>,
nospam(a)see.signature (Richard Maine) wrote:

> I'm fairly sure I
> recall some IBM f66 compilers as having ENTRY as an extension. In fact,
> I think I recall having some porting pains because both the IBM and CDC
> compilers had ENTRY, but with different syntax.

One of the "features" of IBM (f66+extension) ENTRY points was that
dummy arguments from one entry that was previously called could be
accessed by code in subsequent entry calls. That is, one entry
point could be called to set the base addresses for some set of
dummy arrays, or for some set of scalar variables, and then those
scalars and arrays could be used later. The other entry points
could then have shorter argument lists, making the code (uh...what
is the word I'm looking for...) 'simpler'. :-) In fact, trying to
figure out how such code written by other programmers actually
worked was a nightmare, and when it came time to port this code to
standard f77 machines, it sometimes took quite some effort. In many
cases where the 'initialization' occurred at some high level in the
code and the later entry calls were several levels down, it required
modifying the argument lists for dozens of subroutines to add the
missing dummy arguments. Sometimes these arguments were used as
read-only variables in the low-level calls (read, but not modified),
other times they were used as internal workspace (values did not
need to be saved between calls), and other times the arguments
defined some global state (values were modified and needed to be
saved between calls). The best "fix" for all of these situations
was often different within f77.

I had to port such code to several different machines, mostly DEC,
Harris, Convex, and FPS, but also including some CDC, Cyber, and ETA
along the way. Some machines/compilers would take the IBM style
code, others wouldn't, so the best solution was to port all of it to
f77. Before f90, entry points were the only way to encapsulate data
locally within a set of related routines, so unlike many other
programmers who tried to avoid entry points entirely, I actually
liked using them in many situations, including for example library
routines.

$.02 -Ron Shepard
From: Gary L. Scott on
On 8/8/2010 2:57 PM, Ron Shepard wrote:
> In article<1jmwkol.1ngbt631cg29baN%nospam(a)see.signature>,
> nospam(a)see.signature (Richard Maine) wrote:
>
>> I'm fairly sure I
>> recall some IBM f66 compilers as having ENTRY as an extension. In fact,
>> I think I recall having some porting pains because both the IBM and CDC
>> compilers had ENTRY, but with different syntax.
>
> One of the "features" of IBM (f66+extension) ENTRY points was that
> dummy arguments from one entry that was previously called could be
> accessed by code in subsequent entry calls. That is, one entry
> point could be called to set the base addresses for some set of
> dummy arrays, or for some set of scalar variables, and then those
> scalars and arrays could be used later. The other entry points
> could then have shorter argument lists, making the code (uh...what
> is the word I'm looking for...) 'simpler'. :-) In fact, trying to
> figure out how such code written by other programmers actually
> worked was a nightmare, and when it came time to port this code to
> standard f77 machines, it sometimes took quite some effort. In many
> cases where the 'initialization' occurred at some high level in the
> code and the later entry calls were several levels down, it required
> modifying the argument lists for dozens of subroutines to add the
> missing dummy arguments. Sometimes these arguments were used as
> read-only variables in the low-level calls (read, but not modified),
> other times they were used as internal workspace (values did not
> need to be saved between calls), and other times the arguments
> defined some global state (values were modified and needed to be
> saved between calls). The best "fix" for all of these situations
> was often different within f77.
>
> I had to port such code to several different machines, mostly DEC,
> Harris, Convex, and FPS, but also including some CDC, Cyber, and ETA
> along the way. Some machines/compilers would take the IBM style
> code, others wouldn't, so the best solution was to port all of it to
> f77. Before f90, entry points were the only way to encapsulate data
> locally within a set of related routines, so unlike many other
> programmers who tried to avoid entry points entirely, I actually
> liked using them in many situations, including for example library
> routines.

I used to use "initialization" entry points with subsequent calls having
shorter argument lists (but with matching types with the subroutine). I
stopped doing it when I found that others had trouble following the logic.

>
> $.02 -Ron Shepard

From: glen herrmannsfeldt on
Ron Shepard <ron-shepard(a)nospam.comcast.net> wrote:
(snip)

> One of the "features" of IBM (f66+extension) ENTRY points was that
> dummy arguments from one entry that was previously called could be
> accessed by code in subsequent entry calls. That is, one entry
> point could be called to set the base addresses for some set of
> dummy arrays, or for some set of scalar variables, and then those
> scalars and arrays could be used later. The other entry points
> could then have shorter argument lists, making the code (uh...what
> is the word I'm looking for...) 'simpler'. :-)

I think that isn't quite right, at least for Fortran IV.

From "S/360 and S/370 Fortran IV":

"Arguments that were received by value at some previous use of
the subprogram need not appear in the argument list of the
ENTRY statement. Arguments that were received by location
must appear."

They use call by value result for scalars, and call by reference
(location) for arrays. (Also, dummy arguments enclosed in slashes.)

So, only scalars keep their value, and not their base address.
(Note that storing the address would give strange results, as changes
to the base variable would change the value seen in the subroutine.)

I don't have a VS Fortran manual, so it might have changed, but
likely not, other than removing the feature. For S/360 (and
successors) it takes one instruction to reference a local variable,
but two to reference a variable by reference. Call by value
result is, in most cases, more efficient.

> In fact, trying to
> figure out how such code written by other programmers actually
> worked was a nightmare, and when it came time to port this code to
> standard f77 machines, it sometimes took quite some effort. In many
> cases where the 'initialization' occurred at some high level in the
> code and the later entry calls were several levels down, it required
> modifying the argument lists for dozens of subroutines to add the
> missing dummy arguments.

Well, you could also copy the value to a SAVEd variable for
later use.

> Sometimes these arguments were used as
> read-only variables in the low-level calls (read, but not modified),
> other times they were used as internal workspace (values did not
> need to be saved between calls), and other times the arguments
> defined some global state (values were modified and needed to be
> saved between calls). The best "fix" for all of these situations
> was often different within f77.

-- glen
From: Terence on
On Aug 9, 12:08 am, nos...(a)see.signature (Richard Maine) wrote:
> Terence <tbwri...(a)cantv.net> wrote:
> > 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".
> > LCM=120000B
>
> Variable values aren't bytes, bits, or any units. They are just numbers.
> At least that is so in Fortran (and almost all computer languages). The
> programmer's intent can be for those numbers to represent numbers of
> some unit, but you won't find that in the language syntax.
>
> Numbers in Fortran have a base, but not units. Binary and hex would be
> bases. Bits and bytes are units. I think I detect a confusion between
> the two.
>
> CDC machines of that era did not have bytes. At all.
>
> Somewhat oddly, the B in this syntax on a CDC indicates octal. It is
> just my speculation, but I suppose that they (correctly) figured that
> using the letter O for such a thing would be prone to being misread as a
> digit 0. I also think there was a bit of a notion that octal was just
> sort of a shorter notation for a value that one might think of as
> binary. It is so trivial to translate octal to binary in one's head that
> I think casual terminology sometimes blurred the difference.
>
> If this represents something about memory (as is plausible - the CM in
> LCM might stand for core memory), the units are probably 60-bit words.
> That's the units that memory was measured in. As noted previously,
> characters were 6 bits, but the machine could not physically address
> individual characters and there wasn't really a term used to refer to
> the storage used by a character. On occasion, you might here someone
> talking about the machines having a 6-bit byte, but I don't consider
> that accurate; they just didn't have bytes of any size - only words.
>
> --
> Richard Maine                    | Good judgment comes from experience;
> email: last name at domain . net | experience comes from bad judgment.
> domain: summertriangle           |  -- Mark Twain

Thank your Richard! So 120000B is 120000 octal. I noticed a comment
somewhere else about getting memory in chunks of "100 octal" or 64
bytes. So that value is 10 times 64 times 64 = 40960 or 40k units of
storage words. Whereafter, the code checks it hasn't asked for as much
as that top value in a series of re-allocations of common (which I
have switched to named common for F77 compiling and better
availability).

This program did have output format statements that asked for Octal
and did it by saying "O12" where more usually one asks for "I12" (to
get a same-length different radix result, of course).
But the presence of the 120000B after using O for octal elsewhere,
made me think that B couldn't mean Octal in that statement. Now I
know.

But both my "F77" manuals actually say "F77" all over the texts; so
the issuers did think they had an F77 and not an F66 product to
describe (one is for Burroughs B22, the other is IBM PC AT).

As to the suggestion to go straight to DVF without pausing in F77 is
that far too much rewriting plus module interfacing would be needed;
also there is no distinction in this program between integer and float
storage units, so memory space is carved up as needed as text, integer
and floating point arrays. No way I could easily write the interfaces.