Re: modifying constants in Fortran and elsewhere

gah4 <gah4@u.washington.edu>
Mon, 17 Jul 2023 10:51:56 -0700

          From comp.compilers

Related articles
modifying constants in Fortran and elsewhere gah4@u.washington.edu (gah4) (2023-07-10)
Re: modifying constants in Fortran and elsewhere tkoenig@netcologne.de (Thomas Koenig) (2023-07-15)
Re: modifying constants in Fortran and elsewhere DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2023-07-16)
Re: modifying constants in Fortran and elsewhere tkoenig@netcologne.de (Thomas Koenig) (2023-07-16)
Re: modifying constants in Fortran and elsewhere gah4@u.washington.edu (gah4) (2023-07-16)
Re: modifying constants in Fortran and elsewhere gah4@u.washington.edu (gah4) (2023-07-16)
Re: modifying constants in Fortran and elsewhere david.brown@hesbynett.no (David Brown) (2023-07-17)
Re: modifying constants in Fortran and elsewhere gah4@u.washington.edu (gah4) (2023-07-17)
| List of all articles for this month |

From: gah4 <gah4@u.washington.edu>
Newsgroups: comp.compilers
Date: Mon, 17 Jul 2023 10:51:56 -0700
Organization: Compilers Central
References: 23-07-003 23-07-006 23-07-008 23-07-009
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="6163"; mail-complaints-to="abuse@iecc.com"
Keywords: architecture, history, comment
Posted-Date: 17 Jul 2023 15:01:30 EDT
In-Reply-To: 23-07-009

(snip, our moderator wrote)


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


I have known for a long time that the 704 (and I believe later 7.. machines)
indexes arrays backwards, and allocates from the end of memory.


Allocating COMMON from the end of memory is convenient, in that is the
one place (other than the beginning) where you know will always by the same.


Indexing back means that it will still work, even with different length COMMON.


One Fortran feature that I only recently found out about, from 1130 ECAP,
is CALL LINK.


A program can CALL LINK(other program name), and replace itself with
another executable program. Not a subroutine call, but the whole program
is replaced in memory. But COMMON blocks are kept!


(That might be before subroutine overlay that I know well.)


By the time of OS/360, that seems to have disappeared, but a fancy
subroutine overlay system then appeared.


I any case, allocating from the end of memory, and indexing backward,
is convenient for aligning data in different whole executable programs.


Maybe they were just lucky.
[The 70x IBSYS had what they called chain jobs, same idea that the
code was overwritten but the common data stayed. The 360 linker had an
elaborate system of tree structured overlays that let you divide the
code into segments loaded automatically when the program called a
routine in the segment, again leaving whatever was in the root
segment, typically including common blocks. You can read all about it
in Chapter 8 of "Linkers and Loaders", available from better
booksellers everywhere. -John]


Post a followup to this message

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