(I have a habit of writing one long e-mail when multiple short one
might be better; please note that some issues are almost too trivial
to have included here but I wanted to report back as much detail on
all issues I have learned while studying TinyOS the last 2 days.)
I haven't done complete due diligence yet (however, I did read the
2000+ mailing list posts the other night before finally diving in ;-)
but I wanted to give a "heads up" ASAP. I do not consider this a
complete analysis or report but hopefully it will have some value.
Current issues seen on i386-*-freebsd4.8 (compiling to native
i.e. `pc' code):
- I had to patch a system header to avoid this construct used in
exactly one place in <stdio.h>: __attribute__((__format_arg__(2)))
I began to study how to support that in the nesc parser but decided I
was out of my element (adding the rule to capture the situation in the
parser was easy but that didn't appear to be enough).
- I have the non-portable patch to disable steps in tools/avr-as
(comment out `avr-as' in SUBDIRS in tools/Makefile). In the current
FSF gcc tree, we'd handle this with a target-keyed configuration. I'd
be happy to submit a proper patch if/when other target CPUs are possible.
- When nesc-1.1beta1 was compiled with gcc 3.2.3, it produced a stable
system (when that later TinyOS system was built with 3.2.3). For the
record, the bison 1.28 generated parser files were used.
When nesc-mainline CVS was compiled with gcc 3.2.3 (or recent gcc
mainline, for that matter), it produced an unstable system (when that
later TinyOS system was built with 3.2.3). There were exactly 5 bytes
difference in the final binary (same delta pattern in all case; exact
ripple not debugged yet) but the middle C was different in other
details (appears to resolve more symbols to values during the nesc
phase; I suspect some resolutions are wrong, see next issue). bison
1.75 generated files were used.
When nesc-mainline was compiled with gcc ~2.95.4, (I think) it
produced a stable system (when that later TinyOS system was built with
gcc 3.2.3). bison 1.75 generated files were used.
In my capacity as an FSF gcc maintainer, I intend to get to the bottom
of this issue. Especially if it is believed to be a gcc issue not a
NesC issue.
- Another, (related?) quirk seen on nesc-mainline with both linux &
freebsd (various gcc versions, i.e. I don't think it is related to
using the outdated "2.96" on RH 7.2), in the generated code for
e.g. Bombilla:
enum __nesc_unnamed4355 {
TIMER_REPEAT = 0,
TIMER_ONE_SHOT = 1,
NUM_TIMERS = 4
};
[...]
struct TimerM$timer_s {
uint8_t type;
long ticks;
long ticksLeft;
} TimerM$mTimerList[1000][0];
^ should be NUM_TIMERS
This causes an insidious memory corruption (on linux, I saw random
hangs and misbehaviors; on freebsd, the mutex library happen to report
the trashing it had received, due to the luck of the memory layout).
It appears that uniqueCount("Timer") obtains the correct value in
tos/interfaces/Timer.h but not in some other contexts, where the
NUM_TIMERS, etc. macros are expanded. I'm sorry if this root issue is
something trivial and I missed the dependency. Since this was beyond
my ability to fix at the moment, I unrolled the recent patch that
conditionally set NUM_TIMERS to uniqueCount("Timer").
- Switching gears: I'd have a few general, trivial Makefile
portability patches to TinyOS itself (since people didn't appear to
post them to these discussion lists, I will wait to hear back). Other
than that, I believe I have Mate and many other TinyOS examples
working properly in native simulation on i386-*-freebsd4.8. Really
good work is TinyOS---Thank you all for sharing it. Now, onto a port
to the [MC68]HC[S]08[GB60] as a target... (I already have lined up
permission to return that work, if it would be of general interest.)
Regards,
Loren
_______________________________________________
Tinyos-users mailing list
[EMAIL PROTECTED]
http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-users
