[Tinyos-help] Code copying (generic) VS PoolC+QueueC+Code sharing
Philip Levis
pal at cs.stanford.edu
Tue Feb 12 09:18:34 PST 2008
On Feb 12, 2008, at 2:59 AM, Krisakorn Rerkrai wrote:
> Hi,
>
> I'm working on one application which probably needs a generic
> component approach.
> I'm a bit concerned about the code size generated by code copying
> method. Another
> solution I was thinking of is to use PoolC and Queue to maintain my
> attribute list and
> feed this list to a single component (code sharing approach but
> manually manages
> the attribute on the upper layer component). Which approach is a
> code optimized
> solution?
>
> I try with BlinkAppC to see how much memory code copying approach
> takes.
> I simply remove the Timer component to investigate this.
>
> BlinkAppC
> #Timers ROM RAM
> 3 2642 55
> 2 2616 45
> 1 2526 35
>
> If I look at the memory usage by each module, I can see how much
> VisualizeTimerC uses.
>
> VisualizeTimerC
> #Timers ROM RAM
> 3 448 30
> 2 422 20
> 1 320 10
>
> For RAM usage, it's clear why this is linear. However, the ROM side
> seems to use less
> memory when a generic component is used several times. Is there any
> reason behind this?
>
> Also, could somebody suggest me which approach is more efficient
> (in terms of memory usage)?
> 1. several generic modules
> 2. PoolC+QueueC+single module
Timers are generic configurations, not modules. So they don't lead to
code copying. Instead, they increase the uniqueCount() of the
underlying VirtualizeTimerC. Each Timer requires 10 bytes of state,
hence the linear increase in RAM. The increase in ROM is due to the
slow growth in length of the switch statement. The big jump from 1 to
2 would be (I'm guessing here) because you have a branch in the
handler and can't inline it as easily.
The cost of code copying is why most services are generic
configurations that sit on top of a parameterized module. That way,
you get compile-time sizing and configuration, but only one code module.
Phil
More information about the Tinyos-help
mailing list