From RTSC-Pedia

[printable version]  [offline version]

offline version generated on 04-Aug-2010 21:08 UTC

FAQ-080713-4

Can I leverage RTSC with legacy content, or am I starting from scratch

The C programming language has been widely used for over a quarter-century; and without question, large bases of legacy C code delivered to clients as headers and libraries already exist. While flanking C with both a specification language (XDCspec) as well as a meta-language (XDCscript) may seem rather exotic at first, you can actually employ RTSC in a more incremental manner that allows content leveraging select aspects of the RTSC flow to ultimately co-exist with legacy headers/libraries in embedded application programs. RTSC is revolutionary and evolutionary.

Creating managed content.  Without changing a line of legacy source code, you can leverage RTSC packages for their ability to manage software content from production through consumption; with only modest effort, existing libraries and headers could now flow from supplier to client via a standardized container that is built, released, and deployed using widely-available command-line and GUI tools.

From the client's perspective, all packages exhibit a common "look-and-feel" that streamlines the installation and integration of their contents—independent of whether this content further leverages other elements of RTSC or else remains in its legacy form. From the supplier's perspective, RTSC packages afford new opportunities to explicitly codify dependencies upon other named packages as well as to automate (say) the inclusion of specific versions of legacy libraries during program configuration via special XDCscript meta-functions; content suppliers may also employ RTSC package build scripts to better insulate themselves from underlying compiler details as well as to better manage the compilation of common (legacy) source code for multiple targets.

Creating spec'd content.  As general-purpose containers, RTSC packages need not further define any RTSC modules within their logical scope; but when they do, these packages can participate more actively in downstream program configuration as well as present a more uniform face to client C programmers via generated headers. By wrapping legacy libraries with spec'd RTSC modules whose bodies trivially defer to existing implementations, this content becomes indistinguishable from newly developed modules in the eyes of the component consumer; at the end of the day, each RTSC module has an XDCspec source that draws a programmatic boundary between clients and suppliers using a mixture of formal declarations and informal commentary, regardless of the implementation strategy chosen by the module supplier. Wrapper modules become an ideal locale for "adding value" atop existing libraries, through:

• clarity of XDCspec sources over .h header files
• configuration parameters for greater flexibility during integration
• XDCscript meta-functions to support program synthesis and analysis
• run-time parameter validation and event logging across function boundaries
• and so forth, as an exercise for the legacy content supplier

Complementing the wrapper module approach—which typically requires no changes to legacy code—content suppliers can also introduce RTSC modules specifying just config parameters, replacing #define symbols, static constants, or readonly extern data in the existing code base. Straightforward to implement on the supplier's side, benefit accrues when downstream clients can robustly assign these configs in XDCscript meta-programs in lieu of more ad hoc and error-prone editing of C source files. And thanks to whole-program optimization technology available in many contemporary C compilers, module configs can become as efficient as #define symbols used in conjunction with #if directives; and wrapper modules can become as efficient as #define macros or inline functions.

Finally, RTSC enables content suppliers to define so-called metaonly modules in XDCspec—a module whose implementation is limited to host-based XDCscript meta-functions—used to otherwise facade legacy content when even wrapper modules are inappropriate. Though lacking an automatically generated C header from its XDCspec source, a metaonly facade module becomes indistinguishable from others during design-time configuration (and even during run-time analysis). Leveraging some of the more sophisticated back-end generation capabilities of RTSC configuration (e.g., synthesis of C code via parameterized templates), metaonly facade modules can achieve some of the benefits of target modules containing configs—but without any modification of legacy code, a possible constraint. Erecting software facades itself emerges as a general design pattern employed to encapsulate a myriad of underlying details—whether configuring legacy libraries or even calling other spec'd modules—through a simpler, more focused programmatic contract; what's important here is that RTSC modules defined in XDCspec can broadly subsume a virtually unlimited continuum of techniques for layering new functionality atop existing content.

[printable version]  [offline version]

offline version generated on 04-Aug-2010 21:08 UTC