From RTSC-Pedia
 | [printable version] [offline version] | offline version generated on 04-Aug-2010 21:08 UTC |  |
FAQ-080713-8
I also want to produce RTSC content, what should I read next
Contents |
Though entirely optional, those of you electing to produce as well as consume RTSC target-content would receive immediate benefit—for one, your own modules and packages automatically become peers to products like DSP/BIOS 6.00 and CodecEngine, and would consequently enjoy an equal presence within all of the consumer-centric packaging, configuration, and analysis tools introduced above.
As a content producer, you'd also leverage the same higher-level eXpanDed C capabilities for specification and implementation already used by others to develop modular, flexible components built for multiple RTSC targets from common, portable sources—without sacrificing system performance for broader goals of software re-use.
- The graduated lessons comprising the second-half of this document introduce the XDCspec language, used by content producers to specify RTSC modules along with the packages in which they reside; use of XDCspec fundamentally distinguishes producers from consumers. Live examples throughout these lessons illustrate common programming idioms used in the meta-implementation as well as the target-implementation of any RTSC module.
- At the same time, this document introduces the all-important xdc command, used here to build RTSC packages containing portable module implementations for multiple RTSC targets. Guided by a special build-script found in the package directory—and written in XDCscript, using familiar idioms—package producers can express what to build with the same degree of portability already enjoyed by their module sources.
- Picking up where the Module Primer leaves off, this document brings abstract RTSC interfaces into the picture as a way of specifying common client-visible behavior across an open-ended family of concrete RTSC modules that each would inherit and implement this same interface. The lessons in this document successively re-work example modules developed earlier in the Module Primer, rendering them more flexible and scalable than before.
- This document also explores proxy-delegate, a design pattern for composing concrete modules via abstract interfaces which appears throughout the xdc.runtime package as well as products like DSP/BIOS 6.00. Used here in tandem with whole-program optimization—a compiler technique for optimizing code across module boundaries—benchmarked example output will conclusively demonstrate our claim of higher-level programming and higher-level performance.
- Structured like the Module Primer, the lessons comprising the second-half of this document explore a variety of idioms used when producing a RTSC package—everything from naming the package and populating its contents through creating multiple releases of the same package. As in the first-half of this document, the emphasis here lies with the container and not necessarily its contents—nicely complementing the approach taken by the Module Primer.
- The second-half of this document also illustrates different techniques for delivering legacy content within a RTSC package—existing content not specified using XDCspec, and ranging from arbitrary data files to C library sources. Regarding the latter—code not necessarily implementing any spec'd RTSC module—the same process for building C libraries for multiple RTSC targets using the xdc command and package build scripts applies here as well.
- This document examines various RTSC interfaces published within the xdc.runtime package and then used by other modules within the package in a proxy-delegate pattern. Much of the consumer's ability to mix-and-match alternate modules through configuration parameters—illustrated within companion material on Using xdc.runtime—results from this particular design approach.
- For each of these xdc.runtime interfaces—which cover memory allocation, event logging, critical sections, and more—dedicated sub-documents present sample RTSC modules that inherit and implement these interfaces in a variety of ways. A stock set of portable modules (sources available) contained in the xdc.runtime package that already implement these interfaces receive treatment as well.
In the broadest sense, the role of component producer entails developing and delivering RTSC packages—whether these packages contain legacy-content, target-content, or meta-content. In the latter scenario, the component producer would specify meta-only modules that in turn might inherit meta-only interfaces; unlike ordinary RTSC modules, a meta-only module has a meta-implementation but no target-implementation.
As it turns out, creating a new RTSC target or platform involves developing meta-only modules that inherit and implement well-known meta-only interfaces, and then delivering the resulting meta-content in a standard RTSC package. The various xdc.tools.* utilities enumerated earlier follow a similar pattern, suggesting that anyone might elect to produce host-based RTSC tooling in the same manner.
See also
| FAQ-080713-9 | How is the RTSC-Pedia organized, and what sorts of documents exist |
| FAQ-080713-7 | If I'm only consuming RTSC content, what should I read next |
| [printable version] [offline version] | offline version generated on 04-Aug-2010 21:08 UTC | |
