Mentions légales du service

Skip to content

Compiler: add local variables / static local variables

Created by: vaussard

This is a reflection on local variables, anyone is welcome to join.

Local variables for events could be implemented quite easily, by extending the "temporary variables" framework. It would suffice to implement temporary variables with a life time limited to the context of the event. Two events cannot be executed at the same time, so no risk of collision. Thus these variables can be allocated at compile time.

For subroutines, things are much harder. Subroutines can be nested, thus care should be taken to allocate the "local memory" of each routine. Two options:

  • Compute the needs in space for each routine when parsing, without any allocation. Allocation can then occur when the call-graph has been resolved, as to find a suitable static memory layout preventing collisions. A dumb algorithm would be to statically allocate these variables in adjacent spaces, without taking into account call-dependencies, but memory will be under-optimized. If subroutines are not nested, this algorithm will really underperform.
  • Implement a real stack for local variables, but the current instruction set is not really suited for such operation and will lead to several bytecodes only to access one variable, thus inefficient.

As a summary, it would be easy for events, but no simple solution exits for subroutines. Would it make sense to do this only for events ?

On the other side, "static" variables could also be considered for events and subroutines. In this case, they would be allocated as regular global variables, but prefixed by a specific scope. For example, "static var foo" declared in the event "myevent" would become "_event_myevent_foo" (thus hidden in Aseba Studio). This would be quite easy to do. Aseba Studio would have to be adapted in order to unhide + remove scope prefix when debugging inside a specific scope.

As a summary, static variables would be quite easy to do, for both events and subroutines, but will forever consume the space allocated to global variables.