Re: Return value address

"Christoph Neubauer" <>
21 Sep 2004 22:17:25 -0400

          From comp.compilers

Related articles
Return value address (2004-09-07)
Re: Return value address (Christoph Neubauer) (2004-09-08)
Re: Return value address (2004-09-13)
Re: Return value address (2004-09-14)
Re: Return value address (Christoph Neubauer) (2004-09-21)
Re: Return value address (2004-09-21)
| List of all articles for this month |

From: "Christoph Neubauer" <>
Newsgroups: comp.compilers
Date: 21 Sep 2004 22:17:25 -0400
Organization: Siemens AG Austria
References: 04-09-054 04-09-069 04-09-100
Keywords: code
Posted-Date: 21 Sep 2004 22:17:25 EDT

"Nicola Musatti" <> wrote in message
> "Christoph Neubauer" <> wrote
> > What about a stack model, that allocates:
> >
> > r allways at 0
> > arguments starting at 4
> > local variables afterwards
> > temp variables afterwards
> In my ignorance I thought that just about every compiler worked in
> this way, except maybe when return value and arguments are directly
> allocated into registers. Are there reasons to do otherwise?

Hi Nicola !

I don't know many different compilers and/or stack models.
All of them return function result either on '0' or in register(s).
Further I don't know any reason to do it some other way.

> > [It also seemed to me that the obvious solution is for the caller to
> > allocate the return value cell. -John]
> Wouldn't this also give the opportunity to optimize it away, e.g. by
> directly using the variable to which the function result is assigned?

As I see it:: No.
If you generate code for a certain function, you don't know anything
about the 'dynamic surrounding', where the function is called from !
(Despite some knowledge/optimizations for recursive calls)

What you (maybe ?) could do is:
Pass the address of the variable to the function call (as hidden argument)
Use this address for -indirect- assignment of the result.
--> No performance win at all

Kind regards,

Post a followup to this message

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