Re: Optimization of Uncommon Code

rweaver@ix.netcom.com (Richard Weaver )
3 Jul 1996 10:36:37 -0400

          From comp.compilers

Related articles
Re: Java virtual machine as target language for C/C++ kik@zia.cray.com (1996-05-08)
Optimization of Uncommon Code (Was Java ByteCode ...) dlmoore@ix.netcom.com (1996-06-30)
Re: Optimization of Uncommon Code (Was Java ByteCode ...) wws@renaissance.cray.com (Walter Spector) (1996-07-01)
Re: Optimization of Uncommon Code dwight@pentasoft.com (Dwight VandenBerghe) (1996-07-02)
Re: Optimization of Uncommon Code rweaver@ix.netcom.com (1996-07-03)
Re: Optimization of Uncommon Code leichter@smarts.com (Jerry Leichter) (1996-07-03)
Re: Optimization of Uncommon Code wws@renaissance.cray.com (Walter Spector) (1996-07-09)
Re: Optimization of Uncommon Code mac@coos.dartmouth.edu (1996-07-10)
Re: Optimization of Uncommon Code creedy@mitre.org (1996-07-13)
| List of all articles for this month |

From: rweaver@ix.netcom.com (Richard Weaver )
Newsgroups: comp.compilers
Date: 3 Jul 1996 10:36:37 -0400
Organization: Compilers Central
References: 96-05-061 96-06-152 96-07-021
Keywords: optimize, Fortran, history

Walter Spector wrote:


> > This used to be a common misconception - that locals in Fortran were
> > static and therefore retained their values from one call of a
> > procedure to the next. This was how Fortran was implemented on
> > some early machines.
> ^^^^
> I would say "almost all". And to this day, I still wonder why. Was there
> really a significant performance difference in the machines of the 1960s? I
> can think of cases where stack mode could create *faster* code than static
> mode. But admittedly modern hardware is in use.


You have the wrong decade, it was the 1950s that were different. In what
follows I've made no attempt to locate correct details as to when Fortran
acquired various features (e.g. subroutines) nor to distinguish between 704,
709, etc. implementations, as that work would not contribute to the core of
this response.


The first implementation of Fortran was on the IBM 704. It had index
registers but not 'base' registers, machine instructions contained the
absolute address, possibly indexed, of data. The implementation of argument
passing was that, on entry to a subroutine/function, initialization code
would insert the argument addresses passed into each instruction referencing
those arguments. Note "each", could take a while for routines with lots of
references to their arguments and this occurred on every invocation.


Users discovered that programs could be organized to avoid this overhead, by
keeping arguments in the same (static) locations and having an initial
invocation that was passed all arguments, thus filling in all addresses, and
on later invocations specifying no arguments.


A routine have 3 invocations, such as


              CALL X (A)
              CALL Y (B)
              CALL Z (C)


acquired a 4th invocation and the existing 3 lost their argument specification


              CALL FIRST (A,B,C) Call once, at beginning of MAIN.
              CALL X
              CALL Y
              CALL Z


Since the CALL FIRST had inserted the address of A,B,C into the instructions
referencing them, the later calls needed no arguments -- the addresses were
already in place!


Thus "parameter persistence" came into being. And Fortran code came into
being that was dependent on parameter persistence. So when new Fortrans were
implemented on new architectures ("stack", for example) those new Fortrans,
desiring to run existing Fortran programs, implemented parameter
persistence. And when still newer Fortrans were implemented ....


Hope this helped
Dick W
[This revolting technique was still a win in 360 Fortran due to its slow
copy in/copy out argument passing. -John]


--


Post a followup to this message

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