home *** CD-ROM | disk | FTP | other *** search
/ Best of German Only 1 / romside_best_of_german_only_1.iso / anwender / sim / sim51_04.arj / OMF51.DOC < prev    next >
Text File  |  1993-02-01  |  18KB  |  487 lines
  1. OMF51   :   Intel Objekt-Modul-Format für 8051 Code:
  2. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  3. Dieser Text  enthät eine Beschreibung des  Intel Objekt Modul Formats  beim
  4. MCS51-Assembler ASM51, soweit er  mir bekannt ist. Der  Inhalt ist ohne Ge-
  5. währ für Richtigkeit und Vollständigkeit. Hingegen bin ich für Hinweiße auf
  6. Fehler und Ergänzungen dankbar:  Werner Hennig-Roleff, Sulzgrieser Str. 101
  7. 73733 Esslingen, 0711/376718.
  8.  
  9. Laut telefonischer Auskunft von Intel (München) gab es vor Jahren eine Dok-
  10. umentation von  Intel zum OMF,  jetzt aber  nichts mehr.  Laut Auskunft von
  11. einem Mitarbeiter von Hitex (entwickelt 8051-Emulatoren)  wäre der  OMF von
  12. Intel nicht veröffentlicht worden. Sie hätten den Code auch erst selbst ent-
  13. schlüsseln müssen.
  14.  
  15. Das Objekt-Modul-Format OMF51 wird bei 8051 Entwicklungsumgebungen  verwen-
  16. det vom
  17.  Assembler          (ASM51 von Intel / A51 von Keil) für Objekt-File Output
  18.  C-Compiler         (C51 von Keil) für Objekt-File Output
  19.  Libary Manager     (LIB51 von Intel oder Keil) für Libery-File
  20.  Linker und Locator (RL51 von Intel / L51 von Keil) für Absolut-File Output
  21.  Emulatoren        (von Hitex und Intel ICE51)
  22.  Simulatoren        (natürlich SIM51 !!!)
  23.  
  24. Objekt- und Libary-Files enthalten Code, der noch keiner festen Codeadresse
  25. zugeordnet  sein  muß  (relocateable Segmente).  In Absolut-Files ist jedes
  26. Code-Byte einer festen Adresse zugeordnet.  Adressangaben in  Absolut-Files
  27. sind  absolute  Werte.  In  Objekt- und Libary-Files sind Adressangaben nur
  28. Offsetwerte bezüglich des Segmentstarts.
  29.  
  30. Ein Absolut- sowie ein Objektfile ist aus einer Aneinanderreihung  von  Re-
  31. cords  definiert.  Jedes Record schließt sich direkt an das vorige an.  Sie
  32. besitzen folgenden prinzipiellen Aufbau:
  33.  
  34.         ┌─────┬──────────┬────────────────────┬─────┐
  35.         │ Typ │  Length  │   ...  body  ...   │ CHK │
  36.         └─────┴──────────┴────────────────────┴─────┘
  37.         (Byte)   (Word)       (n - Bytes)      (Byte)
  38.  
  39. Length    gibt die Länge des Records in Bytesanzahl an.  Der Wert wird  aus
  40.      der   Bytesanzahl   des  Record-body's  und  der  Checksumme  gebildet
  41.      (Length = n+1).  An erster Position steht  das  Low-Byte,  danach  das
  42.      High-Byte.  Es können so maximal 0FFFBh Code-Bytes in einen Record ge-
  43.      schrieben werden (siehe Typ 06).  Programme wie  OH.EXE  (Absolut-  zu
  44.      Hex-File Konverter) bearbeiten jedoch nur Records mit bis zu ca.  500h
  45.      Code-Bytes.
  46.  
  47. Der Aufbau des Record-body's ist je nach Record-Typ verschieden.
  48.  
  49. CHK  wird gebildet aus: die Quersumme über alle Bytes des Records außer CHK
  50.      selbst.  Davon das Zweierkomplement,  wobei anschließend das high Byte
  51.      vernachlässigt wird. (Zweierkomplement durch NEG AX beim 8086).
  52.  
  53. Der  oben definierte Aufbau eines Records wird bei vielen Compilern zur Er-
  54. stellung von Objekt-Files verwendet. Die Objekt-Files von Compiler für ver-
  55. schiedene CPU's unterscheiden sich im für sie definierten Satz von gültigen
  56. Record-Typen. Im folgenden werden die für den 8051 Assembler und C-Compiler
  57. definierten Record-Typen beschrieben (soweit bekannt und ohne Garantie).
  58.  
  59.                                      1
  60.  
  61. ** Modul-Start:
  62. ---------------
  63. Dieser Record definiert den Modul-Namen und steht am  Anfang  von  Absolut-
  64. und Objekt-Files.
  65.         ┌────┬────────┬────┬──────────────┬────────┬────┐
  66.         │ 02 │ Length │NaL │  .. Name ..  │   ?    │CHK │
  67.         └────┴────────┴────┴──────────────┴────────┴────┘
  68.  
  69. In NaL steht die Länge des folgenden Namens (Byteanzahl).
  70. In den dem Namen folgenden Word (?) steht meißt
  71.       00FF bei einem Absolut-File (RL51-Output) oder
  72.       00FD bei einem Objekt-File (ASM51-Output) oder
  73.       01FE bei einem C-Compiler-Objekt-File.
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80. ** Modul-End:
  81. -------------
  82. Dieser Record steht am Ende von Absolut-, Objekt- und Libary-Files.
  83.         ┌────┬────────┬────┬──────────────┬────────┬────┬────┬────┐
  84.         │ 04 │ Length │NaL │  .. Name ..  │   ?    │RegB│ ?  │CHK │
  85.         └────┴────────┴────┴──────────────┴────────┴────┴────┴────┘
  86.  
  87. In NaL steht die Länge des folgenden Namens (Byteanzahl).
  88.  
  89. Im Feld RegB sind die verwendeten Register-Banks gekennzeichnet: das lowest
  90. Bit kennzeichnet Registerbank 0 das nächste RegBnk 1,  usw. Steht eine 1 in
  91. diesem Bit, so ist die Registerbank selektiert (USING Direktrive).
  92.  
  93.    Beispiel:  0001b selektiert nur RegBnk 0
  94.               1001b selektiert RegBnk 0 und 3
  95.  
  96. In dem mit ? gekennzeichneten BYTE steht meißt 00.
  97. In den dem Namen folgenden WORD steht meißt  0000.
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104. ** Hex-Code:
  105. ------------
  106.         ┌────┬────────┬────┬────────┬───────────────┬────┐
  107.         │ 06 │ Length │SNr │  Adr   │  .... c ....  │CHK │
  108.         └────┴────────┴────┴────────┴───────────────┴────┘
  109.  
  110. Im mit ... c ... gekennzeichneten Feld steht der Hex-Code (mehrere Byte).
  111.  
  112. Im Feld Adr (Word: low Byte zuerst) ist die Adresse des ersten Codebytes in
  113. diesem Record angegeben.
  114.  
  115. SNr enthält die Segment-Nummer zu dem dieser Code gehört (siehe Typ 0E).
  116.  
  117.  
  118.  
  119.  
  120.                                      2
  121.  
  122. ** Debug-Info Heater:
  123. ---------------------
  124.         ┌────┬────────┬────┬────┬──────────────┬────┐
  125.         │ 10 │ Length │ K  │NaL │  .. Name ..  │CHK │
  126.         └────┴────────┴────┴────┴──────────────┴────┘
  127.  
  128. War bei der Assemblierung die Option Debug gewählt,  so geht  jeder  Gruppe
  129. von Records ein Heater vorraus. Der Heater gibt den Modul-Namen bekannt, zu
  130. dem  die folgenden Records gehören.  Beim C51 gibt es auch Heater mit Funk-
  131. tiuonsnamen.
  132.  
  133. In dem mit K gekennzeichneten Feld steht meißt
  134.         00    wenn globale Symbol-Definitionen folgen
  135.         03    wenn globaler Code folgt
  136.         02    wenn lokale Symbol-Definitionen folgen
  137.         05    wenn lokaler Code folgt
  138.  
  139. Die Unterscheidung in K = 02 oder 05 wurde nur beim C-Compiler  beobachtet.
  140. Beim Assembler wurde nur K = 00 oder 03 beobachtet. K = 01 trat nur bei er-
  141. weiterten OMF51 auf.
  142.  
  143.  
  144. Üblicherweise hat ein Objekt-File folgenden Aufbau:
  145.      02     Modulstart
  146.      0E     Segmentdefinitionen
  147.      18     EXTRN-Definitionen
  148.      16     PUBLIC-Definitionen
  149.      10     Heater für Symbolnamen
  150.      12     Symbolnamen
  151.      10     Heater für Code
  152.      06     Code
  153.      08     Relocation-Informationen
  154.      12     Zeilenzuordnungen
  155.      04     Modul-Ende
  156.  
  157. Verschiedene  Records  können  auch  mehrfach  vorhanden  sein.  Bei  einem
  158. Absolut-File entfallen die Typen 0E, 18, 16,  08.  Obwohl Zeilenzuordnungen
  159. vom Typ 12 sind kommen sie unter dem Code-Heater.
  160.  
  161.  
  162.  
  163.  
  164. ** Debug-Info (Symbol-Definition):
  165. ----------------------------------
  166. Ein Record kann Definitionen für mehrere Variablen beinhalten. Der mittlere
  167. Teil wiederholt sich dann.
  168.  ┌────┬────────┬────┐ ┌────┬────┬────────┬────┬────┬──────────────┐
  169.  │ 12 │ Length │S/V │ │SNr │ T  │  Wert  │ ?  │NaL │  .. Name ..  │
  170.  └────┴────────┴────┘ └────┴────┴────────┴────┴────┴──────────────┘
  171.                       :                                           :
  172.                       ┌────┬────┬────────┬────┬────┬──────────────┐ ┌────┐
  173.                       │SHr │ T  │  Wert  │ ?  │NaL │  .. Name ..  │ │CHK │
  174.                       └────┴────┴────────┴────┴────┴──────────────┘ └────┘
  175.  
  176. S/V gibt an, ob die folgende Zuordnung sich auf einen Segmentnamen oder ei-
  177. ne Variable bezieht.  Jedem Segmentnamen ist auch ein Wert zugeordnet, näm-
  178. lich der Wert der ersten Variable/Adresse  in  dem  Segment.  Achtung:  Ist
  179. S/V = 03, so enthält der Record Zeilezuordnungen (siehe unten).
  180.  
  181.                                      3
  182.  
  183.      S/V = 00  Variablen-Namen folgen
  184.      S/V = 01  public deklarierte Variablen-Namen folgen
  185.      S/V = 02  Segment-Namen folgen
  186.      S/V = 03  Adress-Zeile Zuordnungen folgen
  187.                (Achtung! anderer Record-Body!!  - siehe unten!)
  188.  
  189. SNr  enthält  die  Segment-Nummer  zu  dem  dieser Definition gehört (siehe
  190. Typ 0E).
  191.  
  192. T gibt den Typ an:    00 = CODE
  193.                       01 = XDATA
  194.                       02 = DATA
  195.                       03 = IDATA
  196.                       04 = BIT
  197.                       05 = NUMBER (EQU)
  198.  
  199. Wert (Word: low Byte zuerst) gibt die Adres