[Avrora] Extending avrora

[Ben L. Titzer]

On Sep 14, 2005, at 2:46 AM, Torsten Landschoff wrote:

> Hi folks,
>
> I'd like to thank you for the beautiful simulator that you have  
> written
> with avrora!! It's a great pleasure to work with it.
>
> I am currently using it for my diploma thesis which is about  
> security in
> wireless sensor networks. In trying to hash the whole flash memory  
> I am
> running into an exception because I access flash memory which is not
> covered by my program.
>
> Currently I am working around this by the following trivial patch:
>
> === src/avrora/sim/mcu/ReprogrammableCodeSegment.java
> ==================================================================
> --- src/avrora/sim/mcu/ReprogrammableCodeSegment.java    (revision  
> 2623)
> +++ src/avrora/sim/mcu/ReprogrammableCodeSegment.java    (local)
> @@ -83,7 +83,7 @@
>          public CodeSegment newCodeSegment(String name,  
> BaseInterpreter bi, ErrorReporter er, Program p) {
>              CodeSegment cs;
>              if ( p != null ) {
> -                cs = new ReprogrammableCodeSegment(name,  
> p.program_end, bi, er, pagesize);
> +                cs = new ReprogrammableCodeSegment(name, size, bi,  
> er, pagesize);
>                  cs.load(p);
>              } else {
>                  cs = new ReprogrammableCodeSegment(name, size, bi,  
> er, pagesize);
>

Ah, yes--I remember this problem coming up when I implemented  
ReprogrammableCodeSegment, and the reasoning is just as you pointed  
out; for a large sensor network, saving memory by not allocating all  
the flash memory was important; also, the startup cost of creating a  
new node is lower because the allocated array is smaller and  
initializing it therefore faster.

There were a number of alternatives that I considered, but eventually  
settled on the way it is because basically it is the simplest  
(Occam's razor to the rescue). One way would be to increase the  
smarts of the Segment class so that it would detect out of bounds  
accesses and return the default value, but these extra checks  
introduce some performance overhead; another way would be to have a  
two-level array like a page table so that parts of the memory that  
have not been accessed yet are not allocated, but then each access is  
slower as well; the third would be to just always allocate the entire  
segment.

When we consider adding instrumentation to a segment, then things get  
a bit more complex. One issue that there are now two types of access  
to the segment; accesses by the program (that should trigger  
instrumentation) and accesses by the instrumentation (which should  
not trigger instrumentation). Thus the get() vs read() methods were  
born. An out-of-bounds access by the program usually returns a  
default value when run on the hardware, but on the simulator it  
generates a warning and the program continues. An out-of-bounds  
access by instrumentation in the simulation is really an  
instrumentation error and generates an exception.

I'd like to clean up the current situation a little bit but haven't  
settled on the best solution. I am working on (re)generating the  
interpreter (both an AVR interpreter and an MSP interpreter) from a  
specification, and I am thinking of changing the implementation of  
the CodeSegment to allocate an array that is indexed by word address  
rather than byte address. Since accesses to the code should always be  
aligned, this will save 1/2 of the space for the code segment and  
hopefully result in slightly better performance (due to better cache  
usage).

For your situation I would suggest that you catch the  
AddressOutOfBoundsException which should be generated by an out-of- 
bound access and then use the default value.

Hope this helps.

-B

========================================================
The first principle is that you must not fool yourself--and you are  
the easiest person to fool.
--Richard Feynman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucla.edu/pipermail/avrora/attachments/20050914/f5e89d44/attachment.html