Re: Optimization of Uncommon Code

Dwight VandenBerghe <>
2 Jul 1996 22:49:57 -0400

          From comp.compilers

Related articles
Re: Java virtual machine as target language for C/C++ (1996-05-08)
Re: Java virtual machine as target language for C/C++ (Daniel C. Wang) (1996-05-27)
Re: Java virtual machine as target language for C/C++ (Dave Love) (1996-06-13)
Re: Java virtual machine as target language for C/C++ (1996-06-21)
Optimization of Uncommon Code (Was Java ByteCode ...) (1996-06-30)
Re: Optimization of Uncommon Code (Was Java ByteCode ...) (Walter Spector) (1996-07-01)
Re: Optimization of Uncommon Code (Dwight VandenBerghe) (1996-07-02)
Re: Optimization of Uncommon Code (1996-07-03)
Re: Optimization of Uncommon Code (Jerry Leichter) (1996-07-03)
Re: Recursion and Code Generation on the Cybers and other stackless ma (1996-07-04)
Re: Optimization of Uncommon Code (Walter Spector) (1996-07-09)
Re: Optimization of Uncommon Code (1996-07-10)
Re: Optimization of Uncommon Code (1996-07-13)
| List of all articles for this month |

From: Dwight VandenBerghe <>
Newsgroups: comp.compilers
Date: 2 Jul 1996 22:49:57 -0400
Organization: Pentasoft Corporation
References: 96-05-061 96-05-163 96-06-048 96-06-081 96-06-152 96-07-021
Keywords: Fortran, optimize

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.

Remember that by far the dominant machine of the 60's was the IBM 360,
which had no stack. The Xerox Sigma series duplicated the instruction
set and added a stack, but it saw little use outside academia. The
RCA Spectra 70 had interesting modes and switching, but still no stack,
as I recall. Subroutine linking was done via the BALR 14,15 instruction
(or something like that) which placed the return address into a register
and branched to the routine. It was the called routine's responsibility
to save the return address off and retrieve it when necessary. Recursion
was nearly impossible, without paying a severe performance penalty. It
is difficult now to describe those days, especially for those who have
been bred on superfast machines on their desks. Every cycle counted.
The cost of the machine was something like 100x the cost of the programmer,
so you did everything you could to make things run fast. Main memory
was 32K, or 64K, or maybe if you were really lucky, 128K. It was a big
deal to get everything you could into memory at once; you spent a lot of
your time figuring out overlay schemes and crunching your routines down
to be smaller. So the idea of setting up your own stack and using it
for arguments (instead of registers) and return values, was considered
academic at best. You'd have been laughed out of industrial Dodge for
attempting such a thing. My first fully recursive system was a modelling
language called SimScript, and was it beautiful ... !! It felt like
freedom, like coming out into the light. But it was too slow for real
(production) work, of course. I played with it on the weekends, after
the normal shifts had gone home. Early nerd heaven.

I got a million stories like this. Sitting here on my rocker, on the
ol' porch, teeth in the jar by the bed, watching the sun set and playing
checkers, petting ol' yeller here at my side ... these kids nowadays
don't know what real bit-twiddling is, do they, Amos? :)

[Actually, it's not hard to do a reasonable stack-based calling sequence on
a 360, although you wouldn't know it from some of the brain damaged code
emitted by early Algol and PL/I compilers. (The original IBM Algol compiler
did a GETMAIN system call on every procedure call. Yow.) I think the
problem is much more cultural, the Fortran compilers for the 70XX machines
did all static allocation, code was already breaking badly with the change in
word size, who needs more trouble changing the storage allocation scheme.
-John, who used to toggle programs into his PDP-8 without looking at the
reference card.]


Post a followup to this message

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