Solaris SPARC to Solaris x86 Porting Guide

Solution: For the resolution of shared memory issues such as memory-mapped graphics adapters, the
multi-byte values can be explicitly byte-swapped before storing to, or after loading from, the opposite
endian device.
Another solution to the shared memory problem due to the endianness of the processor is the use of
apertures for different endianness. One example is a PCI-based graphics adapter using a little-endian
processor internally. The adapter can provide two apertures (ranges of addresses) for its frame
buffers.
If an adapter accesses the little-endian aperture, the system stores the data as it is presented on the
bus and moves it directly into the frame buffer. In contrast, if an adapter accesses the big-endian
aperture, the system swaps the data bytes before storing the data. Thus, if the application is running
on a little-endian processor, it can simply map the little-endian aperture while the application running
on a big-endian processor maps itself to the big-endian aperture.
A host processor can also provide endian translation apertures. UltraSPARC processors handle
endianness through allowing independent assignment of endianness to each mapped page. For
example, if a file that contains x86 data were mapped into memory in little-endian mode on an
UltraSPARC chip, the data would be transparently swapped as it was loaded from or stored to the
memory into which the file was mapped. This mechanism solves the issues associated with shared
memory if data is properly aligned.
Storage order differences
The order of storage of the data varies between platforms. A code written assuming a particular
storage order is not portable. The following code sample assumes that the year component may be
stored before the month component. This code works on x86 machines but does not work properly on
UltraSPARC machines:
struct date {
char year;
char month;
char day;
char dummy; // Added so that the struct var size is 4
} planned_date, end_date;
if ( (*(long * )&end_date ) > (*(long *)&planned_date))
{
printf("Sorry, You missed the deadline to support Solaris x86
platform \n");
}
Solution: Portable code must compare the individual fields of the structure variables separately and
not rely on any storage order as in the following example:
if (compare_dates(end_date, planned_date) > 0)
{
printf("Sorry, You missed the deadline to support Solaris x86
platform \n");
}
int compare_dates(struct date date_to_compare,
struct date date_compare_against)
{
if (date_to_compare.year != date_compare_against.year)
return (date_to_compare.year - date_compare_against.year);
if (date_to_compare.month != date_compare_against.month)
6