[Tinyos Core WG] AdcConfigure and struct return

[David Gay]

On 9/21/06, Vlado Handziski <vlado.handziski at gmail.com> wrote:
> On 9/20/06, David Gay <dgay42 at gmail.com> wrote:
> > [Results at end. Summary: runtime cost is 5x slower for Read.read, a
> > 370 byte code increase and some RAM cost]
>
> This is strange. See below...

You returned pointers to structures, not the structures themselves. I
used structures rather than pointers to const structures, because
that's more comparable to what you get from separate commands - see
discussion at end. In theory, a compiler could do just as good a job
with all three approaches; in practice the order is "commands - const
structures pointers (similar) - structures (a lot worse)".

Btw, your code is buggy, because you returned a pointer to a local
variable - I hope you're using static on the msp430 for your
equivalent code (no, there's no realistic guarantee that some future
version of gcc won't break it w/o the static).

> > the code that uses this from
> >   uint8_t channel() {
> >     return call Atm128AdcConfig.getChannel[client]();
> >   }
> >   uint8_t refVoltage() {
> >     return call Atm128AdcConfig.getRefVoltage[client]();
> >   }
> >   uint8_t prescaler() {
> >     return call Atm128AdcConfig.getPrescaler[client]();
> >   }
> >   void sample() {
> >     call Atm128AdcSingle.getData(channel(), refVoltage(), TRUE,
> prescaler());
> >   }
> >
> > to:
> >   uint8_t channel() {
> >     return (call
> Atm128AdcConfig.getConfiguration[client]()).channel;
> >   }
> >   uint8_t refVoltage() {
> >     return (call
> Atm128AdcConfig.getConfiguration[client]()).refVoltage;
> >   }
> >   uint8_t prescaler() {
> >     return (call
> Atm128AdcConfig.getConfiguration[client]()).prescaler;
> >   }
> >   void sample() {
> >     call Atm128AdcSingle.getData(channel(), refVoltage(), TRUE,
> prescaler());
> >   }
>
> Why do you insist on keeping the 3 calls?

Why not (I found the code more readable that way) ? With inlining, one
would hope the optimiser wouldn't care (and in fact it doesn't - those
small functions are inlined.

Anyway, with the structures in flash, and returning a pointer to
flash, the code overhead is 60 bytes and the cycle overhead is 30,
which isn't too bad.

But: I see very little point in doing this. We now have an interface
which has a single command which returns an opaque value (except for
platform-dependent code). This is no more portable or
hardware-independent than an interface with opaque commands.

Additionally, it's not really more flexible: you trade off the ability
to pass around to play with these opaque values in C code (I suppose
you could pick different configurations based on some runtime option,
though you could still do something very similar with parameterised
interfaces). You lose the option of getting configuration values in
more interesting ways (all those configuration structures have to be
compile-time constants if you want reasonable code).

For instance, the current photo sensor's channel is defined as:
  async command uint8_t Atm128AdcConfig.getChannel() {
    return call PhotoAdc.getChannel();
  }
where PhotoAdc is connected to a per-platform configuration component
which specified mapping of the mica bus adc channels to the particular
platform's adc channels.

To do this with configuration structures, we'd have to use constants
instead (possible, of course).

David