Does anyone remember the days when there was a virtual cornucopia of development tools? Well, the latest bounty is even larger. But when it comes to integrated development environments (IDEs), an interesting consolidation has occurred. While the number of unique IDEs continues to shrink, IDE sophistication is on the rise.
It's becoming increasingly difficult to start a brand new IDE from scratch. Likewise, it's more difficult to maintain a unique IDE that supports a range of hardware and software platforms without a significant amount of money to continually fund its development. Still, plenty of room exists in the market for unique IDEs that target specific environments. Not surprisingly, more general IDEs that are open to thirdparty plug-ins continue to rise to the top. Some, such as Microsoft's Visual Studio and Green Hills Software's Multi, have a long track record of formal agreements with a number of third-party solution providers.
On the open-source side of things, Eclipse has garnered a surprising share of third parties that have created plug-ins as well as companies that have used Eclipse as the basis for their own IDE (see "A Total Eclipse," p. 54). Wind River is just one of many major vendors that has migrated from their proprietary IDEs to Eclipse.
Taking in the lay of the IDE land isn't as easy as it sounds. The wide range of features an IDE has and the support it provides make developing an IDE a difficult task. One way to approach it is via the target operating system or platform and the programming language involved (Fig. 1).
Most developers are familiar with Microsoft's Visual Studio. It handles a wide range of programming languages (due to Microsoft's support in addition to numerous third-party compiler providers), but its target platform is the Windows environment. Such linkage between an IDE and the primary vendor's platform isn't uncommon.
Although Eclipse is shown in the upper right of the software graph, specific implementations from a variety of vendors tend to fit other areas. MontaVista's DevRocket Eclipse-based IDE specifically targets MontaVista Linux. TimeSys takes a similar approach, but it customizes it even further with its LinuxLink Web-based configurator. Likewise, vendors such as AdaCore contain Eclipse plug-ins that target a range of platforms, yet they're specific to a particular language. In this case, it's Ada.
Looking at IDEs from a hardware perspective significantly changes the distribution (Fig. 2). Eclipse covers a broad range, mostly because of the number of companies that use it. Some individual companies use Eclipse-based solutions to cover their range of processors, like Freescale and its CodeWarrior product. But coverage by other vendors often isn't as broad. This view of IDEs highlights some of the more vendor-specific solutions like that in the DSP area, where Analog Devices' VisualDSP addresses the company's collection of digital signal processors (DSPs) and digital signal controllers (DSCs). The same is true for Texas Instruments' CodeComposer Studio.
As with VisualDSP++, CodeComposer is useful only for a specific set of hardware platforms; it doesn't apply to a GPU such as the Intel Pentium M. Microchip's MPlab handles Microchip's DSC and microcontroller offerings, so it's slightly higher on the chart due to the microcontroller support.
Keil and IAR primarily target the assembler, C, and C++ languages, which keep them together in the software view of the world. But they also tend to cover the same area in the hardware world.
THE COMPLEXITY CHALLENGE
IDEs tend to consist of at least an editor, a compiler tool chain, and a debugger. In the hacking days of yore, even this combination was viewed with disdain by "real" programmers who did everything from editing to debugging via a command line interface.
It's still possible to do this, but many more management, design, and diagnostic aspects are in play as programming projects become more complex. IDEs have risen to this challenge, but also at the cost of growing complexity.
Project and source-code management are mainstays within IDEs. Linkages to programming frameworks are integrated into the editors and help systems. Even bug tracking is integrated into the build and debugging process.
Initially, IDE vendors took it upon themselves to implement all of these features. The task is daunting, though, even for large companies such as IBM, Microsoft, Sun Microsystems, and Wind River. It was clear that embracing third parties was going to be the wave of the future, and it would require a plug-in architecture. The big question was how open this process would become.
Microsoft started out slowly, but Visual Studio has garnered a vast array of supporters. Keeping a system closer to the vest, like Green Hills' Multi and Freescale's CodeWarrior, allows a more selective inclusion of third parties, letting vendors look for products that will complement their core offerings. It also permits better control over integration as well as over the verification that various components will work together.
On the other hand, IBM blew this approach out of the water when it open-sourced its development tools, which eventually turned into Eclipse. In this instance, the plug-in specification, and even the underlying IDE, is available to any third party. This has created an interesting ripple through the IDE world, potentially leading to the increased complexity being addressed by the core Eclipse developers.
Standardizing the plug-in architecture standard and having the same IDE core architecture supported by a range of vendors means third parties can concentrate on the Eclipse platform. At the same time, their products can be utilized by any user working with an Eclipse-based platform. Most likely, then, developers will be able to choose their favorite sourcecode management system and use it with the desired compiler tool suite to target some arbitrary platform without resorting to three different IDEs or interfaces.
Of course, theoretical holy grails and actual practice tend to be a little rougher. Version coordination for all of the various components can wreak havoc due to the increasing number and complexity of tools. Still, it does make the overall job of integration significantly easier. It also means that IDE vendors can coordinate with a wider variety of third-party vendors with much less support overhead. In fact, this level of support differentiates the various Eclipse-based solutions.
IDEs and their related plug-ins aren't the only source of complexity, though. Embedded design is becoming more difficult, thanks to multiple core chips, mixed DSP and GPU chips, and tightly integrated networked solutions. Consequently, there's been a louder call for mixed toolsets, including debuggers targeted specifically at these mixed-processor solutions.
This trend has led to the opening of even tightly controlled support by vendors such as Texas Instruments. TI recently signed on with Green Hills so TI DSP developers would have a choice of tools as well as tools that can span mixed DSP and GPU chips (e.g., TI's DaVinci platform).
Handling this growing complexity isn't easy. Certain aspects of the process can't be eliminated, such as the support for the aforementioned multicore chips. Still, things like wizards, profiles, and improved help mechanisms can improve developers' IDE experiences by alerting them about features or simplifying how features are accessed.
Another way to keep things simple is to avoid growing the IDE into a complex, all-encompassing system (see "Keep It Simple," p. 60). A further alternative would be to target a specific environment. For example, KDevelop is designed to implement applications that run on the KDE user environment.
Microsoft and Sun do similar things with their tools, but they tend to envelop an even larger environment. As a result, these companies typically offer more tools with more inherent complexity. Microsoft's wide range of frameworks, from MFC (Microsoft Foundation Classes) to .NET, illustrates the complexity that must be supported through Visual Studio.
WHERE IS THE IMPROVEMENT?
Cheaper. Faster. And smarter? Integration has been a major improvement in IDEs. Likewise, incremental improvements in compiler tool chains have enhanced program size and efficiency, though these features tend to be relatively transparent in day-to-day IDE use.
So far, most IDE-specific enhancements involve editing, sourcecode manipulation, and screen management. Features like color coding are the norm. This goes for templates, keyword completion, and popup help for variable and function definitions.
Refactoring has become a more important feature, due to the increasing size and complexity of applications. Even simple renaming changes can break an application. Having the IDE handle this chore cuts down on potential problems, and it could reduce the number of induced bugs.
Another important aspect of IDE concerns screen management, thanks to larger monitors, multiple screens, and more powerful PCs that can switch quickly between a number of applications. The ability to see more information lets developers choose more quickly and examine more of the system, whether during editing or while debugging. Likewise, developers are having to track more information, such as the status of network makes or support for team or pair programming.
Additional screen real estate is always welcome during debugging. This is especially true for multiple task applications and multiple core debugging. More windows means more information about each task and each core.
Some systems like VisualDSP++ can add to the clutter with useful graphs that often tell more than a whole screen of numbers (Fig. 3). Unfortunately, many of these kinds of insightful features tend to be very vendor-specific.
Still, debugging seems to remain one area with limited IDE improvements. Craig Haller, president of Macraigor Systems, says that most developers tend to use the same debugging techniques from 30 years ago, from silly things like print statements to very basic use of breakpoints.
Many debuggers offer much more complex tools, but they're often unique to a particular IDE or are difficult to use. Often, they aren't used because the developer doesn't know about them. Or, the tool may be hard to use.
Tracing is a good example of an underutilized tool. Tracing was quite common in the past. The high cost of external in-circuit emulator (ICE) systems slowed its use, but it has enjoyed a resurgence as more chips incorporate trace support within the chip. Unfortunately, using trace information for debugging is even more of an art than using a regular debugger.
Tools like Green Hills Time Machine improved the situation with slick interfaces and easy-to-use analysis tools (Fig. 4). Green Hills is one of the few companies that's also managed to feed back the results of tracing to the compiler and linker for improved optimization. Inconsistent implementations of tracing support within an IDE seem to be the biggest obstacle to general use.
Some improvements to debugging have been coming from outside the IDEs. Virtutech's Simics system simulator shows how developers can gain access to more system information versus a conventional debugger, because the processor core itself is simulated. This can be very handy when targeting multicore environments. Here, the ability to stop or synchronize the system is easy with the simulator but often difficult in hardware.
Graphical programming IDEs like National Instruments' LabView hold an edge in presenting system status in a more revealing way. Most IDEs don't offer the ability to click on an object and set up a display of its status, which is updated while the application is running or when a breakpoint occurs—especially when the information is displayed in a graphical format.
Picking the right IDE remains a task with many options, even as the total number of unique platforms becomes smaller.
NEED MORE INFORMATION?