Monday, March 29, 2010

Why Target Emulation?

In a word: convenience, but in two respects. The first convenience is that the target board is likely being developed at the same time as the software that’s supposed to run on the board. Second, running in an emulator greatly reduces the complications of communicating with a remote target.

A common practice in embedded engineering is to write code that is compiled and tested on the development host. This makes sense, because the C language is portable enough to make this possible. Although large amounts of code can be written, compiled using the native tools, and tested without the benefit of an emulator, some things, such as the following, require testing using the target processor or emulator:

• Inline assembly: This is the most obvious. Code that has inline assembly for an ARM target won’t compile on that nice new quad core Intel 64 bit host, no matter how much you want it to.

• Endiannesss: This describes the byte order used to store data. In a big-endian system, the high-order bytes precede the low-order bytes; little-endian is the reverse. The date 2009-01-31 is big endian, whereas 31-01-2009 is little-endian.1 If endianness isn’t agreed on, imagine the confusion with a date like 02-05-2009, where the month and day aren’t obvious. This is an example to make plain the notion that endianness, as the internal storage format for a date in a computer, is usually an integer.

• Floating point: The floating-point capacities aren’t the same for all processors and the emulator. One processor’s very large number is another processor’s overflow. Not many embedded systems need high precision, but the ones that do should take these limitations into consideration.

• Optimization: The GCC compiler is smart enough to optimize not only by refactoring and re-ordering the code but also by selecting machine instructions that execute more quickly. This means the classic speed for time optimization may be very different on the host than the target. Optimization is also likely to find bugs in the code generated by GCC

Source of Information : Pro Linux Embedded Systems

No comments: