Programmer 7500

home *** CD-ROM | disk | FTP | other *** search

/ Programmer 7500 / MAX_PROGRAMMERS.iso / CLIPPER / MISC / ACOM0610.ZIP / SUCCESS.HLP < prev

Wrap

Text File | 1993-06-10 | 33.1 KB | 606 lines

AdaIC form G89-1091a file SUCCESS.HLP Ada Information Clearinghouse, 1-800/AdaIC-11, 703/685-1477 10 Ada SUCCESSES By John Keller Reprinted from Military & Aerospace Electronics, August 1991, Copyright 1991, Sentry Publishing Co., Inc., Westborough, MA 01581 Two or three years ago, a search for 10 unqualified Ada success stories would have turned up a whole lot of nothing. A litany of General Accounting Office reports told one Ada horror story after another, of Ada code that wouldn't run, qualified programmers who couldn't be found, and concurrent software engineering projects that became so entangled that project managers had to scrap them and start over from scratch. Leery of cost overruns and delays, program managers willingly granted waivers to the Pentagon's Ada mandate to virtually everyone who asked for one. Now the industry has matured. At the dawning of a new decade, Ada has overcome its greatest setbacks. Today, successful Ada implementations are relatively easy to find. Quality compilers and debugging tools are finally readily available for virtually any host environment and target processor -- and from a range of competing vendors. Congress has given the Defense Department's mandate the force of law, and DoD has responded with a no-waiver policy designed to stop the easy-waiver practices of years past. More important still is an Air Force study that shows, for the first time, that Ada really is living up to its promise of offering better maintainability, reusability, and programmer productivity than competitive languages. This month, Military & Aerospace Electronics showcases 10 projects that can make Ada experts proud, rather than cringe and send them searching for cover. Some are big efforts, some small. Some for embedded and real-time applications, some for desktop information-management jobs. But no matter what the application, all of these efforts share at least one common characteristic: the programming tools worked. And that's something that wasn't always the case just a few years back. Project: FS 2000 Sponsor: Finnish, Swedish, Danish, Australian, New Zealand Navies Integrator: Nobel TechSystems AB, Stockholm, Sweden Compiler Vendor: Rational, Santa Clara, Calif. Challenge: Enabling Related Ada Functions to Communicate If ever there was a massive software challenge, this was it: a complicated package of more than 1 million lines of Ada code that would provide an integrated surveillance, communications, and fire-control system for small warships and patrol craft. What's more, the system had to include independent software programs that could communicate and work together -- and designers were under pressure to reuse as much code as possible each time the software was adapted for different ships belonging to different nations. Today, five years after engineers with Nobel TechSystems AB began writing the first lines of code, the resulting FS-2000 system is acknowledged by senior U.S. software experts as one of the most successful Ada projects to date. Along the way, Stockholm-based Nobel -- formerly Bofors Electronics AB -- had to define a proprietary operating system that added several layers of communications software to the existing OS-9 operating system and develop a new approach to business expressly for their target market -- naval vessels. "We wanted to build the system as a set of cooperating problems," says Jaak Urmi, chief of base technologies for Nobel TechSystems, "Ada nicely defines how to interface Ada tasks, but there is not a word on how to communicate between Ada programs." And while industry and academia were trying to address that problem at the time, Urmi recalls, "we couldn't wait." Instead, Nobel turned to Rational, of Santa Clara, Calif., for development tools and assistance. But the task was not that simple. FS-2000 consists of many systems, ranging in scope from data base applications where speed isn't pressing to demanding real-time applications for tracking sea-skimming anti-ship missiles and directing onboard weapon systems to destroy them within seconds of detection. With the processing load distributed over 100 Motorola Inc. 68020 and 68040 microprocessors, the system was among the most complex Ada projects ever attempted. "The software is very highly distributed," says Bob Bond, Rational's executive vice president for international sales. "It's very complex, with intense real-time requirements." Two conflicting needs tugged FS-2000's designers in opposite directions. On the one hand, they had to meet hard-real-time constraints; on the other, they had to write the software in such a way that it could be easily reused. So while it was tempting to write the real-time portions of the program in Assembly language for maximum performance, it was just as important that Ada be used as much as possible to promote software portability, maintainability, and reuse. Portability was essential because of the broad application of the system. Nobel's FS-2000 command-and-control system is now in use aboard Swedish KKV coastal corvettes, Danish Stanflex 300 corvettes, Swedish A-19 submarines, Finnish coastal patrol boats, and Danish inspection ships designed for fisheries enforcement near Greenland. The system is also scheduled to be incorporated into a planned Australian/New Zealand frigate. Adding further to the already complex equation, was the requirement that developers write custom software to link the multiple Ada programs -- without violating Ada's strict guidelines for acceptable use. The answer, Urmi says, came after much study. "We implemented an Ada remote rendezvous that makes it possible to structure a set of Ada programs so you don't go outside the language," he explains. The rendezvous is folded into OS-2000, a custom operating system based on OS-9. "It's basically OS-9 with a lot of layers of software to support Ada and this distributed system." Now Urmi and his colleagues are facing a new challenge. With Unix becoming an industry standard, they're hard at work trying to substitute Unix for OS-9 as much as possible. Urmi predicts Nobel's future shipboard command and control systems will include a mixture of OS-9 and Unix, with OS-9 handling the demanding real-time tasks and Unix handling the more conventional chores. The arrangement is similar to today's technique of using Assembly routines embedded in Ada programs to squeeze out every microsecond of performance. Project: MK 41 Vertical Launch System Upgrade Sponsor: U.S. Navy Integrator: Martin Marietta Corp. Aero and Naval Systems Group, Baltimore Compiler Vendor: DDC-I Inc., Phoenix, Ariz. Challenge: Achieving The fastest Possible Interrupt Handling When engineers from Martin Marietta Corp.'s Aero and Naval Systems group in Baltimore started designing the Navy's Vertical Launch System Baseline 4 upgrade two years ago, the ability to handle software interrupts was foremost in their minds. That's one of the reasons they chose Ada compilers from DDC-I Inc. of Phoenix, Ariz., to support their VLS computers. The computers are based on Intel Corp.'s 80286, 80386, and 80186 microprocessors, says John Page, Martin's chief of embedded software on the VLS project. DDC-I, Page says, offers two kinds of interrupt handling -- fast and normal. Back in 1989, the competition didn't, he says. The Vertical Launch System arrays as many as 61 missiles and launchers side-by-side, like eggs in an egg carton, below the decks of the Navy's Arleigh Burke and Spruance-class destroyers and Ticonderoga-class cruisers. The system, which can fire both offensive and defensive weapons, is also used in surface vessels belonging to several foreign navies. Martin's job was to replace the low-level sequencing computer that controls missile launch sequencing and interfaces with fire control computers. Engineers tore out 8-bit processors and replaced them with a system based on two 80386 processors and ten 80186 processors, all running Ada, and seven 8097 microcontrollers running code written in C. Their biggest concern: real-time interrupt handling. That's crucial because missiles have to respond to changing threats within seconds -- without waiting for the computer to complete tasks in progress. A missed interrupt message can cause the VLS system to miss incoming missiles, lose target opportunities, waste missiles by inadvertently flooding launching tubes, or even cause accidental detonations of multiple warheads. DDC-I's fast interrupt handler bypasses the runtime system scheduler, so messages go straight into the source code, Page explains. That way "it's as fast as the microcontroller and the processor." By contrast, the normal interrupt handler is an Ada task that the runtime system schedules as the interrupts come into the system. All interrupts must be handled within a 1 to 2 ms window, but some must be taken care of more quickly than others. DDC-I's normal interrupt handler, which features a context switch time of 25 us for an Ada rendezvous on a 16-MHz 80386 machine, beats the requirement by as much as 80 times; DDC-I's fast interrupt handler is another 10 times faster than that. But Page says that designers shouldn't use the fast interrupt handler unless they're faced with potential data overruns, in which the computer receives data faster than it can handle. That's because the fast interrupt handler gains its speed by blocking the flow of other messages. "Unless you have a definite need to use the fast interrupt handler, it's better to use the normal handler because [the fast handler] precludes you from scheduling and passing data to other tasks." The MK 41 VLS, which can fire the Tomahawk and Sea Sparrow missile, Antisubmarine Rocket, and Standard Missile II, is scheduled for Navy acceptance this month, with the first test firings this fall. Project: B-2 Stealth Bomber Air Crew Simulator Sponsor: U.S. Air Force Integrator: CAE Industries Link Flight Simulation Division, Binghamton, N.Y. Compiler Vendor: Concurrent Computer Corp., Tinton Falls, N.J. Challenge: Building Real-Time Extensions To Speed Ada Execution Few defense systems have real-time requirements as stringent as air crew flight simulation. Any perceived delay in the device as it responds to control movements compromises the training's value and makes the air crew lose confidence in the machine. Engineers at CAE Industries' Link Flight Simulation Division in Binghamton, N.Y., confronted this problem when the Air Force contracted them to devise a simulator, written in Ada, for the B-2 stealth bomber. Link turned to Concurrent Computer Corp., Tinton Falls, N.J., in 1986 to provide software and hardware fast enough for the job. Although Ada is intended for real-time embedded applications, critics often fault the language for failing to handle hard-real-time tasking well. Until recently, the accepted method for Ada programmers working time-critical tasks was simply to write them in Assembly or C. That method is fast and efficient, but can be difficult to maintain or reuse. But when they started work on the B-2 simulator, Concurrent's engineers decided to handle virtually all time-critical tasks in Ada by writing a series of real-time extensions with Ada's pragma facility, which sends special instructions to the compiler to attain maximum speed. "Time-critical Ada needs real-time extensions," says Wendy Hudson, Concurrent's senior manager of compiler development. "Ada is a robust language, but there are subtleties underneath, and most basic Ada doesn't handle real time well." Concurrent's 19-processor parallel architecture for the B-2 simulator, which is based on the company's 3280 processor, draws heavily on a real-time extension designed to suppress an Ada task that routinely checks for stack memory overflow, "If a subroutine is being called, you have the option to put in this pragma that says don't do the stack checking," Hudson says. "It saves overhead by saving a couple of instructions." But to do this, Hudson and her colleagues wrote software tools around the pragma that guarantee the programmer from the start that he'll have enough stack space, which is area set aside in main memory for arithmetic calculations or for keeping track of internal machine operations. Concurrent developed tools to calculate how much stack space a program needs at any given time in order to guard against overflow. So by determining that need from the start -- and by structuring code to require the minimum amount of stack memory at any given time -- users can safely avoid stack overflow checking while running code. The B-2 simulator, which consists of more than 2 million lines of code, is now in its final stages of development. Project: YF-22 Common Integrated Processor Avionics Sponsor: U.S. Air Force Integrator: Hughes Aircraft Co., Radar Systems Group, El Segundo, Calif. Compiler Vendor: Irvine Compiler Corp., Irvine, Calif. Challenge: Using Ada Multitasking To Its Full Advantage One of the qualities that attracted the Defense Department to Ada in the first place was its ability to execute several tasks at once. But software engineers working on advanced avionics couldn't take full advantage of that multitasking capability until there was hardware available to really support it. That's now available in Intel Corp's i960, the standard 32-bit microprocessor for Lockheed Corp's F-22 Advanced Tactical Fighter. "The i960 processor understands multitasking in the silicon," says Dan Eilers, president of Irvine Compiler Corp., Irvine, Calif. "It actually has hardware instructions to schedule and deal with different processes" -- capabilities unavailable, he claims, on competing processors, such as MIPS Computer Systems Inc.'s R3000. "This is one key reason why the ATF uses the i960, because you have direct hardware support for these concepts." Without a multitasking language like Ada and a chip like the i960 that can use it to full advantage, "you have to do clumsy things outside the language and in the operating system" to handle interrupt tasks, Eilers says. "If the language is sequential [like C] and your application is parallel, you have a mismatch between the abstractions available in your programming language, and those required by your application." With Irvine's Ada compiler, F-22 software engineers were able to handle interrupts within the language -- a crucial quality for avionics. Interrupts are crucial in avionics applications, since software tasks must routinely be stopped and set aside so the system can handle higher-priority jobs, such as threat warning and avoidance. Hughes Radar Systems Division, El Segundo, Calif., which is developing the F-22's Common Integrated Processor avionics, chose Irvine in 1986 because the company was the first to offer an i960 compiler -- one year before its prime competitor, Tartan Inc. of Monroeville, Pa., brought its compiler to market. Tartan, however, claims it's the first to have its i960 compiler pass DoD validation. Lockheed's YF-22 beat out a rival from a team led by Northrop Corp. and McDonnell Douglas Corp. in April, and the program's demonstration/validation phase is wrapping up this summer. Project: Advanced Field Artillery Tactical Data System (AFATDS) Sponsor: U.S. Army Communications-Electronics Command (CECOM), Fort Monmouth, N.J. Integrator: Magnavox Government/Industrial Electronics Co., Fort Wayne, Ind. Compiler Vendor: TeleSoft, San Diego Challenge: Building a complex system with immature technology The Defense Department's first standardized version of Ada was only a year old when the Army and Magnavox Government/Industrial Electronics Co., Fort Wayne, Ind., started work on the Advanced Field Artillery Tactical Data System in 1984. AFATDS was going to be one of DoD's first major Ada projects. The trouble was, there were virtually no reliable Ada compilers on the market at the time, the AFATDS central processor -- Motorola Inc.'s 68020 -- was brand spanking new and didn't have a proven track record, and the project called for 1 million or more lines of code -- more than any prior program. Recalls Mark Overgaard, vice president for advanced development at San Diego-based TeleSoft, which provided Ada compiler support: "It was pushing technology on all fronts." It seemed like a disaster. Magnavox engineers had software problems from the start. And, for the first three years running, the company was lambasted in reports prepared for Congress by the General Accounting Office, Capitol Hill's investigatory arm. Critics called for the program's cancellation and sought to replace it with a competing system from Litton Industries Inc. called Light Tacfire. "Compilers had a lot of problems," says Ron Lawson, AFATDS software engineering manager at Magnavox, in a classic understatement. Perhaps just as troublesome, he adds, was the lack of an Ada debugger for the 68020 target hardware. But Magnavox weathered the storm. Today, John Solomond, director of DoD's Ada Joint Program Office, points to AFATDS as one of the most successful military Ada programs in the U.S. Magnavox started turning things around in 1987 and, two years later, the Army redefined AFATDS hardware requirements, mandating that the software run on Army Tactical Command and Control System common hardware, rather than the custom computers originally planned. That change -- to Hewlett-Packard Co. computers adapted for military use by Miltope Corp., Melville, N.Y. -- effectively removed TeleSoft from the project, and handed compiler work over to Alsys Inc., Burlington, Mass. Still, Magnavox officials credit TeleSoft for helping to get the program back on track when everyone in Washington seemed bent on letting it die. Magnavox officials agree that an extremely close relationship between the two companies may have been the key to salvaging AFATDS. Indeed, TeleSoft even delivered its own source code directly to Fort Wayne, where it was loaded onto Magnavox's host computer systems. That meant TeleSoft "could make fixes right on their machines, and within 24 hours [Magnavox] could be back in business," Overgaard says. "We had technicians on site. That makes a big difference on these big projects using complex languages with a lot of subtleties." In return, Magnavox provided TeleSoft with working copies of AFATDS code as it was developed, so the Ada vendor's analysts could use it to test changes to their compilers and ensure that revised compilers could efficiently handle such large programs. A footnote: The Army's restructuring of the AFATDS program two years ago essentially forces Magnavox to start again from scratch with a new design, new software requirements analysis, and a move from the old menu-driven user interface to a graphical interface based on X-Windows, Motif, and the Unix operating system. Code development has barely started. Even so, Lawson says Magnavox has completed much of the shovel work, because his engineers will be able to reuse as much as 50 percent of the Ada code they developed with the first go around. The project is still woefully behind its original schedule, which called for fielding in the late 1980s. But with reusable Ada code, and with the introduction of well-tested off-the-shelf software for the user interface and data base construction, Lawson says AFATDS is on track for its scheduled March 1993 delivery to the Army. Project: Integrated Control & Avionics for Air Superiority (ICAAS) Sponsor: U.S. Air Force Integrator: Lear Astronics Corp., Santa Monica, Calif. Compiler Vendor: InterAct Inc., New York Challenge: Developing Software for Multiprocessing Architecture Software engineers at Lear Astronics Corp., Santa Monica, Calif., had to break new ground in 1988 when they won a contract to develop the Integrated Control & Avionics for Air Superiority system, or ICAAS, a situation-awareness and flight-control computer designed to enhance the air-combat capability of the aging F-15. Their challenge was to write software for a multiprocessor system based on MIPS Computer Systems Inc.'s R3000 RISC processor and the MultiBus II backplane/data bus. No one had ever done that before. Lear Astronics was a beta test site for InterAct Inc.'s Ada/MIPS Cross Compiler system, so it was the natural choice for the company's developers. But to optimize the resulting Ada code for ICAAS' multiprocessing architecture, "we needed to modify the runtime system to provide the hooks, communications, and device drivers to exercise the [MultiBus II] architecture," says Bernard Shen, the project's lead software engineer. Shen and his colleagues devised a message-passing scheme, rather than the more conventional approach of using shared memory and semaphores, because it was more secure and was less susceptible to data corruption, he says. But message passing, with its extra layer of communications software, consumes twice as much throughput capacity as shared memory systems. That factored heavily in Lear's decision to stick with the InterAct compiler, he adds, since its fast and efficient code put less demand on the hardware. "The InterAct code is almost as fast as my hand-coded Assembly," Shen says. Now InterAct is introducing Version 2.0 of its R3000 compiler, which Shen says produces code that's twice as fast as the previous version. And Lear is wasting no time upgrading ICASS with the new compiler. "[Its] performance makes such a big difference, that you really don't have to care [in terms of speed] whether you have shared memory or message passing," Shen says. His advice for other projects: "If you choose the right compiler, you'll be O.K." Lear delivered its portion of ICASS to the Air Force in October 1990. Flight tests on the F-15 are to begin next month. Project: Advanced Navy Submarine Communications Buffer Sponsor: U.S. Navy Integrator: Naval Ocean systems Center, San Diego Compiler Vendor: Alsys Inc., Burlington, Mass. Challenge: Code Reuse Across Multiple Platforms The software the Navy was using in the mid-1980s to automate its strategic submarine communications systems was a technical success. Users didn't complain and system failures were rare. But maintaining those programs was a logistical nightmare -- the systems were a mish-mash of hardware and software written primarily in poorly documented Assembly language. By 1987, the systems needed to be modernized. But given their software architectures, upgrading them was nearly impossible. So program managers at the Naval Ocean Systems Center in San Diego decided to start from scratch, reprogramming NISBS, the NATO Interoperable Submarine Broadcast System, in Ada. Now they're using that program as a foundation for two other submarine communications systems -- the Submarine Message Buffer and the Advanced Message Processing System. The two spin-off projects are expected to multiply into an entire family of submarine communications systems, all of which will be made up of predominantly common software components. The goal: only about 10 percent of each new program will be fresh Ada; the rest will all be taken from NISBS. The savings are phenomenal. NOSC's Submarine Message Buffer program might have cost $2.6 million and taken 235 man months to develop if it had to be developed from scratch, says program manager Ben Barlin. Instead, it's costing $550,000 and taking just 48 man months. Although it's a relatively small program -- about 20,000 lines of code -- Barlin says he can get the same time and cost savings on projects of 1 million lines or more. Key to that process is compelling the sponsoring system program office -- in this case the Space and Naval Warfare Systems command -- to specify requirements, rather than narrow instructions for development. As a result, the customer gets new systems into the field faster, Another bonus: functional prototypes early in the design cycle, so users can provide feedback on design and performance virtually from the beginning. "Don't let the sponsors dictate how to do it," Barlin advises. "Let them dictate what they want. You [should] be responsible for the implementation." Barlin's group does all the work on site at NOSC labs, using Intel Corp. 80386-based personal computers as both the development environment and the target processor. The project began with 80286-based machines in 1987 and was converted to 386 platforms two years later. Alsys Inc., Burlington, Mass, supplies the compiler, but Barlin says the tools are not the most important thing here -- it's the reuse process, he says, that makes the difference. Project: Marine Corps Command Management Information System Sponsor: U.S. Marine Corps Integrator: Marine Corps Resources Management Directorate, Albany Marine Corps Logistics Base, Ga. Compiler Vendor: Aetech Inc., Solana Beach, Calif. Challenge: Mapping Off-The-Shelf PC Graphics Into Ada The Marine Corps' project to upgrade its Command Management Information System (CMIS) with Ada software was proceeding on course and on schedule last year. Then disaster struck: software engineers discovered the Alsys Inc. compiler they were using couldn't map DOS-based graphics programs into Ada or support the use of a mouse. Without the ability to use such programs as PC Paintbrush and Harvard Graphics, or permit the use of a mouse on their Intel Corp. 80286 and 80386-based personal computers, the Marine engineers were in a quandary. They needed those capabilities and they needed Ada. But no one could give them both. Then, after looking into dozens of compiler products, they contacted Aetech Inc. in Solana Beach, Calif. Aetech provided just what the doctor ordered. "We needed the Aetech compiler and tools to display the graphical information, and for the graphic user interface and mouse driver," says 1st Lt. Lloyd Biggs, assistant officer in charge of Ada programming for the Information Resources Management Directorate at Albany Marine Corps Logistics Base, Ga. "Aetech had a mouse driver package, which Alsys did not provide, and they can display the graphical images of several formats." The Marines' CMIS program is an executive information system designed to pass logistics information up the chain of command, and it makes heavy use of bar graphs and pie charts so commanders can efficiently interpret data and pass it on to their high-ups, Biggs says. The Marines moved CMIS to Ada because the older version, written in a language called Ready Master, didn't allow them to service all CMIS users with one program. "We used to have to develop separate programs for each user, and it became cumbersome to maintain," says Capt. J.A. Hernandez, the directorate's officer in charge of Ada programming. "The only drawback to Ada was the [lack of available] packages to handle these low-level capabilities that we needed. Other than Aetech, there wasn't anybody out there who supplied them." Project: Wide Area Mine (WAM) Sponsor: Army Armament Research and Development Command, Picatinny Arsenal, N.J. Integrator: Textron Inc.'s Defense Systems, Wilmington, Mass. Compiler Vendor: Tartan Inc., Monroeville, Pa. Challenge: Optimizing Code For Different Memory Types Modern military systems often integrate multiple types of solid state memory, including fast random-access memory chips and nonvolatile programmable read-only memories. But the incompatible speeds and wait states of the memory chips can be a show stopper for weapons designers. Program code must be written in such a way that real-time performance isn't sacrificed just because memory wait states aren't the same. This was an important concern when engineers designing WAM, the Army's Wide Area Mine, began looking for an Ada compiler in 1989. Their system was going to include static RAMs, erasable PROMs, and electrically erasable PROMs. They turned to Tartan Inc., of Monroeville, Pa., to develop and provide an Ada compiler. "These different memories have different wait states, and our product allows the user to specify the wait states that will be employed in the memory," says John Staire, DSP product manager at Tartan. "It allows us to optimize the code generated for the machine." With an architecture based on Texas Instruments Inc.'s 320C30 digital signal processor, WAM uses seismic and acoustic sensors to detect enemy tanks. The unit then lobs a munition into the air where it conducts a localized search before attacking the tank from above, where its armor is thinnest and most vulnerable. To succeed, the mine has to process information fast -- time-critical subroutines must execute in less than 500 ms -- with as little processing and memory hardware as possible. Gary Viviani, principal engineer for Textron, adds that Tartan takes full advantage of the C30 architecture, which takes four cycles to branch, or move to different sections of the program, by filling each cycle with logic tasks that otherwise would have to be done after branching. "Tartan isn't letting any of those cycles go to waste while it waits for the processor to be ready," Viviani says. WAM is now in full-scale development. Project: Ada-To-Motif Bindings (Developed for the EUCOM Command and Control System) Sponsor: Army Communications-Electronics Command, Fort Monmouth, N.J. Integrator: NASA Jet Propulsion Laboratory, Pasadena, Calif. Compiler Vendor: Meridian Software Systems Inc., Irvine, Calif. Challenge: Making Ada Compatible With the Motif Graphical User Interface It's no secret that the Defense Department requires all weapons-system software to be written in Ada. Less known -- though no less important -- is that DoD is also standardizing on the Open Software Foundation's Motif graphical user interface for all computer information systems. But despite DoD's requirements, binding together popular "point-and-click" interface was next to impossible. Until now. The National Aeronautics and Space Administration's Jet Propulsion Laboratory broke through the barrier in May when it delivered a Motif and Ada-based command, control, and communications system to the U.S. European Command in Stuttgart, Germany. With help from Ada compiler vendor Meridian Software Systems Inc., Irvine, Calif., JPL wrote the first-ever Ada bindings to Motif. And now JPL is making the bindings available, free of charge, as government-furnished equipment to companies and government agencies that need them. JPL wrote the bindings while under contract to the Army Information Systems Management Activity's Office for Command Center Upgrades and Special Projects, located at Fort Monmouth, N.J. Assembling the bindings wasn't as easy as it might sound, says Andrew Magruder, a JPL systems programmer who's been closely involved with the project to build a decision support system for the Army Headquarters European Command's Command and Control System upgrade. The problem was that Motif is written in C, a loosely controlled language that doesn't mesh well with Ada's notoriously tight controls. "We tried lots of compilers and platforms, and they didn't work," Magruder says. Then they tried Meridian's -- and it worked. Unlike most compilers, the Meridian product doesn't translate Ada code directly to Assembly before generating machine language. Instead, it incorporates an intermediate step, translating the Ada into C before boiling it down into machine language for specific target hardware -- in the case of the EUCOM C2 system, MIPS Computer Systems Inc.'s R3000 processor, the RISC engine within Digital Equipment Corp.'s DECStation 3100. Meridian makes the extra step through C to make the compiler more portable from one host computer to the next, Magruder says. The fact that the intermediate step was the key to binding Ada to Motif -- and conceivably other C-based products and standards -- was a bonus. But it was a major step forward for DoD software compliance. Indeed, since JPL's breakthrough, Magruder says, he can barely keep up with demand. "We get calls every single day." ********************** Ada Information Clearinghouse (AdaIC) P.O. Box 46593 Washington, DC 20050-6593 703/685-1477, 800/AdaIC-11, FAX 703/685-7019 adainfo@ajpo.sei.cmu.edu; CompuServe 70312,3303 The AdaIC is sponsored by the Ada Joint Program Office and operated by IIT Research Institute.