|
|
Chapter 10 Porting Software to the MIPS Architecture
Very few project require absolutely all of their software to be created from
scratch; the vast majority make use of at least some code that already exists
——at the application level, in the operating system, or both. You may well
find, however, that the existing code you`d like to use in your MIPS system
was originally developed for some other microprocessor family. Of course, at
a minimum, you`ll need to recompile the source code to create a new set of
binaries for MIPS; but as we`ll see, the task may be more complicated than
that. Portability refers to the ease with which a piece of software can be
transferred successfully and correctly to a new environment, particularly a
new instruction set. Porting a substantial body of software is rarely easy,
and the level of difficulty tends to rise sharply if the software in question
is (or includes) an OS or OS-related software such as device drivers.
High-level software(Linux application code or the like) will typically have
been writen with at least some notion of portability and will quite probably
have been used in several environments already, so there`s a reasonable
likelihood that you`ll be able to recompile it without having to make changes.
Low-level software——perhaps a large portion of the source code, for some
embedded systems—— is more troublesome. Software that has been developed
exclusively in just one particular environment is especially likely to present
portability problems, since its creators may not have recognized any particular
need to avoid or resolve them. The object of this chapteris to draw your
attention to areas that are particularly likely to cause problems when you`re
porting software to MIPS.
The parts of a system that drive the lowest-level hardware are inevitably
nonportable; embedded systems are typically subject to significant design upgrades
every couple of years or so , and it`s just not reasonable (and certainly not cost
effective) to insist that the original hardware/software interfaces be preserved
throughout such changes.
<font color=blue>10.1 Low-level Software for MIPS Applications: A Checklist of Frequently Encountered Problems.
The following are problems that have come up faily frequently:
>> Endianness: The computer world is divided into little- and big-endian camps
and a gulf of incomprehension falls between them. Most MIPS CPUs can be set
up to run either big-endian or little-endian; but even if you already know
which way your MIPS system will be configured, it`s strongly recommendded
that you make sure you understand this issue thoroughtly. It`s caught out
many experienced developers before you, and it will catch out some more.Read
about it in section 10.2.
>> Data layout and alignment in memory: Your program may make unportable
assumptions about the memory layout of data declared in C.It`s almost always
unportable to use C struct declarations to map input files or data received
through a communication link, for example.Danger can lurk in a program that
employs multiple views of private data with differently typed pointers or
unions.
However, data layout goes together with a description of other conventions
(for register use, argument passing, and stack handling) and you`ll find
that in the next chapter: If you need to take a peek ahead, it`s in section
11.1.
>> Need for explicit cache management: You may find that code you`d like to reuse
was developed for a microprocessor that didn`t implement caches at all, or
one that used a CPU with caches that are "invisible" to software(almost all
side effects of caching in PC-compatible processors are hidden by clever
hardware, for instance). But most MIPS CPUs keep their hardware simple by
letting some side effects remain visible and making software responsible for
cache management;we`ll describe what this means in section 10.3
>> Memory access ordering and reordering: In many modern embedded or consumer
systems, data moving around the system may pass through a chain of subsystems
as it moves from its source to its final destination.Those subsystems may
themselves encapsulate a lot of complicated hardware, and may present you
with unexpected problems. For example, pieces of information passed between
the CPU and I/O devices may be forced to wait in queues, incurring variable
amounts of delay; or thay may be separated into several independent traffic
streams, so the order in which they arrive at their respective destinations
can`t be guaranteed to match the order in which they were originally sent.
Typical problems and solutions are discussed in section 10.4.
>> Writting it in C:This is not so much a problem as an opportunity. But there
are things you can do in C(and probably should do in preference to writing
assembly code)that are fairly MIPS-specific. This section talks about inline
assembly, using memory-mapped registers, and a ragbag of possible pitfalls
using MIPS.
10.2 Endianness: Words, Bytes and Bit Order
The word endianness was introduced to computer science by Danny Cohen(Cohen 1980).
In an article of rare humor and readability, Cohen observed that computer architectures
had divided up into two camps, based on an arbitrary choice of the way in which byte
addressing and integer definitions are related in communications systems.
In Jonathan Swift`s Gulliver`s Travels, the "little-endians" and "big-endians"
fought a war over the correct end at which to start eating a boiled egg. Swift was
satirizing 18th-century religious disputes, and neither of his sides can see that
their difference is entirely arbitrary.Cohen`s joke was appreciated, and the word has
stuck. The problem is not just relevant to communications; it has implications for
portability too.
Computer programs are always dealing with sequence and order of different types
of data:iterating in order over the characters in a string, the words in an array,
or the bits in a binary representation. C programmers live with a pervasive assumption
that all these variables are stored in a memory that is itself visible as a sequence
of bytes-memcpy() will copy any data type.And C`s I/O system models all I/O operations
as bytes; you can also read() and write() any chunk of memory containing any data type.
So one computer can write out some data, and another computer can read it;suddently,
we`re interested in whether the second computer can understand what the first one wrote.
We understand that we need to be careful with padding and alignment(details in
section 11.1). And it`s probably too much to expect that complex data types like
floating-point numbers will always transfer intact. But we`d hope at least to see simple
twos complement integers coming across OK; the curse of endianness is that they don`t.
The 32-bit integer whose hexadecimal value was written as 0x1234.5678 quite often reads
in as 0x7856.3412--it`s been "byte-swapped." To understand why, let`s go back a bit.
10.2.1 Bits, Bytes, Words, and Integers
Building...
Please stand by...
10.2.2 Software and Endianness
Building...
Please stand by...
10.2.3 Hardware and Endianness
Building...
Please stand by...
10.2.4 Bi-endian Software for a MIPS CPU
Building...
Please stand by...
10.2.5 Portability and Endianness-Independent Code
Building...
Please stand by...
10.2.6 Endianness and Foreign Data
Building...
Please stand by...
10.3 Trouble with Visible Caches
Building...
Please stand by...
10.4 Memory Access Ordering and Reordering
Building...
Please stand by...
10.5 Writing it in C
Building...
Please stand by...
</font> |
|
发表于 2008-8-27 17:44:11
楼主
