wampler@unmvax.UUCP (Bruce Wampler) (10/01/86)
I'm working on porting an assembler/linker to the ST, but
I can't seem to find a description of the .PRG file format. What
goes in the header - what does the file have to have to be loaded by
the GEMDOS loader? Any specifics or directions to specific parts of
the developer's documentation would be most appreciated. I will
make this assembler/linker available when it is finished.
--
Dr. Bruce E. Wampler
University of New Mexico
Department of Computer Science
Albuquerque, NM 87131
..{ucbvax | seismo!gatech | ihnp4!lanl}!unmvax!wamplersansom@trwrb.UUCP (Richard Sansom) (10/03/86)
The following was posted some time ago by J. R. Bammi via J. M. Turner:
-- cut here --
I extracted the following info. from documents that came
with the development system. I have only found the .prg (output
of relmod) format, and not the .o format. The input of
relmod is the standard cp/m-68K relocatable files, so I
guess the .o format is the same as for cp/m-68K. I am not at
all familiar with cp/m-68K, and i could not find anyting in the
documents I have about the format of .o files. Maybe you are
familiar with cp/m-68k or have access to the relevant cp/m-68k
documents. Looking forward to your PD diss assmebler.
The format for a .prg file is as Follows (word = 16 bits). Output of
relmod - 16 bit relocatable objects are not supported by Gem Dos.
14 Word Header
Text Segment Image
Data Segment Image
Symbol Table (Optional)
Relocation Info (Optional)
Header Format:
Byte Size(words) Contents
0 1 Contains 601A H Denoting Contiguous
text, data and block storage segments
2 2 Size of Text Segment - Bytes
6 2 Size of Data Segment - Bytes
10 2 Size of Block Storage Segment - Bytes
14 2 Size of Symbol Table - Bytes
18 2 Reserved - Always Zero
22 2 Reserved - Always Zero
(This is supposed to contain the
Begining of the Text Segment and
execution, but execution always begins
at the top of the Text segement, hence 0)
26 1 If Zero then Relocation info IS
present, No relocation info otherwise.
Always Zero for Gem Dos.
Symbol Table Format:
Each entry is 7 words.
Byte Size(words) Contents
0 4 Name - zero padded to 8 characters
8 1 Type
10 2 Value
Type Value
defined 8000 H
equated 4000 H
global 2000 H
equated register 1000 H
external reference 800 H
data based reloc. 400 H
text based reloc. 200 H
bss based reloc. 100 H
where:
reloc. == relocatable
A symbol with multiple characteristics has the bits OR'ed in
the type field.
The value field is the value of the symbol (address, register
number, value of an expression or some other value). When the value
field is non-zero AND the type field contains an External Symbol, the
linker interprets the value to be a common region in which the size of
the region is the value in the value field. Multiple such entries may
be present and the size of the common that the linker ultimately
decides on, is the greatest of the values, of the same name.
The nm68 utility provided with the development system can be used to
dump the symbol table.
Relocation Information:
If the last word in the header is Zero the relocation info is
present in the following format: (following symbol table if present)
Byte Size (BYTES) Contents
0 4 Offset from the beginning of the Text
Segment of the first longword needing
relocation.
4 1 Relocation offset byte
5 1 " " "
.....
xx 1 A byte containing Zero terminates
Relocation offset byte - Gives the offset to the Next longword
in the Text Segment to relocate (offset from the First Offset ) and so
on. When an offset of Zero is encountered the relocation info
is terminated. The bytes of Relocation offset give succeeding offsets.
(so the smallest legal value is 4 (size of long word)). If a
succeeding offset is greater than 254, then a byte containg One (1)
will be encountered, signifying add 254 to the previous total.
I hope that I explained the above clearly. I guess an example
is appropriate to say what i mean.
Suppose that the first longword to be relocated is at offset
128 from the begining of the text segment. The next one is at offset
132 from the begining. The next is at offset 390 from the begining
of the text segment (ie. 258 bytes from the second longword to be
relocated ), Then the relocation info looks like
byte Size(BYTES) Contents
0 4 128
4 1 4
5 1 1 (add 254)
6 1 4 (128 + 4 + 254 + 4 = 390)
and so on.
-- cut here --
__________ ______ ____ _____ ___
/_________//___ ||__|/____|/__/ Richard E. Sansom
___ ____/ / ____________ TRW Electronics & Defense Sector
/ / / /\ < | /| / One Space Park Drive, R3/1028
/ / / / \ \ | / | / Redondo Beach, CA 90278
/__/ /__/ \__\|__/ |__/ {...decvax,ucbvax,ihnp4}!trwrb!sansom