On Mar 31, 2006, at 9:49 PM, Chang Li wrote:
inline will inflate code size. Look at the MSP430F1611 mote
its Code/Data Rate = FLASH/RAM Rate = 48KB / 10KB = 4.8
The FALSH/RAM Rate of tinyos applications:
Blink 2606B/40B = 65.15
SurgeTelos 17140B/670B = 25.58
SimpleCmdTelos 11516B/359 = 32.08
TOSBase 11066B/1848B = 5.99
...
The FLASH/RAM Rates of most applications are much higher than real
motes.
The aggressive inline optimization may not good at using of
resources in balance.
Or MCU makers may need to design a new one.
The FLASH/RAM ratio is pretty high; in fact, a lot of TinyOS
programming practice tends to focus on the idea of minimizing RAM
usage wherever possible, trading off for increased flash if needed.
There are a couple of reasons for this, some of them are historical,
some of them are speculative/futurist.
The earliest commonly available TinyOS nodes (rene) had 512 bytes of
RAM and 8K of flash. While RAM was tight, flash was an impossible
boundary for complex apps. The rene2 nodes increased this to 1K/16K
of flash, which eased things off a bit. Then in 2002 the micas had
128K of flash and 4K of RAM.
Some complex apps gobbled up the RAM (TinyDB and Maté are very RAM
limited), but no app ever went far above the 64K mark (some TinyDB
builds did, which caused Sam to discover and fix a bug where you
couldn't program the top 64K). The mica2 and micaZ have the same
profile. 128K was plenty, and complex apps started hovering around 50K.
The Telos revA motes had 60K of flash, and so there were no real
issues with code size. Their 2kB of RAM, though, was a harsh limit on
everyone who had become accustomed to the luxurious 4K. For example,
the early Telos versions of Maté had to provide a reduced instruction
set to minimize RAM usage.
In all of these platforms, the push in programming was to minimize
RAM consumption whenever possible. The more RAM you could leave to an
application, the better. E.g., if you left 2K to an app, that would
let it store 2K of interesting data and therefore enable new
applications. That's one reason why core systems don't really reflect
the ratio: the idea is that applications are what store the data
(RAM). That's the past.
Telos revB reversed this trend: with 48K of program memory and 10K of
RAM, programs written in styles assuming the older ratios can run
into trouble.
On to the future: one issue here is whether the MSP430 F1611 ratio
(4:1) is going to hold in the long term, or whether things will swing
back to older ratios (16:1) or even further (64:1?). If the
expectation is that in one year, the ratio will swing back,
completely revisiting all of the TinyOS programming methodologies and
re-implementing everything would be a huge waste of time. On the
other hand, if the ratio is going to stay, then revisiting all of
these assumptions could be really worthwhile. The murmurs I've heard
from the MCU world is that more program memory will be appearing
soon, while RAM won't. If that's the case, making sure people in edge
cases can tweak their performance tradeoffs (e.g., preventing
inlining of very common functions) in the present is good so there
can be forward progress, but re-implementing everything for this
temporary situation isn't a big priority, at least for me.
Phil
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
