BSP Developer's Guide

VxWorks 5.5
BSP Developer’s Guide
For example:
struct aPackedStruct {
UINT32 int1;
INT16 aShort;
INT8 aByte;
} _WRS_PACK_ALIGN(1) anInstance={0x1,2,3};
/* Bits in the aByte field */
#define ABYTE_ERROR
#define ABYTE_OFLOW
#define ABYTE_UFLOW
#define ABYTE_DMA
#define ABYTE_POLL
0x01
0x02
0x04
0x08
0x10
8.1.2 In-Line Assembly
In-line assembly is a more difficult issue because it involves both the compiler and
the assembler. In Wind River’s case, the code base fortunately uses MIT assembler
syntax throughout, which many assemblers are compatible with. In-line assembly
in portable C code is by its nature not portable across architectures. Thus, the real
question for in-line assembly is compiler portability.
The current compilers differ significantly about how to include assembly
instructions without interfering with, or suffering interference from, the
compiler’s optimization efforts. In the absence of an ideal solution, in-line
assembly should only be used if it does not interact with the surrounding C code.
This means that acceptable in-line assembly does not interact with C variables or
return values. Code that cannot meet this limitation should be written entirely in
assembly language.
The vxWorks.h header file defines a _WRS_ASM macro to be used to insert in-line
assembly instructions in a C function.
For example (PowerPC):
VOID foo (void)
{
routineA (args);
_WRS_ASM(“ eieio; isync;”);
routineB (args);
}
Assume that the compiler is not free to optimize or reorder in-line assembly code
with respect to surrounding C code.
162