Motorola dsp assembler Reference Manual

Motorola DSP Object File Format (COFF)
Object File Components
E-26
DSP ASSEMBLER REFERENCE MANUAL
MOTOROLA_DSP_ASSEMBLER_REFERENCE_MANUAL_E-27_Figure_E-27_Structure,_Union,_or_Enumeration_Name_Auxiliary_Entry_E.3.4.7_Object_File_Comments'>MOTOROLA
E.3.4.6.8  Beginning of Blocks and Functions
The format for C language symbol entries for the beginning of blocks and functions is de-
scribed in Figure E-26. The source file line number is retained. The x_endndx provides a
link to the next beginning of block or function symbol in the symbol table.
Figure E-26 Beginning of Block or Function Auxiliary Entry
E.3.4.6.9  Structure, Union, and Enumeration Names
The format for auxiliary entries related to structure, union, and enumeration names is giv-
en in Figure E-27. The tag index is used to access the tag symbol record that describes
this structure. Note that in Motorola DSP COFF the size of the associated structure or
union is in words as opposed to bytes as in standard COFF.
Bytes
Declaration
Name
Description
    0-3
-
-
Unused (zero filled)
    4-7
unsigned long
x_lnno
Source file line number
  8-15
-
-
Unused (zero filled)
16-19
long int
x_endndx
Index of next beginning of
block or function
 20-23
unsigned long
x_type
Function prologue/epilogue index
24-31
-
-
Unused (zero filled)

---

Motorola DSP Object File Format (COFF)
Differences In DSP Object Format And Standard COFF
MOTOROLA
DSP ASSEMBLER REFERENCE MANUAL
E-27
Figure E-27 Structure, Union, or Enumeration Name Auxiliary Entry
E.3.4.7  Object File Comments
Object file comments are stored in a single COFF symbol table entry. The symbol name
field contains the special comment string .cmt. The n_address field points to the com-
ment text as an offset into the string table. Comments generated automatically by the As-
sembler or via the IDENT directive have an n_scnum field with value of -1. Comments
produced with the COBJ directive generally have the section number of the COFF section
in which they reside. The type and storage class fields are both zero.
E.3.5   String Table
Symbol and section names longer than seven characters and comment text are stored
contiguously in the string table with each string delimited by a zero byte.  The first four
bytes represent the size of the string table in bytes; offsets into the string table, therefore,
are always greater than or equal to 4.  An empty string table has a length field with value
zero.
E.4
  DIFFERENCES IN DSP OBJECT FORMAT AND STANDARD COFF
Motorola DSP COFF is substantially the same as generic COFF and usage of format el-
ements is similar.  However, the original COFF specification did not envision aspects of
machine architecture which the Motorola DSP family possesses.  Moreover, standard
COFF encompasses a file format which is quite adaptable among host processors, but is
not necessarily portable among those hosts.   It is straightforward enough to adapt COFF
to a new host machine, but the intent is that the derived host format will be recognized and
executed only on that target host.  For Motorola DSP COFF the format had to be extended
for cross-development such that a given object file would be usable on all targeted host
systems.  The following sections outline the differences and changes between standard
COFF and Motorola DSP COFF.
Bytes
Declaration
Name
Description
    0-3
long int
x_tagndx
Tag index
    4-7
-
-
Unused (zero filled)
  8-11
unsigned long
x_size
Size of structure, union, or
enumeration in words
12-31
-
-
Unused (zero filled)

---

Motorola DSP Object File Format (COFF)
Differences In DSP Object Format And Standard COFF
E-28
DSP ASSEMBLER REFERENCE MANUAL
MOTOROLA
E.4.1   Multiple Memory Spaces
Standard COFF has no built-in mechanism for accommodating multiple memory spaces.
It does handle the notion of separate text and data sections, and a possible extension
would have been to define section types for the new memory areas.  This quickly be-
comes unwieldy when mapping information (internal, external, port A/B) is considered as
well.
The solution was to extend addressing information to include the memory and mapping
with the address value itself. This is done by defining a C language typedef called
CORE_ADDR which holds both the memory and mapping data along with the memory ad-
dress. For any address context in the COFF file a CORE_ADDR is used rather than, for
example, an unsigned long. A description of the CORE_ADDR format is shown in Figure
E-28.
Figure E-28 CORE_ADDR Format
The enumeration values for the memory mapping field are shown in order in Figure E-29.
Bytes
Declaration
Name
Description
    0-3
long
w0.l
Memory address
    4-7
enum
w1.mape
Memory mapping

---

Motorola DSP Object File Format (COFF)
Differences In DSP Object Format And Standard COFF
MOTOROLA
DSP ASSEMBLER REFERENCE MANUAL
E-29
Figure E-29 Memory Mapping Enumerations
E.4.2   Object File Transportability
There are many different structure definitions in the COFF specification.  These definitions
consist of fields comprised of varying C data types.  These data types are recognized by
any reasonable C compiler, but their characteristics and sizes may change from machine
to machine.  This is acceptable if the COFF files are to be used only on a particular ma-
chine architecture.  But if COFF files are produced on one machine to be used on another
several problems may arise.  One is that since the data fields can vary in size there could
be alignment problems when accessing structures or individual fields.  Another issue is
byte ordering between machines.  Given an arbitrary byte stream, some machines store
the bytes in a word starting at the least significant bit (LSB) end of the word, while others
store bytes starting at the most significant bit (MSB) end of the word.
Mnemonic
Value
Mnemonic
Value
memory_map_p
0
memory_map_xa
16
memory_map_x
1
memory_map_xb
17
memory_map_y
2
memory_map_xe
18
memory_map_l
3
memory_map_xi
19
memory_map_none
4
memory_map_xr
20
memory_map_laa
5
memory_map_ya
21
memory_map_lab
6
memory_map_yb
22
memory_map_lba
7
memory_map_ye
23
memory_map_lbb
8
memory_map_yi
24
memory_map_le
9
memory_map_yr
25
memory_map_li
10
memory_map_pt
26
memory_map_pa
11
memory_map_pf
27
memory_map_pb
12
memory_map_emi
28
memory_map_pe
13
memory_map_e0-63
29-92
memory_map_pi
14
memory_map_error
666666
memory_map_pr
15

---