|Re: Java virtual machine as target language for C/C++ firstname.lastname@example.org (1996-05-08)|
|Re: Java virtual machine as target language for C/C++ email@example.com (Daniel C. Wang) (1996-05-27)|
|Re: Java virtual machine as target language for C/C++ firstname.lastname@example.org (Dave Love) (1996-06-13)|
|Re: Java virtual machine as target language for C/C++ email@example.com (1996-06-21)|
|Optimization of Uncommon Code (Was Java ByteCode ...) firstname.lastname@example.org (1996-06-30)|
|Re: Optimization of Uncommon Code (Was Java ByteCode ...) email@example.com (Walter Spector) (1996-07-01)|
|Re: Optimization of Uncommon Code (Was Java ByteCode ...) firstname.lastname@example.org (1996-07-04)|
|Re: Optimization of Uncommon Code (Was Java ByteCode ...) email@example.com (1996-07-05)|
|Re: Optimization of Uncommon Code (Was Java ByteCode ...) firstname.lastname@example.org (1996-07-13)|
|From:||email@example.com (Richard A. O'Keefe)|
|Date:||4 Jul 1996 15:29:50 -0400|
|Organization:||Comp Sci, RMIT, Melbourne, Australia|
|References:||96-05-061 96-05-163 96-06-048 96-06-081 96-06-152 96-07-021|
>I would say "almost all". [machines implemented Fortran locals as
"static" rather than "auto".]
One notable exception was the B6700.
>And to this day, I still wonder why.
The idea of using a stack of activation records was invented for Algol 60;
after Fortran tradition was already established. Don't forget that Fortran
was implemented on some very old machines with odd addressing. On the IBM
1130, for example, the index registers were actually memory locations, so
addressing off one of them would have been a serious hit. You will still
see the influence of old machines in the "MIX" computer used in Knuth v1..v3
(although MMIX, to be used in later volumes, will apparently be a RISC).
>really a significant performance difference in the machines of the 1960s?
For some of them, yes. For the DEC-10 and IBM 360, perhaps not, but IBM
had painted themselves into a bit of a corner: IBM Fortran code tended
to have subroutines where
- you initially called the subroutine with a bunch of parameters
- subsequent calls went via an ENTRY statement without those
- subsequent calls relied on the PARAMETERS passed in the first
call still having the old values!
I kid you not. I tried to convert such a program to the B6700, and it was
a major pain.
>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
The Fortran 66 standard went further: COMMON blocks could be stack
allocated. This was to allow data overlays as well as code overlays.
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
Return to the
Search the comp.compilers archives again.