Re: The C Stack in interpreters - why?

nmm1@cus.cam.ac.uk (Nick Maclaren)
16 May 2005 11:18:49 -0400

          From comp.compilers

Related articles
[8 earlier articles]
Re: The C Stack in interpreters - why? Marko.Makela@HUT.FI (Marko =?ISO-8859-1?Q?M=E4kel=E4?=) (2005-05-14)
Re: The C Stack in interpreters - why? marcov@stack.nl (Marco van de Voort) (2005-05-14)
Re: The C Stack in interpreters - why? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2005-05-15)
Re: The C Stack in interpreters - why? gene@abhost.us (Gene Wirchenko) (2005-05-15)
Re: The C Stack in interpreters - why? nmm1@cus.cam.ac.uk (2005-05-15)
Re: The C Stack in interpreters - why? gneuner2@comcast.net (George Neuner) (2005-05-16)
Re: The C Stack in interpreters - why? nmm1@cus.cam.ac.uk (2005-05-16)
Re: The C Stack in interpreters - why? scooter.phd@gmail.com (scooter.phd@gmail.com) (2005-05-18)
| List of all articles for this month |

From: nmm1@cus.cam.ac.uk (Nick Maclaren)
Newsgroups: comp.compilers
Date: 16 May 2005 11:18:49 -0400
Organization: University of Cambridge, England
References: 05-05-072 05-05-073 05-05-084 05-05-112 05-05-128
Keywords: C, architecture
Posted-Date: 16 May 2005 11:18:49 EDT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
|>
|> Few of the Cambridge compilers used standard linkage (this was back in
|> the BAL/BALR days), on the grounds of unsuitability and cost, though
|> they almost all used BAL/BALR. I did some testing, and found some
|> advantages in not even using them (i.e. using LA and BC), as was done
|> by some specialist assemblers, but never saw a genuine compiler use
|> that method.
|>
|> [Gee, I always liked ATTACH because then you could have race
|> conditions. So, speaking of obsolete, let me take a look, on a /30
|> BALR took 18us, BR took 9, LA took 17, so BALR won there. On a /67,
|> BALR was 1.2us, BASR was 1.43us, BR 1.1us, LA 0.9us. BALR and BASR
|> still won. -John]


Excessively naive calculation. 2/10 :-)


My tests were on a 370/165, but the principles were more general,
and the gain of LA/BC was not direct but in the extra flexibility
that it allowed. Yes, simply replacing BALR/BAL by LA/BR/B was a
loser, but that was obviously unlikely to help. There was the
obvious one that it gave better code generation to tail recursion
removal and common constructions like:


        IF (JOE) CALL FRED
        x = (bert ? 1.23 : alf());


But it also simplified the generation of inline parameter lists
(whether of arguments or debugging information), with the resulting
improvement in cache and (more importantly) TLB utilisation. Note
that allowing WRITABLE data there was always a loser. I did some
investigations on the Fortran linkage, and could speed it up by a
factor of 2-3 just by cleaning it up and designing it for 1970s
systems.


Regards,
Nick Maclaren.
[Cache? TLB? Tail recursion? You didn't say you were using all
that newfangled stuff. Time to retire under my rock, now. -John]



Post a followup to this message

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