Hi Berwyn,
> 1. Atomic access (see 3.8.1.2). It sure would be nice if the critical keyword
> worked on variable
> declarations. It would make access to the variable atomic. For example, a
> typical timer interrupt
> would run a long msec counter, and main() would check it to see if >1000 ms
> had been added.
> Since you can't access a long atomically, right now you'd have to do critical
> { if (msec>end)
> second(); }. That would at least prevent false triggers due to partial
> addition overflow. (BTW: it
> would be even worse than this because you probably don't want to run second()
> in a critical
> section.) But if the compiler knew you wanted access to that variable to be
> atomic, it could easily
> do critical { msec>end } for you.
I would not implement this as
critical { msec>end }
but instead
critical { temp=msec;} if (temp>end) ...
It gets tricky however when doing msec++ or msec+=10.
> 2. A huge, fool-proof enhancement on this would be to make the linker warning
> if a variable was
> not declared as critical but it is >8 bits or in xram and if it is accessed
> both in and out of an
> interrupt routine.
The fact that a variable is in xram is not enough to cause atomicity
problems. Only if it is used in a read-modify-write operation it
will. And most read-modify-write operations are non-atomic for
variables in other memories too.
> This would require that the compiler keep track of what functions interrupt
> routines call (and, I guess, some sort of "used by interrupt" flag for each
> function in the object
> file). BTW: it would be nice if the compiler could add the modifier keywords
> automatically, but if
> the project is multi-file, it won't know until after link.
After linking it is too late to change the code.
> I know that keeping track of which functions are called by interrupts is
> quite significant to-do, but it
> would make using interrupt routines non-dangerous. There is a precedent for
> this: the Keil
> compiler warns about functions called inside and out of interrupt routines.
>
> 3. It is also very tricky for the programmer to remember to use the #pragma
> nooverlay modifier on
> all functions called by interrupt routines, and tricky to remember to use the
> reentrant keyword on
> functions called both in and out of interrupt routines. If the
> compiler/linker keeps track of which
> functions call which functions per the enhancement above, then it could also
> warn if nooverlay or
> reentrant modifiers are required.
If the linker could build and analyze the call tree it could set
nooverlay itself or better only overlay where it does no harm. The
total overlay scheme could improve significantly. It could also warn
about needed reentrancy.
> Any discussion on these ideas? Point 1, at least, could be done relatively
> easily, I suspect. Just
> seems like the kind of bug that easily happens and could be prevented
> automatically.
>
> - Berwyn
>
> --
>
> Berwyn Hoyt, Senior Hardware Engineer: [EMAIL PROTECTED]
> Ph: +64 3 359 2101; Mobile: +64 21 045 7830
> Brush Technology: www.brush.co.nz
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
