On Nov 15, 2004, at 12:38 AM, Leopold Toetsch wrote:
Bill Coffman <[EMAIL PROTECTED]> wrote:
[ pdd03 ]
The way I read it, paragraph one implies that when you print P5 after calling foo(), you are expecting to get the return value. You didn't save and restore register P5, so you wanted foo() to do something to it.
The nasty thing of a function call is:
i = foo() # fine P5 returned
vs.
foo() # P5 clobbered by foo
(but you can replace P5 with P15 too, or every register R5..R15)
This has never bothered me, probably because of the comparison to the register-based calling conventions that the PPC uses: A called function (which returns a value) has to store its result in some register, whether or not the caller wants it. A call like "i = foo()" is really two steps: call the function, then copy the result from r3 to the appropriate location (maybe a location on the stack, maybe another register). It may be possible to optimize so that "i" is already using the same register as the return value, but in general that can't be arranged for most cases; consider how this would compile:
i = foo() //call foo, copy result from r3 to other register--must since bar() would clobber
j = bar() //call bar, copy result from r3 to other register--could avoid copy, if j not
// needed past baz
baz(i + j) //add those two other registers into r3, and call baz
And due to the register-preservation semantics on the PPC, even a call to a void-return function could clobber r3, since it could call another function which returns a result and thus uses r3.
Not that parrot has to necessarily work this way, but it at least has precedent, so it's not totally strange behavior.
JEff
