Implementation Aspects

 general design principles followed when designing the architecture for the AOCS Framework are discussed under the following headings:

• Implementation Language
• Use of Parasoft CodeWizard
• Framework Overheads
• Testing Configuration

• Back to AOCS Project Home Page

Implementation Language

In order to ensure compatibility with the real-time environment in which the framework is expected to be used, only a subset of the C++ features were used. More specifically, the following features were not used:

• exception handling
• multiple inheritance of implementation (see also discussion on MI)
• run-time type information
• unsafe type casting (except in wrappers that are specifically designed to safely handle this type of casting)
• operator overloading

In order to eliminate the danger of "dangling pointers", complex objects (ie objects that are directly or indirectly derived from class AocsObject) are never destroyed until application termination. This restriction also applies to object destruction on the stack. One implication is therefore that such objects are never passed by value in method calls. Only pointers to objects are passed as method parameters, never the object themselves. This guarantees that references to objects remain always valid.

Compliance with the rules forbidding dynamical destruction of complex objects is ensured by having the destructor of class AocsObject raise a failure event if it is ever executed. In a more radical approach, one could make the destructor private which would ensure that the compiler detects any attempt to destroy an object dynamically. This was not done in the framework prototype because of interference with the testing programs.

Back to Top, Back to Aocs Framework Project Home

Use of Parasoft's Code Wizard

Back to Top, Back to Aocs Framework Project Home

Framework Overheads

• overheads due to dynamic binding
• framework-specific overheads

• Dynamic binding introduces an additional layer of indirection and therefore slows down application execution. The overhead in a call to a dynamically bound method with respect to a call to the same method when it is statically bound is roughly equivalent to the overhead of having one extra parameter in the method call. The only study to have tried to quantify this type of overhead seems to be K. Driesel in: The Direct Cost of Virtual Function Calls in C++ (ACM Sigplan Notices, Vol. 31, n. 10, Oct. 1996) that puts its average value at about 5%.
• Dynamic binding also has an impact on memory usage which consists in a virtual function table to be created for every class that declares virtual methods, and a pointer to the virtual function table to be added to every instance of such classes. See D. Herity, C++ In Embedded Systems: Myth and Reality (Embedded Systems Magazine, Feb. 1998) for a technical discussion.

The memory overhead is simply given by the memory occupied by the functionality managers which represents the ballast that the framework introduces at application level. With the configuration used for the AOCS framework prototype this is equal to just over 60 kBytes (including both code and data). Since a typical AOCS application might occupy around 400-600 Kbytes, the framework memory overhead is around 10-15%.

CPU overheads can be established by measuring CPU usage when the functionality managers run “empty” (ie. no components plugged into them). In the AOCS framework prototype, an empty cycle takes 0.2 ms with the SPARC processor running at 14 MHz. Since typical AOCS cycles last 100 ms or more, the framework-induced CPU overhead is nearly negligible.

Back to Top, Back to Aocs Framework Project Home

Testing Configuration

Back to Top, Back to Aocs Framework Project Home