Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #3505
| From | gah4 <gah4@u.washington.edu> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: modifying constants in Fortran and elsewhere |
| Date | 2023-07-16 19:09 -0700 |
| Organization | Compilers Central |
| Message-ID | <23-07-009@comp.compilers> (permalink) |
| References | <23-07-003@comp.compilers> <23-07-006@comp.compilers> <23-07-008@comp.compilers> |
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]
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar
modifying constants in Fortran and elsewhere gah4 <gah4@u.washington.edu> - 2023-07-10 19:42 -0700
Re: modifying constants in Fortran and elsewhere Thomas Koenig <tkoenig@netcologne.de> - 2023-07-15 10:57 +0000
Re: modifying constants in Fortran and elsewhere Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-07-16 11:56 +0200
Re: modifying constants in Fortran and elsewhere Thomas Koenig <tkoenig@netcologne.de> - 2023-07-16 13:08 +0000
Re: modifying constants in Fortran and elsewhere gah4 <gah4@u.washington.edu> - 2023-07-16 19:09 -0700
Re: modifying constants in Fortran and elsewhere gah4 <gah4@u.washington.edu> - 2023-07-17 10:51 -0700
Re: modifying constants in Fortran and elsewhere gah4 <gah4@u.washington.edu> - 2023-07-16 19:17 -0700
Re: modifying constants in Fortran and elsewhere David Brown <david.brown@hesbynett.no> - 2023-07-17 13:09 +0200
csiph-web