Re: The C Stack in interpreters - why?

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]

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