 |
||||
|
|
|
|
|
|
| Porting Software to ARM Linux Most of the software you are likely to run on the iPAQ was written in C. C is not an inherently portable language. To write portable code in C generally requires some extra thought. This HOWTO describes the common portability issues that we run into when porting applications to ARM Linux, especially from x86 Linux. C Portability Issues There are a number of areas in which the definition of a C program's behavior depend on the architecture on which the program is run. It's behavior can depend on the peculiarities of the OS, the compiler, the libraries, and the CPU. Signed vs. Unsigned Characters The C standard says that char may either be signed or unsigned by default. On x86 Linux, char is signed by default. On ARM Linux, char is unsigned by default. Comparing a char to a negative number will always return 0, because the char is unsigned and therefore positive. See ARM Linux Signed Char FAQ for more details. Pointer Alignment Issues On many CPU architectures, the memory system requires that loads of values larger than one byte must be properly aligned. Usually, this means that a 2-byte quantity must be aligned on an even address boundary, a 4-byte quantity must be aliged on a multiple of 4 boundary and sometimes 8-byte quantities must be aligned to addresses that are a multiple of 8. Depending on the CPU and the operating system, misaligned loads and stores may cause a signal, may be handled in the OS, or may be silently rounded to the appropriate boundary. The x86 boundary imposes no such alignment restriction, so some programs written for the x86 do not use the proper alignment for other architectures. ARM Linux defaults to silently round the address to the appropriate alignment boundary. This can even be a feature, because it lets you rotate values by storing and loading with different pointer alignments. (But isn't there a rotate instruction that would execute faster?) Structure Size and Alignment Issues Here's a hint. [This section will be completed at a later time./ struct foo_t { u16 x; } __attribute__ ((packed)); The packed attribute will cause the arm-linux-gcc (or the native ARM gcc) to pack the struct foo_t into 2 bytes instead of expanding it to 4 bytes. Using Memory Overlays to Convert Types This is very non-portable. The code has to be written so that alignment, size, and endianness are all correctly handled across the supported architectures. Endianness Issues There are two basic memory layouts used by most computers, designated big endian and little endian. On big endian machines, the most significant byte of an object in memory is stored at the least signicant (closest to zero) address (assuming pointers are unsigned). Conversely, on little endian machines. the least significant byte is stored at the address closest to zero. Let's look at an example: int x = 0xaabbccdd; unsigned char b = *(unsigned char *)&x; On a big endian machine, b would receive the most significant byte of x, 0xaa. On little endian machines, b would receive the least signficant byte of x: 0xdd. The x86 architecture is little endian. Many ARM processors support either mode, but usually are used in little endian mode. The Linux distribution on the Handhelds.org site is little endian. Endian problems arise under two conditions: * When sharing binary data between machines of different endianness. * When casting pointers between types of different sizes In the first case, the data appears in the correct location, but will be interpreted differently by the different machines. If a little endian machine stored 0xaabbccdd into a location, a big endian machine would read it as 0xddccbbaa. In the second case, on a little endian machine there is no problem: a char, short, or int stored in an int sized variable each have the same address. On a big endian machine, if you want to be able to store a short and then read it as an int you have to increment the pointer so that the MSB lands in the right place. Modified September 15, 2000 by [email protected] |
|
|