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

ok@cs.rmit.edu.au (Richard A. O'Keefe)
4 Jul 1996 15:29:50 -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 (Was Java ByteCode ...) ok@cs.rmit.edu.au (1996-07-04)
Re: Optimization of Uncommon Code (Was Java ByteCode ...) grout@polestar.csrd.uiuc.edu (1996-07-05)
Re: Optimization of Uncommon Code (Was Java ByteCode ...) dlmoore@ix.netcom.com (1996-07-13)
| List of all articles for this month |
From: ok@cs.rmit.edu.au (Richard A. O'Keefe)
Newsgroups: comp.compilers
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
Keywords: optimize, Fortran

>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).


>Was there
>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
parameters
- 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
>things.


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.
--


Post a followup to this message

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