Related articles |
---|
Re: Java virtual machine as target language for C/C++ kik@zia.cray.com (1996-05-08) |
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 wws@renaissance.cray.com (Walter Spector) (1996-07-09) |
Re: Optimization of Uncommon Code mac@coos.dartmouth.edu (1996-07-10) |
Re: Optimization of Uncommon Code creedy@mitre.org (1996-07-13) |
From: | Walter Spector <wws@renaissance.cray.com> |
Newsgroups: | comp.compilers |
Date: | 9 Jul 1996 13:29:59 -0400 |
Organization: | Are you kidding? |
References: | 96-05-061 96-06-152 96-07-021 96-07-032 |
Keywords: | code, history, comment |
> Walter Spector wrote:
> > Was there
> > really a significant performance difference in the machines of the 1960s?
Richard Weaver wrote:
> You have the wrong decade, it was the 1950s that were different...
> The first implementation of Fortran was on the IBM 704.
> ...
> The implementation of argument
> passing was that, on entry to a subroutine/function, initialization code
> would insert the argument addresses passed into each instruction referencing
> those arguments. Note "each", could take a while for routines with lots of
> references to their arguments and this occurred on every invocation.
YUCK!!!
Why was the address not simply added to the index at run-time
when needed? Shortage of registers? (I'm thinking about that
PDP-8 again...)
[The 704 had more registers than the PDP-8, but still pretty tight. -John]
> Users discovered that programs could be organized to avoid this overhead, by
> keeping arguments in the same (static) locations and having an initial
> invocation that was passed all arguments, thus filling in all addresses, and
> on later invocations specifying no arguments.
> [This revolting technique was still a win in 360 Fortran due to its slow
> copy in/copy out argument passing. -John]
I've seen this technique used on code ported Univac systems.
In one of my old Univac manuals, this is actually a documented
technique! I thought maybe this was an early attempt at 'object
oriented' programming!
Dwight VandenBerg writes:
> 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...
I think where the boat was really missed was with placing local data
arrays on a stack (though it sounds like Burroughs saw the light...)
Recursive calls were not needed and only confused the issue!
Jerry Leichter writes:
> The procedure call on the 6600 saved the return address *at a fixed location
> in memory*.
Yes, the RJ instruction was the single blot in the otherwise
beautiful RISC instruction set. The compilers did support an
'unsafe' calling sequence which simply stored the return address
in a register, then branched to the subroutine. On return one
would perform an indirect jump back. Fast and no memory references!
Walt
--
Walt Spector
(wws@renaissance.cray.com)
Sunnyvale, California
[This is wandering off into computer architecture history, so this thread
is ended unless someone can drag it back into the compilers realm. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.