[Tinyos-devel] call-by-value vs. -pointer

[Jan Hauer]

In my situation the call is split-phase (request->confirm), and with
the standard TinyOS semantics the caller would have to guarantee that
the pointer is valid until the confirm event. But in contrast to the
Send interface, the caller is not interested in getting the parameters
back, because they carry only control information for this particular
call (e.g. address/status information). What the caller actually wants
is call-by-value semantics - but the list of arguments is long...
Forcing the caller to guarantee that these parameters are valid until
the confirm event means that the caller must allocate them as global
(module) variables. And, because the caller can have multiple
outstanding requests it would even have to allocate multiple parameter
sets.

With msp430-gcc if the parameters can fit in 4 registers (total of 8
byte) then they are passed through registers, otherwise they are put
on the stack. I just did a quick check and compared the codesize when
I pass 16 byte by value vs. by pointer, and the difference is small
(30 byte, when the app calls the command from two different places),
compiled with -Os. I'm not sure how it would look like on other
platforms, though.

Jan


On Thu, Jun 12, 2008 at 8:09 PM, Philip Levis <pal at cs.stanford.edu> wrote:
>
> On Jun 12, 2008, at 7:12 AM, Jan Hauer wrote:
>
>> I'd like to hear people's opinion about passing
>> command-/event-parameters by pointer vs. by value, in a situation
>> where you would like to use call-by-value semantics, but the number of
>> arguments / their total size is big. Background: some of the 802.15.4
>> management primitives use a lot of parameters (in some situations 7
>> parameters with a total of 25 byte) and there is generally a
>> perfomance penalty when passing them by value over the stack (more
>> code size, slower execution). One alternative is that the caller
>> encapsulates the parameters in a struct and passes a pointer to it.
>> The drawback is that one needs an agreement about when/how long the
>> pointer is valid. When you have written the callee component yourself
>> you can make sure that you keep no reference after the return
>> statement, but when you cannot control the callee (e.g. signal an
>> event to some app) passing a pointer can be problematic. As long as
>> the interfaces are not used very frequently, I tend to prefer the
>> call-by-value approach even if a long list of parameters is passed -
>> what do other people think?
>
> With the exception of allocators, TinyOS semantics tend to be:
>
> For single-phase calls, ownership of a pointer is granted to the callee and
> given back to the caller when the call returns. (e.g., Packet)
>
> For split-phase calls, when ownership of a pointer is granted to the callee
> and given back to the caller when the completion event is signaled, the done
> event passes the pointer. (e.g., Send)
>
> I can't think of any interfaces off the top of my head which are split-phase
> yet return ownership of the pointer when the command returns/
>
> Phil
>
>
>