|Re: Java virtual machine as target language for C/C++ email@example.com (1996-05-08)|
|Re: Java virtual machine as target language for C/C++ firstname.lastname@example.org (Daniel C. Wang) (1996-05-27)|
|Re: Java virtual machine as target language for C/C++ email@example.com (Dave Love) (1996-06-13)|
|Re: Java virtual machine as target language for C/C++ firstname.lastname@example.org (1996-06-21)|
|Optimization of Uncommon Code (Was Java ByteCode ...) email@example.com (1996-06-30)|
|Re: Optimization of Uncommon Code (Was Java ByteCode ...) firstname.lastname@example.org (Walter Spector) (1996-07-01)|
|Re: Optimization of Uncommon Code email@example.com (Dwight VandenBerghe) (1996-07-02)|
|Re: Optimization of Uncommon Code firstname.lastname@example.org (1996-07-03)|
|Re: Optimization of Uncommon Code email@example.com (Jerry Leichter) (1996-07-03)|
|Re: Optimization of Uncommon Code (Was Java ByteCode ...) firstname.lastname@example.org (1996-07-04)|
|Re: Recursion and Code Generation on the Cybers and other stackless ma email@example.com (1996-07-04)|
|Re: Optimization of Uncommon Code (Was Java ByteCode ...) firstname.lastname@example.org (1996-07-05)|
|[4 later articles]|
|From:||Walter Spector <email@example.com>|
|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
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 "Trying to imagine Fortran on a PDP-8" Spector
[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]
Return to the
Search the comp.compilers archives again.