ryer@inmet (04/21/89)
ECS Ada ISSUES WORKING GROUP PLANS FOR SUMMER '89 AdaJUG SESSION The Joint Integrated Avionics Working Group (JIAWG) has submitted seven language change requests for consideration for Ada 9X. These change requests represent some level of consensus among the developers of ATF, A-12 and LHX, but need to be analyzed by the larger embedded systems community and discussed in a more public forum. Other organizations will evaluate these language changes from a variety of viewpoints. The ECSAIWG of AdaJUG intends to provide the Ada 9X developers with an evaluation strictly from the viewpoint of suitability for real-time embedded systems. In general, the more the language changes, the longer it will take before compilers implement the new language AND provide the same level of optimization and robustness that they now exhibit. The ECS community is very sensitive to this issue, and has traditionally opposed proposals that make the language more complex unless there are very specific needs for the change to make embedded systems work. At the summer meeting of AdaJUG, ECSAIWG will conduct a two-hour session to discuss these seven change requests and make recommendations. We will not repeat the background or motivation for the changes (which have been presented repeatedly and are fully described in a paper distributed by Mike Mills of ECSPO/ATF-SPO). Instead, we will have a panel consisting of compiler developers and embedded system developers. For each issue, the compiler developers will be asked to characterize the impact of the proposed changes on compilers, specifically the size of the change (affecting robustness and schedule) and the impact if any on the generated code for related features and for code which does not use the changed feature. Then, the embedded system developers will state their positions on the changes: whether they are important to a wide range of embedded systems, whether they are worth the cost in optimization and robustness, and at what "level" the change should be made. Most of the seven JIAWG changes define a problem in the language and define or hint at multiple levels of solution. This is illustrated in the breakdown below: JIAWG CHANGE REQUESTS ANNOTATED WITH ALTERNATE LEVELS OF SOLUTION 1. "Fast Initialization" - Dynamic Priorities - Control over order of task elaboration - Elevating the priority of low-priority tasks' elaboration. 2. "Static Ragged Arrays" - "New" function processed at compilation/linking time for static data - Getting the address of any object into any access variable - Getting the address of any "safe" object into any access variable of the correct type. - Built-in support for "static ragged arrays" 3. "Non-Contiguous Arrays" - same as first three solution levels above - Built-in support for "Non-contiguous arrays" 4. "Generic I/O - Ability to treat any Ada object as an array of bits or bytes. - Adding attributes for generic parameters (such as 'contiguous) combined with more uniformity in the treatment of 'address and 'size - Specific framework for implementing avionics I/O in Ada 5."Use of Task Priorities in Select and Accept Statements" - Require this in all compilers - Make it legal, not required - Solve all priority inversion problems - Redesign, replace, or remove tasking from the language 6. "Alternative Task Scheduling" - User control over time-slicing, dynamic priorities, pre-emption - More control over starting and restarting tasks - Built-in support for rate-monotonic, cyclic processes - If major changes are needed: --- Re-design tasking as a new standard for all applications --- Specify mandatory set of alternatives and options --- Allow vendor-to-vendor variations 7. "Execution of a Unit by its Address" - With limitations needed to avoid performance loss - With limitations for strong typing, safe programming - Sufficient to allow user implementation of overlay structures For example, in item #2, "Ragged Static Arrays", the problem can be solved by adding low-level features to the language (address-to-access functions, etc.) so the user can construct the functionality himself, or by explicitly providing ragged static arrays as a language feature. If the preference is to add low-level facilities, then there are tradeoffs among safe programming, structured programming, and absolute control/flexibility. After the panel members have spoken on each issue, there will be an opportunity for embedded systems developers (only!) to add their comments from the floor. When discussion has terminated or time runs out, there will be a straw vote of the audience to establish the AdaJUG view of the importance of the change to embedded systems in general, and any preferences about the level of change that should be made. The ECSAIWG will summarize the discussions and straw votes and produce a report to be submitted to Christine Anderson (Ada 9X), JIAWG, and the AdaJUG minutes. Note that AdaJUG membership is open to anyone. The AdaJUG does focus on realtime and embedded systems. All persons with an interest in embedded systems are welcomed to attend this session. Anyone who has a strong position on one or more of these issues but is unable to attend is welcome to submit written comments to the ECSAIWG. The co-chairs of the ECSAIWG are: Mike Ryer Intermetrics Inc. 733 Concord Avenue Cambridge, Mass. 02138 (617)661-1840, ryer@inmet.inmet.com and Maretta Holden Boeing Advanced Systems PO Box 3707, MS 33-22 Seattle, Wash 98124 (206) 241-3381, mholden@ajpo.sei.cmu.edu Volunteers to help with the production of the report will be welcome. Also, there are still some spaces on the panel for compiler vendors and ECS application developers. Anyone interested in being on the panel should contact Mike Ryer at the address/number above.