Glossary - Offline Version

From RTSC-Pedia

Jump to: navigation, search

revision tip

—— LANDSCAPE orientation

[printable version] [offline version]

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

Glossary

Terms used throughout the RTSC-Pedia

Base Directory

The directory containing the package's specification file, package.xdc.

Build Domain

Before a build script runs, numerous global variables have been initialized which represent the package to be built; i.e., both the xdc.bld.BuildEnvironment and xdc.bld.PackageContents modules as well as any properties accessible from these modules. This global context is sometimes referred to as the "Build Domain" and this global context is used by build scripts to affect the final contents of the package to be created.

Build Script

A build script specifies the set of software artifacts (libraries, headers, executable, scripts, documentation files, etc.) that must be included in a released package. Package producers write build scripts to specify what should be included in the package they are creating. Build scripts have the filename extension ".bld" and are written in the XDCscript language and runs in the context of the Build Domain. Also see DOM.

Bundle

A package that contains one or more repositories; i.e., directories containing a set of related packages.

Bundles are used to distribute a larger "product" consisting of several related packages.

Packages in any of the bundle's repositories are not "nested" packages of the bundle. Nested packages have names that are related to the names to the package within which they are "nested". In the case of a bundle, the packages in any of its repositories have names unrelated to the bundle's name.

Capsule

A capsule is simply a file in a package that contains XDCscript code. Capsules can be loaded and utilized via the xdc.loadCapsule() method. See The XDCscript Language for examples of how capsules can be used.

Compatibility Key

A compatibility key is a sequence of four numbers (M, S, R, and P) that is used to specify compatibility among different versions of the same entity (e.g., a package or a target). Changes in one or more digits of a compatibility key are used by package producers to allow or exclude certain combinations of packages (or object files created with different targets) by package consumers.

For more information compatibility keys and how they are used, see Compatibility Keys in the XDCtools User's Guide.

Component

Because there are many, sometimes conflicting, definitions of component, the term component will be avoided wherever possible. However, many in the software industry are adopting Clemens Szyperski's definition (from "Component Software, Beyond Object-Oriented Programming", 1998):

Software components are binary units of independent production, acquisition, and deployment that interact to form a functioning system.

Szyperski also describes a definition that was first formulated at the 1996 European Conference on Object Oriented Programming (ECOOP) as an outcome of the Workshop on Component-Oriented Programming.

A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.

Using these definitions, we see that components differ from classes in object-oriented systems in that components are units of deployment; most classes in an object-oriented system cannot be independently delivered into and reused in a different application.

Independent of any definition, Szyperski and Messerschmitt identify five essential properties of components:

A component should be multiple-use, non-context-specific, composable with other components, encapsulated (cannot be modified or, typically, even examined) and a unit of independent deployment and versioning

`config.bld`

config.bld refers to the target configuration file that specifies the location of code-generation tools as well as optional target and platform configuration values used to build packages. This configuration file does not have to be named config.bld but, because this is the default name, this file is often referred to as "the config.bld file" rather than the awkward "the build model's target configuration file".

See xdc.bld.BuildEnvironment for a description of this file and how it is located by XDCtools. For a description of what this file contains and how it's used, see Managing Compiler Toolchains.

Configuration Domain

Before a configuration script runs, numerous global variables have been initialized which represent the program being configured; i.e., xdc.cfg.Program and any properties accessible from this module. This global context is sometimes referred to as the "Configuration Domain" and this global context is used by configuration scripts to affect the results of a configuration.

Configuration Script

A configuration script specifies the set of packages and modules that are available for use at run-time in a target executable. Package consumers write configuration scripts to import RTSC content into their executables, configure the content's functionality and optimize its memory footprint. Configuration scripts have the filename extension ".cfg" and are written in the XDCscript language and runs in the Configuration Domain. Also see DOM.

DOM

DOM is an acromym for Domain Object Model.

Domain Object Model

A Domain Object Model (DOM) is the set of objects that are read or manipulated by a domain-specific scripts. For example, the xdc.cfg.Program object and all of the objects it references form the DOM for configuration scripts. Similarly the xdc.bld.PackageContents and the xdc.bld.BuildEnvironment and any objects these two objects reference form the DOM for build scripts.

Some scripts operate in more than one domain (e.g., package init() functions). In this case, it is possible for a script to determine the current "domain" by examining the value of xdc.om.$name. This value is set as follows:

"cfg" for the configuration domain
"bld" for the build domain
"rov" for the runtime object view domain

E4X

E4X refers to a standards-based extension of ECMA-262 (JavaScript or ECMAScript) adds native XML support to JavaScript. This extension is also known as ECMA-357.

ECMAScript

ECMAScript is a vendor neutral name for JavaScript standardized as ECMA-262.

Gated Module

A gated module is a module whose specification (its .xdc file) declares that is has the @Gated attribute. This attribute means that the module has a dedicated xdc.runtime.Gate that it can use to serialize access to its internally managed "shared" data structures.

If an application configuration script does not explicitly create a gate for a gated module, a gate is automatically created and bound to the module during the configuration process.

IDL

See RTSC IDL.

Interface

An interface is an abstract module; i.e., it provides only the declarations of the constants, types, functions, and variables for which one or more modules implement.

JavaScript

A marketing name for the script language standardized as ECMA-262 (or ECMAScript).

Meta-Code

Code that runs in the meta-domain. Typically this code is written in XDCscript, but it can also be written in Java and even C.

Meta-Domain

Meta-domain refers to execution environments sufficiently rich to support the execution of RTSC configuration scripts; e.g., the developer's workstation.

RTSC modules have a dual existence: each module exists in the meta-domain before an application is linked (where its configuration parameters can be set and its properties examined) and (optionally) in the target-domain (where its functions are called by an embedded application).

Metadata

The simplest definition of metadata is that it is data about data. Metadata is used to facilitate the understanding, use, and management of data. For example, packages include metadata that describe the contents of the package - its compatibility with previous releases, the targets and platforms supported, any dependent packages, etc.

Metaonly Module

A module that has no formal existence on the embedded target. Metaonly modules exist solely in meta-domains (e.g., the configuration model or the build model), are specified using the metaonly keyword in the RTSC IDL, and are implemented in the XDCscript language.

Module

A module is a logically related set of constants, types, functions, and variables formally specified via the RTSC IDL. Roughly speaking, a module is comparable to a C++ or Java class; all of the identifiers defined by module are "scoped" by the module's name and it optionally defines and manages a set of instance objects.

In RTSC, however, modules have a dual existence: each module exists at design-time before an application is linked (where its configuration parameters can be set and its properties examined) and it has an existence at runtime (where its functions are called by the application). In some cases, a module may only exist at design-time and is called a meta-only module.

Modules provide both an interface and an implementation of the interface. A module named ModA typically has two implementation files:

ModA.c - the C implementation of the methods declared in its specification file ModA.xdc
ModA.xs - the implementation of the meta-domain methods declared in its specification file ModA.xdc

Nested Package

A nested package N is any package in which a proper prefix of N is the name another package, where a proper prefix is any prefix that ends just before a '.' character. For example, if ti.bios is a package, the package ti.bios.tests is a nested package of ti.bios and it is not a nested package of ti.biosutils.

Nested packages do not need to be physically nested; in the example above, ti.bios and ti.bios.tests may be installed in separate repositories.

Packages contained in a repository of a bundle are not nested packages of the bundle; the bundle's name is not a prefix of the name of any package in the bundle's repositories.

Package

A package is a named collection of files which form a unit of versioning, update, and delivery from a producer to a consumer. A package typically serves to contain one or more closely related modules and interfaces.

Each package is embodied as a specially named directory (and its contents) within a file system and always contains a package specification file named package.xdc and a sub-directory named package containing files that describe the package.

Package Archive

A single file that "contains" all of the files included in a package release. The XDCtools are used to initially create a package archive; in this case, the archive is a tar ball.

Package Consumer or Client

A role played by a developer in which she uses a package. Consumers never release new versions of a package and, with the exception of source packages, consumers never modify the contents of a package.

Package Path

A sequence of directories (also called repositories) that are searched to locate packages and the files contained in these packages.

XDCtools defines the package path as follows: "$XDCPATH;$XDCROOT/packages;^", where XDCPATH is an environment variable or command line parameter controllable by the user, XDCROOT is the location of the XDCtools installation directory, and '^' is the repository of the current package (if one exists). XDCPATH is a semi-colon separated list of repositories.

A package may appear in more than one repository, but only the first occurrence, in order of the repositories listed in the package path, is visible. This enables one to quickly replace one or more packages in a system without changing the contents or locations of existing repositories. In addition, this interpretation is consistent with how C/C++ compilers locate header files and, as a result, integration of existing C/C++ code gen tools amounts to simply adding a -I option for each repository in the package path.

For more information about managing the package path see Managing the Package Path.

Package Producer

A role played by a developer in which she creates and controls releases of a package to be used by package consumers.

Platform

A platform is a named entity that can load and run an executable. Platforms encapsulate everything necessary to link and run an application on a specific hardware platform: a linker command file template used to link an application, a "model" of the hardware used by configuration scripts to conditionally select appropriate libraries to link against, and commands to run applications on the hardware.

Platforms are defined in RTSC as an instance of a module named Platform, in any package, that implements the xdc.platform.IPlatform interface.

Platform Package

Any package containing a module, named Platform, that implements the xdc.platform.IPlatform interface. Platform packages contain all the information necessary to link and run applications within a specific "execution environment". Usually the execution environment is a specific hardware platform, however, it may also be a hardware simulation environment.

Release

A release of a package is the set of files that are seen by the client of the package. This set of files is often a subset of the package files that were used by the producer in the creation of the release. For example, package producers often deliver only pre-compiled libraries built from proprietary sources maintained in the package's directory.

A single version of package can provide multiple releases. For example, a codec package may produce multiple releases from a common set of sources: a binary release for each ISA supported (each sold separately), a "watermarked" binary release for evaluation by potential customers for one or more of the binary releases, and a re-buildable source release.

Repository

A directory that contains one or more packages which, when added to the Package Path, makes those packages visible to all tools. For example, a package named xdc.runtime must be installed in a directory that ends with xdc/runtime/ and the directory containing the xdc sub-directory is the repository for this package.

RTSC IDL

An Interface Definition Language (IDL) is a declarative language used to specify the programmatic interfaces provided by components within a system. IDLs describe interfaces in a language-neutral way, offer a bridge between different implementation-language tool-chains, and standardizes concepts not uniformly present in the implementation languages.

For example, using the RTSC IDL it is possible to define an interface that can be shared between a GNU Arm C/C++ tool-chain, a TI C6x C/C++ tool-chain, and a Microsoft x86 C/C++ tool-chain. Beyond just standardizing the concept of an interface and enabling interoperability among components produced by different groups, the RTSC IDL also augments C/C++ implementation languages by adding the concepts of package and module; concepts essential to component-based development.

The RTSC IDL is formally described in the XDCspec Language Reference.

Target

Targets are a named entity that encapsulate everything necessary to build a library of object code: a compiler tool-chain, a compiler-specific runtime model, and optionally a runtime OS. Targets are defined by any RTSC module that implements the xdc.bld.ITarget interface.

A RTSC target is distinct from the execution platform (sometimes referred to as "target hardware"). RTSC targets only encapsulate the code generation tools used to produce object code that is run on a RTSC platform. Platforms can run code produced by more than one target - different compiler tool-chains produce code that can run a platform - and a target can produce a library that can be used in different applications running on different platforms.

Target-Code

Code that runs in the target domain. Typically this code is written in C, but it can also be written in C++ or even an assembly language supported by a target.

Target Domain

A target-domain refers to an embedded target execution environment. Typically this environment is highly resource constrained with very little memory, no spare MIPS capacity, and tight real-time constraints.

Target Compatibility Key

Each target has an associated compatibility key. This compatibility key is typically computed from the version number of the compile and is used to ensure that incompatible versions of tool-chain's object code are not linked into a single application.

Target compatibility keys are used to detect the situation where a consumer using an old tool-chain tries to use a package that was built with a newer version of the tool-chain. Since an old tool-chain can't anticipate new object-file formats or name mangling algorithms used by newer tools, target compatibility key checks can provide early diagnostics for what would otherwise be cryptic tool-chain errors or hard to find bugs in an application.

Target Module

A target module is any module that is not meta-only. These modules provide code (or data) can be referenced by other modules at runtime in the embedded target.

Template

A template is a file that is used to generate another text file. Although a template file can have any extension, by convention the template in the XDCtools all have the extension .xdt. Templates are loaded and expanded using the XDCscript methods xdc.loadTemplate() and tplt.genFile() where tplt is the object returned by xdc.loadTemplate().

Templates are used to generate C headers, linker command files, C source code, and even IDE project files. For more information about how templates can be used to generate files see Methods for Generating Other Files.

Typed-Object

Typed-Objects refer to XDCscript objects that, unlike ordinary JavaScript objects, are specified via XDCspec, do not allow the addition of new properties, type check all assignments to their properties, and have a set of built-in properties that enable scripts to "walk" the object's inheritance type hierarchy.

XDCtools

A set of freely available host-independent tools that enable the creation and use of RTSC packages.

These tools can be obtained from the RTSC home page.

XDCPATH

XDCPATH is an environment variable used set to be a string of ';' separated directories that contain packages; i.e., repositories. XDCPATH is not the entire package path, it only defines the initial repositories searched. The values contained in XDCPATH may also be specified on the command line of any XDCtools command via the --xdcpath option; for example, see the xs command options documentation.

It is usually a mistake to put a relative path in XDCPATH. Relative paths in XDCPATH reference directories relative to the package being built rather than the directory where the xdc command was invoked. Thus, a relative path will refer to a different repository for each package being built.

It is possible, however, to use the '^' character in the XDCPATH definition to refer to the current package's repository. So, if you have a repository that is always in a fixed location relative to all of your package's repositories, it is possible to create a single XDCPATH setting that does not include any absolute paths. Suppose, for example, that your build system places all prerequisite packages in an imports repository prior to building the packages in a src repository and that the imports and src repositories are sibling directories in the file system. The following XDCPATH setting is sufficient to build all packages in the src repository.

Windows

set XDCPATH=^/../imports

Unix

export XDCPATH=^/../imports

Note that multiple versions of the same package can appear along the XDCPATH. The package path can name multiple repositories which can contain a package directory with the same name. When searching for a package, the first repository that contains a directory matching the package's name will be used. Thus, even if two packages with the same name appear in the package path, only the first one in the order specified in the package path will be found.

XDCROOT

The installation directory of XDCtools. The xdc command defines an environment variable of this name so that makefiles can portably reference the packages that are delivered as part of XDCtools.

XDCscript

XDCscript refers to the programming language used to implement the meta-domain portion of RTSC modules, configuration and build scripts, and command line utilities. This language is primarily JavaScript with E4X but also includes some Rhino shell extensions and a few global objects defined by the XDCtools product.

For a description of this language, see the The XDCscript Language user's guide.

XDCspec

XDCspec refers to the RTSC Interface Definition Language used to declare modules, interfaces, and packages.

For a description of this language, see the XDCspec Language Reference.