Amiga Hunk

From Just Solve the File Format Problem
(Difference between revisions)
Jump to: navigation, search
(Category:Amiga)
 
(2 intermediate revisions by one user not shown)
Line 12: Line 12:
  
 
== Structure ==
 
== Structure ==
The loadable format begins with a fixed header, followed by a series of ''hunks''. each one of which is considered an independent ''segment'' by AmigaDOS. These hunks can either be code, data, or zeroed memory (BSS).
+
=== Loadable format ===
 
+
Hunks themselves can contain optional ''blocks'', for code relocations and debug symbols.
Hunks themselves can contain optional ''blocks'', including code relocations and debug symbols.
+
  
 
All Amiga programs share the same address space and are loaded to wherever there is free memory. They cannot be loaded to specific absolute addresses. This means code must either be written in a position-independent fashion, or it can use ''relocation'' blocks to specify where the loader has to fix up absolute address references.
 
All Amiga programs share the same address space and are loaded to wherever there is free memory. They cannot be loaded to specific absolute addresses. This means code must either be written in a position-independent fashion, or it can use ''relocation'' blocks to specify where the loader has to fix up absolute address references.
  
 
Amiga programs do their own dynamic linking with OS functions such as <tt>OpenLibrary</tt>, which loads and returns a pointer to a shared library, whose functions can then be executed by jumping to specific offsets from the pointer. This is unlike Windows and UNIX where the loader is expected to fetch and link in other libraries while loading the program.
 
Amiga programs do their own dynamic linking with OS functions such as <tt>OpenLibrary</tt>, which loads and returns a pointer to a shared library, whose functions can then be executed by jumping to specific offsets from the pointer. This is unlike Windows and UNIX where the loader is expected to fetch and link in other libraries while loading the program.
 +
 +
The loadable format is limited compared to the object code format. Many types of hunk and block are intentionally unrecognised by the AmigaOS <tt>LoadSeg()</tt> function in order to keep the core OS complexity low. The format is as follows:
 +
 +
* A fixed header (HUNK_HEADER) including a count of all hunks to follow and their lengths
 +
* One or more HUNK_CODE, HUNK_DATA or HUNK_BSS hunks, each of which comprises:
 +
** The code/data for a code/data hunk
 +
** Zero or more blocks for this hunk: all can have HUNK_SYMBOL or HUNK_DEBUG blocks. Code/data can also have HUNK_RELOC32, HUNK_RELOC32SHORT, HUNK_DREL32 or HUNK_ABSRELOC16 relocation blocks
 +
** Hunks always end with a HUNK_END block
 +
 +
The load format also supports ''overlays'' (HUNK_OVERLAY and HUNK_BREAK), where the file is not fully loaded, but control is passed to an ''overlay manager'', which can then decide to load or unload hunks at any time, allowing a program to be much larger than would fit in memory, provided the program can keep track of which of its parts need to be in RAM at any given them. There is a "standard" overlay manager and overlay format, but programs do not have to use it.
  
 
== Format specification ==
 
== Format specification ==
Line 24: Line 33:
 
* Ralph Babel. "The Format of Load and Object Modules" ''The Amiga Guru Book'', self-published, 1993, p657-682
 
* Ralph Babel. "The Format of Load and Object Modules" ''The Amiga Guru Book'', self-published, 1993, p657-682
 
* http://amiga-dev.wikidot.com/file-format:hunk
 
* http://amiga-dev.wikidot.com/file-format:hunk
 +
 +
[[Category:Amiga]]

Latest revision as of 19:34, 14 May 2018

File Format
Name Amiga Hunk
Ontology
Extension(s) (none), .library, .device, .datatype, .o, .lib

The Amiga Hunk format is the native file format of AmigaOS for loadable files (including all executable files), object code and link libraries.

Contents

[edit] Identification

Loadable files begin with the magic ID 00 00 03 F3. "Loadable" includes all directly executable files, as well as shared libraries, device drivers, filesystem handlers, datatypes and other "plugins".

Object code and link libraries begin with the magic ID 00 00 03 E7. These files have to be combined into a loadable file using a linker to get an executable program.

[edit] Structure

[edit] Loadable format

Hunks themselves can contain optional blocks, for code relocations and debug symbols.

All Amiga programs share the same address space and are loaded to wherever there is free memory. They cannot be loaded to specific absolute addresses. This means code must either be written in a position-independent fashion, or it can use relocation blocks to specify where the loader has to fix up absolute address references.

Amiga programs do their own dynamic linking with OS functions such as OpenLibrary, which loads and returns a pointer to a shared library, whose functions can then be executed by jumping to specific offsets from the pointer. This is unlike Windows and UNIX where the loader is expected to fetch and link in other libraries while loading the program.

The loadable format is limited compared to the object code format. Many types of hunk and block are intentionally unrecognised by the AmigaOS LoadSeg() function in order to keep the core OS complexity low. The format is as follows:

  • A fixed header (HUNK_HEADER) including a count of all hunks to follow and their lengths
  • One or more HUNK_CODE, HUNK_DATA or HUNK_BSS hunks, each of which comprises:
    • The code/data for a code/data hunk
    • Zero or more blocks for this hunk: all can have HUNK_SYMBOL or HUNK_DEBUG blocks. Code/data can also have HUNK_RELOC32, HUNK_RELOC32SHORT, HUNK_DREL32 or HUNK_ABSRELOC16 relocation blocks
    • Hunks always end with a HUNK_END block

The load format also supports overlays (HUNK_OVERLAY and HUNK_BREAK), where the file is not fully loaded, but control is passed to an overlay manager, which can then decide to load or unload hunks at any time, allowing a program to be much larger than would fit in memory, provided the program can keep track of which of its parts need to be in RAM at any given them. There is a "standard" overlay manager and overlay format, but programs do not have to use it.

[edit] Format specification

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox