Re: Is multi-level function return possible?

anton@mips.complang.tuwien.ac.at (Anton Ertl)
Mon, 24 Mar 2014 17:06:07 GMT

          From comp.compilers

Related articles
[23 earlier articles]
Re: Is multi-level function return possible? marcov@toad.stack.nl (Marco van de Voort) (2014-03-16)
Re: Is multi-level function return possible? news@cuboid.co.uk (Andy Walker) (2014-03-16)
Re: Is multi-level function return possible? yaldnif.w@blueyonder.co.uk (Bill Findlay) (2014-03-17)
Re: Is multi-level function return possible? anton@mips.complang.tuwien.ac.at (2014-03-18)
Re: Is multi-level function return possible? news@cuboid.co.uk (Andy Walker) (2014-03-21)
Re: Is multi-level function return possible? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2014-03-21)
Re: Is multi-level function return possible? anton@mips.complang.tuwien.ac.at (2014-03-24)
Re: Is multi-level function return possible? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2014-03-24)
Re: Is multi-level function return possible? gneuner2@comcast.net (George Neuner) (2014-03-26)
Re: Is multi-level function return possible? news@cuboid.co.uk (Andy Walker) (2014-03-26)
Re: Is multi-level function return possible? news@cuboid.co.uk (Andy Walker) (2014-03-26)
Re: history of C, was Is multi-level function return possible? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2014-03-27)
Re: Is multi-level function return possible? federation2005@netzero.com (2014-03-26)
[2 later articles]
| List of all articles for this month |

From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.compilers
Date: Mon, 24 Mar 2014 17:06:07 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 14-03-020 14-03-022 14-03-025 14-03-030 14-03-044 14-03-046 14-03-047 14-03-048 14-03-053
Keywords: design, history, comment
Posted-Date: 24 Mar 2014 15:43:04 EDT

Andy Walker <news@cuboid.co.uk> writes:
>On 18/03/14 17:36, Anton Ertl wrote:
>> Keeping a feature may just be loyalty, but adding it back after it had
>> been removed says something about what the language designer thought
>> about the usefulness of the feature.
>
> Well, it certainly implies that the designer [or the committee!]
>is admitting to a mistake.


In the case of the C branch of the Algol family, I very much doubt
that the designers see it that way. B had a reduced feature set not
because the language designer did not like the features they removed,
but because B had to work on a very small machine. They added some
features back in C, which ran on larger machines. The designers of
C++, Java and C# are different persons than the designers of B and C,
so if they add a feature, why would they see it as "admitting to a
mistake"?


>[...]
>> "Parameters have a run-time cost": So has access to non-local
>> variables.
>
> That depends on the machine and compiler. The first compiler I
>used extensively [for Atlas Autocode] accessed variables at lexical
>depth N by offsetting from register N, so all variables were accessed
>at exactly the same cost.


So this compiler maintained a display in the registers. The costs here are:


1) Accessing the variable in memory, whereas a parameter can be passed
in a register and accessed in a register.


2) Maintaining the display. AFAIK it turned out that maintaining the
display is more costly in typical uses than the access cost it saves,
so displays fell out of favour. This means that the run-time cost of
non-local variables is typically even more costly on this
implementation than one an implementation going using static link
chains.


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/
[We do forget that Ritchie's C compiler ran in 12K bytes of RAM,
two passes plus assembler, and generated quite respectable code
for the PDP-11. -John]


Post a followup to this message

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