Electronic Design

Dynamic Binary Translation Delivers Program Portability

Program portability is coming to an embedded processor near you, courtesy of Transitive Technologies' dynamic binary translation software, Dynamite. This San Diego company has demonstrated Dynamite x86 application code on a MIPS processor. The technology will be available in 2002, including support for most source and host processor architectures.

Dynamic binary translation is promising because it lets designers transition applications to new environments and faster processors. It also can preserve investments in existing code. Product delivery times can be shortened by enabling existing applications to be used on new platforms. These applications may be recoded for the new platform if warranted, but Dynamite would permit more time for this to occur. Also, Dynamite is useful where application source code is not available.

Dynamite takes an incremental approach similar to that used by Transmeta with its Cruso line of x86 processors. There are a number of significant differences, though. First, Dynamite doesn't require a custom very-long-instruction-word (VLIW) processor. Second, Transmeta's translation is a one-step process, while Transitive uses a two-step process. Third, Dynamite allows individual applications to run on a host processor in conjunction with native applications, whereas Cruso completely hides the underlying VLIW architecture from even the operating system. Finally, Transitive is targeting a range of source and host processor architectures, not just one set.

The Dynamite software actually targets a different environment than Cruso. While Cruso is an x86-compatible processor, Dynamite permits a foreign application or operating system to run on the host processor in addition to native applications and operating systems. This lets existing applications run on new embedded systems.

Dynamite starts first when a foreign application is run on a host processor. It creates two caches (see the figure): one for intermediate code blocks, and one for executable code blocks. Blocks are sequential collections of source instructions that end in a jump. These are translated to an intermediate code block that is placed in the first cache as the application begins to run. The intermediate code is then translated to native host code and placed in the second cache, where application execution actually occurs.

Dynamite uses the same intermediate code on all platforms. This allows the same front-end translator for a particular source architecture to be used on any platform. Likewise, a single native code translator is needed for a particular host platform. Dynamite applies conventional compiler optimizations to the front- and back-end translations.

Dynamite monitors block execution patterns and frequency so it can identify a group of blocks that would benefit from additional optimizations. It then assigns these blocks to a background task that takes the intermediate code blocks and generates a new optimized code block. In theory and in practice, the new block executes faster.

Then, Dynamite adjusts its configuration to use the new block and frees the old blocks in both caches. The application is only interrupted during the transition from using the old and new code. The intermediate cache eliminates the need to regenerate intermediate code for subsequent optimizations.

Blocks are also removed from the cache when the cache is full and a new block must be executed. The least recently used blocks are removed to make room for the new block. Blocks are actually removed in pairs, one from each cache, since an intermediate code block is always needed for an executable code block should subsequent optimizations be required.

Typically, Dynamite performs translation on demand. But it is possible to do some of this work before an application is started. This minimizes startup latency and is important for real-time embedded applications.

Application-code translation is just part of the job. The other part is providing an interface between the source and the host services. For example, an application normally needs access to a file system or network interface that is normally provided by the operating system that runs the application. Transitive's FUSE (flexible user system environment) technology makes this happen. Transitive has FUSE definitions for Linux, and developers can write new definitions for other environments.

Transitive is taking a number of different approaches to incorporating Dynamite into an embedded environment. One way is to make Dynamite part of the host services and identify foreign applications that Dynamite must process. Another alternative is to encapsulate Dynamite in a host executable file that also includes the desired foreign application.

More information about Dynamite can be found at www.transitives.com.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.