The MC-3020 Model Compiler is available in two forms: source and binary. As its name implies, the source version contains the full source code for the Model Compiler with rights for the user to modify it to suit their needs. The binary version contains full code generation capability, but does not contain the Model Compiler source code. This is manifest in the presence, or not, of the arc folder in the installation.

The translation engine embodied in the MC-3020 Model Compiler performs two passes across the xtUML model under translation. The first pass analyzes the model structure and action language semantics of each component. The results of this analysis drive the generation in the second pass. The second pass generates code and data that is minimized and optimized for speed. Unaccessed data and unneeded code are eliminated.

This multi-pass intelligence spans components and allows for optimizations at the system level based on information collected and collated from all components in the system.

Preemptive multi-tasking is supported on the Nucleus PLUS real-time operation system (RTOS) and on systems supporting POSIX threading. Single-task operation (with or without and RTOS) is also supported. Tasking supplies a rich means of providing preemptive prioritization among the xtUML classes running in the system.

Preemptive task/thread prioritization is provided in the generated C code. Groups of xtUML classes are mapped to tasks running at differing priorities.

MC-3020 also provides for prioritization through the marking of events. Higher priority xtUML threads of control can run without being preempted by lower priority activities.

MC-3020 cleanly translates large systems consisting of multiple xtUML and realized components. Support is provided to integrate and interface to hand-craft, legacy and/or off-the-shelf code.

MC-3020 supports the marking of persistent classes. The instance data for classes marked as persistent is restored at power-up from a non-volatile storage (NVS) device.

A set of metrics can be generated and reported each time the model compiler is run. Statistics on classes, associations, events and first pass analysis can be produced.

Metrics provided can be fed back to the analyst to provide a focus on recognized dangerous practices and fully illegal operations and accesses. Some of the metrics relate to sizing and complexity. These metrics could easily be tracked over the life of a project to provide quality and effort related measurements.

Based upon information modeled in BridgePoint Builder MC-3020 automatically generates source code frameworks for operations and outbound bridge implementation. These skeleton files will actually compile as generated. The user is saved from delving into generated code to divine interfaces required for these boundary functions. Kind and helpful comments are provided to guide insertion of bridge and operation implementation code.

Support is provided for translation of OAL in operation and bridge descriptions. The same action language used for BridgePoint Verifier is translated into the of bodies of the operation C source files and the bridge skeleton files.

Several hooks have been supplied to allow easy interfacing of user supplied code to the system level generated code. A source module is automatically generated that supplies empty functions which are invoked at various points during initialization, dispatch processing and shut down. These empty functions can be populated with user code for ``can't happen'' events, hardware bring-up, ``background'' processing, legacy clean-up and more.

To allow optimization for space and control over precision, the storage classes of integer and real based user-defined data types (UDTs) can be supplied by the user. MC-3020 also allows user-defined data types to be implemented as pointers. The pointer types are very convenient for passing across bridges (in both directions). Precision and pointer information is provided to the model compiler through marking.

Further optimization of space is provided through ANSI C bit field support. Multiple attributes can be packed into a single word of storage. This feature may also be used (with caution) in conjunction with memory mapped classes to model hardware with xtUML constructs.

MC-3020 attempts to optimize select any [inst_ref] from instances of [key_letters] where [where clause] when the where clause is checking for equality of the identifier. MC-3020 optimizes for code space. In addition, hooks into the scanning routines are provided to enable customizations to the selection search algorithms. Applications dealing with large collections of class instance data (hundreds or thousands) may use these hooks to further speed the selection process.

MC-3020 provides a safe way to bridge into the application from interrupt handlers (or other external tasks). Consistency is maintained in software architecture data structures and application data access sets.

A means is provided for the user to supply application specific fule file functions. This capability serves to extend the marking capabilities of MC-3020. It is possible to steer code generation in such a way as to provide customizations characteristic of particular target platforms, compilers and tool sets.

MC-3020 is purely ANSI C and generates code that can be compiled by any compiler compliant with the ANSI standard. The core model compiler uses no libraries or system functions. stdio.h is included simply for convenience during debug (for printf, etc). All generated code is simple, native C.

As of version 3.1, MC-3020 supports initialization of preexisting instances in data. This provides a substantial optimization in both bring-up execution speed and overall code footprint. Instead of creating, relating and initializing all of the classes at start-up, pre-existing class instances can be pre-populated with static initializers. Support is maintained for dynamic initialization using an initialization function (or an initialization object).

MC-3020 allows the user to intermix target source code with action language. These pieces, nicknamed snippets, are delimited by special strings. Snippets are allowed anywhere action language is supported: bridge operations, functions, class and instance-based operations, mathematically-dependent attributes, and state actions.

Snippets are delimited by /*#inline on a line by itself, followed by the target source code, followed by */ on a line by itself. C++ style comments (comments preceeded with "//") are allowed inside a snippet. Here is an example:

    /*#inline
      // Don't Panic
      int a = 42;
      printf( "The answer is %d\n", a ); 
    */

While the primary use of this feature is to add target code to action language, it should be noted that MC-3020 does not restrict (or care) what is placed inside the snippet. The key point is that MC-3020 simply allows these inline snippets to fall through the code generation process to the output target code. No additional processing of the snippet is provided.

A compiler directive called XTUMLMC_INLINE is used to allow conditional target compilation of the snippet code. Each snippet in the generated source code starts with

#if XTUMLMC_INLINE

and ends with

#endif

This directive (and, hence, snippet usage) is set active (1) by default in sys_user_co.h.

Note that entering target-specific code into a model can have consequences. A good model represents an implementation-independent specification of the application. Adding target-specific code to the model can reduce this flexibility.

On the other hand, done carefully, code in models can overcome some of the limitations of the action language. For example, code in models can allow you to access target-specific registers and ISRs, give you access to unmodelled external code modules, and use target assembler code in an action.

In nearly all cases, properly constructed models and action language can completely describe an application. Take care when adding code to models. Understand the benefits and do not underestimate the costs.

By default MC-3020 creates applications that are very restrictive in their memory usage. This is done by statically allocating all memory that will be needed when the application starts. Some applications, however, need the flexibility of being looser in their memory consumption. See the section called “Marking Dynamic Memory Allocation On” for information on how to allow your application to dynamically allocate additional memory as needed.

XMI is an acronym for XML Metadata Interchange. BridgePoint MC-3020 supports the ability to export your models in XML format using XMI 2.1. XMI is an Object Management Group (OMG ) specification for the use of XML in serializing models so that they can be imported, exported and interchanged.

To export your project using XMI:

MC-3020 will run in a special mode that generates an XML file for each of your domains. The files will be placed in the src folder of your project. The file(s) are named <domain>_xmi.xml.

Once the export is complete, be sure to uncheck the XMI Export builder and check the CDT Builder to put MC-3020 back into normal code generation mode.