Amiga Executable File Format

[Sidewinder]

I'm looking for information in the format of Amiga executable files.  I'm actually interested in assembler construction and am wondering how the object files and executable files are made and read.  Does anyone know of any places where I can find information on Amiga assembler construction or object/executable file formats?

Thanks.

[peroxidechicken]

Ah, I fellow traveller of the path - I hope you brought provisions 'cause I sure didn't!  

You'd think this stuff'd be easy to find in RKMs and the like but what I know I've found out mostly by accident and by using odd little developer type utilities like Zap (v2.47 - nice little program) and another I picked up recently - Exemine.  It gives hunk information and offsets to the data of address sensitve instructions.  

Message me if you'd like me to email them to you otherwise they can be found on Aminet.  

[x303]

Maybe you wanna take a look at the source of hunkfunc to get some more indepth knowledge of hunks. I know it's not asm (it's in C), but you have to make the best of it.

[color=FF0000]x303[/color] :-D  :-D  :-D

[Thomas]

The Amiga load module file format is described in detail in the RKRM:AmigaDOS. Unfortunately this one is not contained on the Amiga Developer CD, but you can find in on the net. I think they have a copy of it on www.amigau.com.

Bye,
Thomas

[Minuous]

Actually to be exact Amiga University have a cross-site link to the file which is on my site, but that's OK, I said they could...not sure if the link is still valid though, I may have moved the file...better to go direct to my site and get it...

[Sidewinder]

Thanks for the info everyone.  I found the files mentioned and am attempting to understand the information provided.  :-D I have one (probably simple) question--In the following code, what does the Hex information after the offset mean?  :-?  For instance, the line

0004'123C 00FF       MOVE.B  #$FF,D1

The offset is 0004, but what does 123C 00FF mean?  I thought it might be the Hex representation of the machine code instruction, but when compared to my book on 68000 machine code from Motorola it doesn't seem fit the correct bit pattern for a MOVE.B instruction.

Here is the example I'm looking at:

                           IDNT    A
                           XREF    BILLY, JOHN
                           XDEF    MARY
    * The next longword requires relocation
    0000'0000 0008         DC.L    FRED
    0004'123C 00FF         MOVE.B  #$FF,D1
    0008'7001      FRED    MOVEQ   #1,D0
    * External entry point
    000A'4E71      MARY    NOP
    000C'4EB9 0000 0000    JSR     BILLY           Call external
    0012'2239 0000 0000    MOVE.L  JOHN,D1         Reference external
                           END

produces the following object file:

    hunk_unit
    00000001  Size in longwords
    41000000  Name, padded to longword
    hunk_code
    00000006  Size in longwords
    00000008  123C00FF 70014E71 4EB90000 00002239 00000000
    hunk_reloc32
    00000001  Number in hunk 0
    00000000  hunk 0
    00000000  Offset to be relocated
    00000000  Zero to mark end
    hunk_ext
    01000001  XDEF, Size 1 longword
    4D415259  MARY
    0000000A  Offset of definition
    81000001  XREF, Size 1 longword
    4A4F484E  JOHN
    00000001  Number of references
    00000014  Offset of reference
    81000002  XREF, Size 2 longwords
    42494C4C  BILLY
    59000000  (zeros to pad)
    00000001  Number of references
    0000000E  Offset of reference
    00000000  End of external block
    hunk_end

The matching program to this is as follows:

                           IDNT    B
                           XDEF    BILLY, JOHN
                           XREF    MARY
    0000'2A3C AAAA AAAA    MOVE.L  #$AAAAAA,D5
    * External entry point
    0006'4E71      BILLY   NOP
    * External entry point
    0008'7201      JOHN    MOVEQ   #1,D1
    * Call external reference
    000A'4EF9 0000 0000    JMP     MARY
                           END

and the corresponding output code would be:

    hunk_unit
    00000001  Size in longwords
    42000000  Unit name
    hunk_code
    00000004  Size in longwords
    2A3CAAAA AAAA4E71 72014EF9 00000000
    hunk_ext
    01000001  XDEF, Size 1 longword
    4A4F484E  JOHN
    00000008  Offset of definition
    01000002  XDEF, Size 2 longwords
    42494C4C  BILLY
    59000000  (zeros to pad)
    00000006  Offset of definition
    81000001  XREF, Size 1 longword
    4D415259  MARY
    00000001  Number of references
    0000000C  Offset of reference
    00000000  End of external block

Once you passed this through the linker, the load file would have the
following format:

    hunk_header
    00000000  No hunk name
    00000002  Size of hunk table
    00000000  First hunk
    00000001  Last hunk
    00000006  Size of hunk 0
    00000004  Size of hunk 1
    hunk_code
    00000006  Size of code in longwords
    00000008  123C00FF 70014E71 4EB90000 00062239 00000008
    hunk_reloc32
    00000001  Number in hunk 0
    00000000  hunk 0
    00000000  Offset to be relocated
    00000002  Number in hunk 1
    00000001  hunk 1
    00000014  Offset to be relocated
    0000000E  Offset to be relocated
    00000000  Zero to mark end
    hunk_end
    hunk_code
    00000004  Size of code in longwords
    2A3CAAAA AAAA4E71 72014EF9 0000000A
    hunk_reloc32
    00000001  Number in hunk 0
    00000000  hunk 0
    0000000C  Offset to be relocated
    00000000  Zero to mark end
    hunk_end

[PiR]

Hi

The value at the offset must be the command hex.
I don't have the 68k manual with me, but the second word 00FF suits very well the immediate argument, isn't it?  :-)

Reffering to executable format I thing you may find some interesting info in this thread.

Good luck

[Sidewinder]

Heh, my bad guys.  It is the hex of the machine code instruction.  In my conversion from hex to binary I left of a leading zero.  Sorry 'bout that.  :oops: