Building
Embedded Applications Using Multiple Languages The Request for Proposal (RFP), an upgrade to a large avionics application, has just landed on the desk of a senior engineer. Winning this contract is important to the company. Discussions begin about the proposal and some basic questions about the software need to be answered. For instance, what development platform should be used? It has been years since the original software was developed and the world has moved on (and in the CS world the movement has been phenomenal). The next question: what programming language should be used? The original software was written in Ada or JOVIAL or C. Should the original language be used again, or should a new language be selected? What problems are likely to be encountered if a second language is chosen? Since cost reduction is the driving force in embedded systems today, there is a growing need to combine reusable software components, written in different languages, targeting different processors and developed on different platforms. This requires software design tools that can provide the flexibility to move between or even mix programming languages and make the process of migrating software to new processors as inexpensive as possible. The result can be significant: reduced development costs and improved time to market for new and redesigned products - which could be the company’s best chance to win that critical contract. However, the problems introduced when two or more languages are used are insidious and surprisingly difficult to resolve. What appears as a simple technical decision can lead to months of difficulties during implementation, debugging and testing of the software. Problems which can occur are described below: Incompatible Object Code An often overlooked problem is that compilers for each of the two languages may produce incompatible object code at two levels. First, the two languages may use different inter-procedural protocols that will make it impossible for procedures in one language to directly call procedures in the second language. For example, language A passes parameters using registers and language B passes parameters using the stack. These problems can be overcome at significant expense using case-by-case, specially-written, assembly-language transfer routines which adjust the parameters appropriately. The second level of incompatible object code, however, is unresolvable by the user. The internal format of the compiler-produced object code may be different. COFF, the so-called common object file format, has been implemented slightly differently by different vendors. Sun and Microsoft, for example, had different interpretations of the relocation entries which would prohibit their respective object code from being linked together. When the application is targeting an embedded microprocessor, each compiler vendor may have their own format or a different interpretation of a standard format. Incompatibilities at this level can only be resolved by the compiler vendor. Incompatible Run-Time Systems The next problem may be incompatible run-time systems. Certain languages (e.g. Ada and C++) require more extensive run-time support, and the run-time systems may take different approaches to handling interrupts or program raised exceptions or timers or memory-mapped I/O devices or a number of other low-level functions. Commercially available RTOS have alleviated this problem, but adding an RTOS to an existing system would be a significant challenge. Limited Source-Level Knowledge in Debugger Once the code is written, a symbolic debugger is an essential tool for eliminating bugs in the software. Unfortunately, many debuggers are written for one particular language. These debuggers do not have the needed source-level knowledge of the other program language. Using two debuggers is an option, but each would have limited capabilities when code written in the other language is executed. Limited would mean machine-code debugging only. While it is not impossible to debug higher-level languages at the machine-code level, it typically requires detailed knowledge of the source-to-machine-code translation and it significantly decreases programmers’ productivity. Language-specific Testing Automated testing tools also improve programmers’ productivity, but are faced with the same problem as debuggers - namely language-specific capabilities. A tool which analyzes Ada code and automatically produces test cases or measures test coverage will be incapable of doing the same functions for Java code. Language-specific Analysis Tools Other tools for analyzing source code, from automatic documentation generation to complexity measurements to static analysis, are frequently language-specific. Acquiring these tools for the second language (either build or buy) will require additional expense. Despite the problems involved with using multiple languages, nearly all embedded applications are written using more than one language. There are typically a number of financial reasons for doing so. Reuse of Existing Code There are many financial incentives for reusing existing code written in other languages. The obvious one is the code has already been written and debugged. An additional point to consider is testing. Testing code for FAA certification is a very serious and expensive undertaking. Reusing existing code can reduce this effort. Programmers’ Skills The original code may have been written in languages not used or taught today, e.g. JOVIAL. Hiring programmers with these skills or even training current staff may not be possible. Instead of continuing the old language, the new software is written in a more modern language. Efficiency No language does everything well. In spite of the improvements in processor speed, there will always be cases where the speed or size of the generated code will be an issue. For example, interrupts may be disabled for only a limited and very short period of time. A second language may provide the degree of control that will solve the problem. Interface to Third Party Libraries or Tools Some needed functions may be available from third party libraries which are written in a second language. Automatic code generation tools may speed the development process, but may generate code in a different language as well. Overcoming the Problems of a Second Language Given the financial incentives to pick a second language, what options are available to overcome the problems inherent in that selection? There are three approaches. For completeness, the first option is to reconsider the choice of a second language. Often that is not an option for reasons not directly related to the current project. Company standards regarding the use of third party libraries or tools may require it. The savings from reusing those other software packages (or rather the expense of rewriting them) may also rule out the one-language option. The second option is to work around the incompatibilities. The decision is made to write the assembly-language inter-procedural routines, to accept machine-level debugging for part of the code and to write manual tests. The additional costs from this option must be included not only in the initial delivery but in the entire life cycle (e.g., extended maintenance) of the product. The third option is to select a suite of related tools, compilers, linkers, debuggers, test tools, etc. that are designed to work together and address the incompatibilities. Here, the biggest problems are availability, expense and completeness. For the development of embedded applications, a number of vendors now offer tool suites of varying functionality and cost that support at least two languages. DDC-I markets a tool suite called SCORE (Safety-Critical, Object-oriented, Real-time Embedded) that addresses these problems in a unique way. DDC-I has developed and integrated tools that rely on a number of open standards. The central concept of SCORE is a common intermediate language, called ANDF (Architectural Neutral Distribution Format). ANDF was developed by the European Commission (EC) and is a X/Open standard. The Europeans were concerned over the US domination of the microprocessor industry and undertook a cooperative development effort called the Open Microprocessor Initiative (OMI) to address support needed by newly developed microprocessors. Computer languages and compilers are one such need. The EC selected the United Kingdom-developed ANDF as the common intermediate language and then developed a set of language-specific producers which translate a programming language into ANDF and a set of processor-specific installers which translate ANDF into a target processor’s object code. New processors would require only a new installer to have a suite of languages readily available, and a new language needs only a new producer to be targeted to a set of processors. Within SCORE two languages (e.g. Ada and C) share the same installer, resulting in the same object code. Other companies (DERA and Etnoteam) have also created producers and installers which will work within SCORE. The object code adheres to other standards such as ELF and DWARF. The use of DWARF debugging information allows the SCORE multi-language debugger to support multiple languages at the source level. Each language producer generates ANDF debugging directives which the desired installer converts into language-independent DWARF information. To debug an embedded application the multi-language debugger needs only the DWARF information and access to the source files. Compare and contrast this to a proprietary debugger such as DDC-I’s earlier DACS debugger. While this was a full-featured Ada language debugger, it relied on symbol table and other compilation information that was unique to that tool set. Other languages could not be supported and could be debugged only at the machine-code level. Within the ANDF and DWARF, DDC-I developed other SCORE-integrated tools that are common across languages. The Run-Time System uses common low-level code for all languages. For example, all memory management and storage allocation are performed by one common set of routines. Test tools are developed which use the common ANDF intermediate language and are, as a result, language independent. Where other standards are available, they are also incorporated in SCORE. One such example is the debugger communications with the embedded application. Included on the target is a debug monitor which utilizes the OMI host-target protocol for communicating with the multi-language debugger on the host. Programming embedded applications in multiple languages is standard practice. However, all problems and costs of such a development must be considered when making language-choice decisions. The availability of common tool sets, such as DDC-I’s SCORE, remove some of the associated uncertainties and risks. Taking all of these things into consideration, the senior engineer who received the RFP is now ready to make an informed decision about the programming language for the project. DDC-I Offers User-Friendly VAX to Solaris™ Migration DDC-I’s Very Smooth Migration (VSM) package delivers a low-risk migration path for safety-critical embedded system Ada developers faced with rising VAX/VMS support costs Phoenix, AZ — September 12, 2000 — DDC-I, an industry leading provider of real-time embedded system software development tools and services for safety-critical project developers since 1980, today announced the availability of a new Very Smooth Migration (VSM) package, created specifically to support safety-critical software developers decomissioning their venerable DEC VAX hardware — recently discontinued by Compaq — and moving to the well-established Sun Solaris environment. The package is designed to ease the transition for organizations replacing their existing VAX-based DDC-I IDE (Integrated Development Environment) with a mature Solaris-based version. Other developers new to DDC-I that are also migrating from VAX/VMS to Sun Solaris have the opportunity to acquire one of DDC-I’s robust Ada IDEs, field-proven by customers like Boeing, Ericsson, Honeywell and Mitsubishi. "Given that a customer’s OS and apps generally represent a far greater financial and intellectual investment than the underlying hardware, we feel that minimal disruption and change for the programmers and the IDE they depend on is the top priority when it comes to managing a platform migration for embedded systems application development," says Russ Seideman, Vice President of Sales and Marketing at DDC-I. Soon after Compaq announced the acquisition of Digital in early 1998, industry analysts reported that approximately 30 percent of VAX/VMS users were planning to migrate to a different platform. DDC-I created the VSM migration package in direct response to Compaq’s impending September 30, 2000 cut-off date for VAX hardware orders, which is the first step in a proposed ten-year system support phase out. One of the few contemporary operating systems to rival the unparalleled stability and scalability of the legendary clustered VAX/VMS environment, Sun Solaris in tandem with the mature DDC-I Solaris-hosted IDEs provides a secure migration path that minimizes risk via porting of existing VAX-hosted VMS applications to a new Solaris development platform. "The program was designed to be extremely affordable and flexible, to allow organizations to dictate exactly what tools and support they need, instead of handing them a rigid, tiered list of options," he says. By letting customers define the parameters, each organization has the ability customize their migration package by choosing from among a wide spectrum of options, from software upgrades and a basic annual support package to complete start-to-finish consultation, training, and system configuration. According to Seideman, the VSM package will bundle either the mature and stable DACS™ (DDC-I Ada Compiler System) or TADS™ (Tartan Ada Development Systems) IDE for Sun Solaris with a list of choices that includes on-site consulting to assist with rescripting, memory and segment set up, tool adaption, related Ethernet work and UCC upgrading. A final project report with recommendations is inclusive. "In addition to new DACS or TADS software, the package will also add one year or support to any existing support package from DDC-I, and includes all necessary license transfers and keys. The user also has complete freedom to select the number of seats they want to migrate and whether to upgrade their software versions during the migration," he adds. DDC-I’s DACS is a powerful development environment, constructed around a validated, field-proven Ada compiler. The standard DACS bundle also features an Ada recompiler, symbolic debugger, linker, run-time profiler and system, and library management tools. The TADS-2000 products (TADS-1750A, TADS-68xxx, and TADS-i960) combine a highly optimizing compiler with modular run-times and selective linking to generate the most compact code available, in addition to performance benefits and classical optimizations specific to target architecture. "DDC-I is offering the VSM package to its existing IDE users as a cost-effective migration path away from the aging VAX hardware, while we will continue to offer a level of support for existing DDC-I IDE users that choose remain on VAX/VMS," Seideman concludes. Ada Names & Debugger Keyword A possible conflict may arise in the debugger if an Ada name coincides with a debugger keyword. The Debugger is not able to recognize an Ada name as such if a keyword exists with the same spelling that can appear at the place of the Ada Name. The debugger selects the keyword by default. For instance, when the command 'display status' is presented to the DACS-NT debugger, it is the status of the debugger that will be displayed rather than the value of a variable. The ambiguity may be resolved with the dotted path notation to the Ada entity:
An alternative method is to place the keyword within parentheses:
or as an alternate:
|