Updates on the code generation annex. Jérôme Hugues, ISAE

Transcription

1 Updates on the code generation annex Jérôme Hugues, ISAE

2 Current status Traceability to the AADL requirement document (ARD 5296): Validate and Generate complex systems Has been mostly delayed by AADLv2 and BA reviews Implementation prototype available as part of Ocarina, for both C and Ada, and both AADLv1 and part of AADLv2 Partially documented in the respective documentations Scope of the annex Define what the user interface to the AADL runtime The implementation of the AADL runtime is not addressed Keep efficiency expected by users Draft sent in December, partial comments on clarification, currently being integrated page 2

3 Motivating example P.impl 5ms T1: T.impl Two instances of the same thread Same features, compute entrypoint Need to distinguish at runtime level Solution: Ports variables, access, subcomponents, Introduce an instance specific context record 5ms T2: T.impl Gives access to all internals and externals visible in this particular context Passed as parameters to code executed by the user-provided code page 3

4 Context for user-subprograms Example: thread Landing_Gear_T features Dummy_In : in event port {Compute_Entrypoint_Source_Text => "Manager.On_Dummy_In";}; end Landing_Gear_T; void on_dummy_in( aadl_ctx self) { aadl_send_output (self.landing_gear_local_ack,&request); } This self parameter would be used by the AADL runtime to route the request to proper destination no need to say more about aadl_ctx type, it is up to the code generator to define it, and instantiate it Note: this context info need to be passed in all cases to be consistent, and reduce code adaptation page 4

5 Context for subprograms Context give access to all entities visible from the subprogram perspective User-code hosted by a thread Thread component type has visibility on Features, data, subprograms Similar syntax used to dereference all elements Features: self.<port> Data: self.<data> Subprograms: self.<spg> page 5

6 Handling ports and ports queues Issue: the standard leaves this as implementation-defined subprogram Send_Output features OutputPorts: in parameter <implementation-dependent port list>; -- List of ports whose output is transferred SendException: out event data; -- exception if send fails to complete end Send_Output; Add helper routines: Set_Send, Set_Dispatch, e.g. Set_Dispatch (self.<port>); Like Unix-select: implicitely of ports of a components are part of a set, simply flag the one to use to send/await dispatch on, etc Dual of the Updated runtime-service page 6

7 Tricky constructs: prototypes Shall we think about prototypes? we may allow subprograms with prototypes inside to have userprovided implementation e.g. C++ template, Ada generic, even some limited support in C however, needs to be constrained no need for code generated: simply generate the consolidated subprogram Does the instantiation process trashes the prototype? Actually, after reviewing Ocarina implementation: Instantiation trashes refines to, so no way to know the generic to instantiate Is it a bias in Ocarina? What about the meta-model? page 7

8 Tricky constructs: modes About modes If explicitly modeled using port communication, we rely on standard mechanisms What about runtime services? What is implementation-specific? Actual representation? Way to name modes? Is it something about mode naming in the BA? subprogram Current_System_Mode features ModeID: out parameter <implementor-specific>; -- ID of the mode end Current_System_Mode; page 8

9 Tricky constructs: interrupts Related to code generation, but also modeling patterns How to model an interrupt handler? It is a piece of code, dispatched by hardware or software elements Issue for code generation: What is its context? Who resets the interrupt mask? How to fetch interrupt information? Need a complete example by the community page 9

10 Tricky constructs: accessors Is there an agreement on the following pattern? Update is an accessor Requires access to data One instance part of data Connected to particular members Shall we explicit its features? procedure Update (Field : in out POS_Internal_Type); subprogram Update features this : requires data access POS.Impl; end Update; subprogram implementation Update.Impl end Update.Impl; data POS features Update : provides subprogram access Update.Impl; end POS; data implementation POS.Impl subcomponents spgupdate : subprogram Update.Impl; Field : data POS_Internal_Type; connections Cnx_Pos_1 : subprogram access SpgUpdate -> Update; end POS.Impl; page 10

11 Roadmap Need to converge on the tricky constructs to finish Modes and prototypes can be left over for now Modes: removed in model refinement to have more control Prototypes: syntactic sugar, yet only usable for Ada So no urgency Interrupts and accessors More useful patterns to be solved page 11