[Tinyos Core WG] AdcConfigure and struct return

[David Gay]

On 9/21/06, Vlado Handziski <handzisk at tkn.tu-berlin.de> wrote:
> > 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).
>
> Are you referring to the module variables? The code has nothing to do with
> Jan's implementation on the msp430. I did a quick test only to double check
> the overhead that you reported because it looked incredibly large. But on
> msp430 a const goes into flash automatically, so I don't see a problem.

The C spec specifies that a variable declared on the stack only lives
until the function exits. The compiler can assume this wherever it
wishes. Assuming that some particular quirk of some particular
implementation means your code will always work is stupid. Fix: write
"static const", not "const".

For instance, I'd be rather surprised if msp430-gcc placed x in

  void g(void) {
    struct { int a; } const x = { f() };
  }

in flash. If you write static const, you'll at least get a compile-time error.

> Cool. Now we agree that it is not an issue of performance anymore, but of
> religion :)

And I'm tired of fighting stupid religous wars. Write the TEP however
you wish, and find somebody to update the atm128 code. Probably Xbow
will do it.

> As I said, it has to do with history (we have always used structs on the
> msp430, from the very first implementation) and religion,

I.e., you did it this way, so it must be the right way. So you'll
carefully define HIL so that only your way is acceptable, even though
it has no real advantage. Fine, go ahead. I'm tired of this whole
silly discussion about the purity of the way of particular ways of
expressing platform-dependent concepts.

> This being such a major issue, I invite once again all interested parties to
> participate in the HIL telecon next thursday. Hopefully we can come to some
> agreement.

I'll skip - I've had too many "angels on the head of a pin"
discussions on this topic.

David