Re: modifying constants in Fortran and elsewhere

On Sunday, July 16, 2023 at 9:43:20 AM UTC-7, Thomas Koenig wrote:


(snip)


> I just have the IBM System/360 Operating System FORTRAN IV (H)
> Programmer's Guide, Fourth Edition, open (isn't Bitsavers great?).
>
> It states, on page 108
>
> Argument List
>
> The argument list contains addresses of
> variables, arrays, and subprogram names
> used as arguments. Each entry in the argu-
> ment list is four bytes and is aligned on a
> full-word boundary. The last three bytes
> of each entry contain the 24-bit address of
> an argument. The first byte of each entry
> contains zeros, unless it is the last entry
> in the argument list. If this is the last
> entry, the sign bit in the entry is set on.


> So, apparently no copy in/out on that particular compiler, at least.
> It also shows the (ab)use that was possible of the uppermost byte,
> because clearly 24 bits are enough for everybody and for all
> time, right? :-)


Soon after I started learning OS/360 Fortran, I found the LIST compiler option.


That gives a listing, sort-of, of the generated assembly code.
(Not good enough to actually assemble, but useful to figure out
what it actually does.)


First, OS/360 Fortran, like just about all the others at the time, does
all static allocation. The MAP option gives a listing of all the variables
used, and their addresses.


Each subroutine has a prologue, which copies all scalar variables to
the address indicated in the map, and an epilogue which copies them
back.


Variables are stored just after the executable code, and so addressable
with the same base register, as long as it fits in 4K bytes.
(Or two or three base registers for 8K or 12K bytes.) Once copied,
they are easily directly addressed.


Otherwise, to use one, the address is loaded into a register, and then
used, requiring usually two instructions. And two instructions to
copy each in, and two more to copy back out. So any variable referenced
more than four times, is faster with the copy.


And yes, you can put the dummy argument between slashed, in which case
it won't do that.


There is one reason given by IBM. A DIRECT ACCESS statement, used with
a direct access file, keeps a variable with the record number of the next
record, in case you want to read sequentially. If you need to reference that
from a called subroutine, you need the slashes.


There are a few other cases involving variables in COMMON, such that a
variable could change at an unusual time.


In any case, the Fortran standard, since Fortran 66 allows for this.


I didn't know until the above note from or moderator that went back
to the IBM 704, where Fortran originated. I don't know the addressing
modes of the 704, and how or why that helped.


The only other compiler that I know in that much detail is Fortran-10
for the PDP-10. The PDP-10 has an indirect bit on addresses, such that
the processor will indirectly address with one instruction, though likely
the time of two instructions.


It is only more recently, with non-contiguous assumed shape arrays,
that this came back again. Fixed size and assumed size arrays are
assumed by the called routine to be contiguous. If a routine with
an assumed shape argument, calls another with assumed size,
it is usual to make a copy and pass that. Then copy back again
on return. In that case, it is the caller that does the copy, not the
callee, as for IBM.
[The 70x series had 15 bit word addressing with index registers. Even
though they mostly did sign/magnitude arithmetic, indexing worked by
doing a two's complement subtract of the index register from the
address in the instruction. (I've seen lots of guesses why they did
that, but never found an actual source.) So Fortran arrays were stored
in reverse order starting in high memory. 70x Fortran did not have
the /X/ argument specifier and I cannot find anything in the manuals
about argument aliasing, although the calling sequence example in the
FAP assember program shows how to copy in arguments.


The Fortran manual does say:


  A constant may not appear as an argument in the
  call to a SUBROUTINE or FUNCTION subprogram if
  the corresponding dummy variable in the definition
  of the subprogram appeared either on the let side of an
  arithmetic statement or in an input list.


-John]

Return to the comp.compilers page.
Search the comp.compilers archives again.