Re: Optimization of Uncommon Code (Was Java ByteCode ...)

Walter Spector <wws@renaissance.cray.com>
1 Jul 1996 22:42:59 -0400

          From comp.compilers

Related articles
Re: Java virtual machine as target language for C/C++ kik@zia.cray.com (1996-05-08)
Re: Java virtual machine as target language for C/C++ dw3u+@andrew.cmu.edu (Daniel C. Wang) (1996-05-27)
Re: Java virtual machine as target language for C/C++ d.love@daresbury.ac.uk (Dave Love) (1996-06-13)
Re: Java virtual machine as target language for C/C++ cdg@nullstone.com (1996-06-21)
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 (Was Java ByteCode ...) ok@cs.rmit.edu.au (1996-07-04)
Re: Recursion and Code Generation on the Cybers and other stackless ma dmoisan@shore.net (1996-07-04)
Re: Optimization of Uncommon Code (Was Java ByteCode ...) grout@polestar.csrd.uiuc.edu (1996-07-05)
[4 later articles]
| List of all articles for this month |

From: Walter Spector <wws@renaissance.cray.com>
Newsgroups: comp.compilers
Date: 1 Jul 1996 22:42:59 -0400
Organization: Are you kidding?
References: 96-05-061 96-05-163 96-06-048 96-06-081 96-06-152
Keywords: optimize, Fortran, comment

David L Moore wrote:
>
> > f2c is a good case study for illustrating one type of problem with language A
> > to language B translation systems.
> >
> > [f2c makes local variables static]
> >
> 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.


> Fortran 77 introduced the "save" statement to allow the programmer
> to specify which variables should be static. Other variables can
> be static or dynamic at the choice of the compiler.


Correct. But even the FORTRAN 66 Standard allowed an implementation to use
a stack. There were explicit cautions about how data was initialized (not),
when it became defined, and undefined. The 77 and 90 Standards said similar
things.


Our moderator writes:
> [Sigh... Some years ago I wrote
> one of the earlier F77 compilers, INfort, and since it was running on a
> PDP-11 with only a 16 bit address space, I tried hard to put everything on
> the stack that I could. The customers hated it...]


Sigh. I sure wish I had your compiler in 1978/79. I also wish you'd had a
version for the CDC 6000 series. The young 'uns of today will never learn
the joys of overlaying a 1 mword program into 64 kwords.


When Cray switched our default to 'stack' many years ago, there were some
screams. But every program I looked at was trivial to fix. Some people I
know found bugs in their programs which had been there for years. The
ironic thing is that the default was not changed because of space savings -
it was changed to encourage multitasking.


What was your experience, speedwise, between stack and static modes on the
PDP-11? Other older machines?


Walt
--
Walt "Trying to imagine Fortran on a PDP-8" Spector
(wws@renaissance.cray.com)
Sunnyvale, California
[On the PDP-11, references were the same speed, procedure entry and exit each
had one added instruction for the stack adjust. Re the PDP-8, we didn't have
to imagine it. We lived it. -John]
--


Post a followup to this message

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