josef@ugun21.UUCP (11/21/88)
Subject: Format of .REL files I have posted this before on a different newsgroup, have received an e-mail-response, but have lost it. So here I go again: What is the format of the (Microsoft?) .REL files that the assembler generates? All I have found out is that they seem to be bit-packed, i.e. they consist of fields that are more or less any number of bits in size. My foremost aim is to write a UN*X nm(1)-style utility for my Z-System (Steve Ciarcia's SB180FX), which is CP/M2.2 compatible. Josef Moellers paper mail: e-mail: c/o Nixdorf Computer AG USA: uunet!linus!nixbur!nixpbe!mollers.pad Abt. EG-3 !USA: mcvax!unido!nixpbe!mollers.pad Unterer Frankfurter Weg D-4790 Paderborn tel.: (+49) 5251 104691 Standard disclaimer: Blablabla opinion blablabla employer blablabla!
bill@sigma.UUCP (William Swan) (12/04/88)
In article <17700002@ugun21> josef@ugun21.UUCP writes: >What is the format of the (Microsoft?) .REL files that the assembler >generates? >All I have found out is that they seem to be bit-packed, i.e. they >consist of fields that are more or less any number of bits in size. > Josef Moellers Excerpted from Microsoft's LINK-80 (L80) manual (my additions in []): ------------------------------------------------------------------------------ "...object files consist of a bit stream. Individual fields are not aligned on byte boundaries, except as noted below. ... There are two basic types of load items: Absolute and Relocatable. The first bit of an item indicates... If the first bit is 0, the following 8 bits are loaded as an absolute byte. If the first bit is 1, the next 2 bits are used to indicate one of four types of relocatable items: [1] 00 Special LINK item. (see below) [1] 01 Program Relative. Load the following 16 bits after adding the current Program base. [1] 10 Data Relative. Load the following 16 bits [adding current] Data base. [1] 11 Common Relative. Load the following 16 bits [...] Common base. [the 1 in brackets is the 1st bit of field] Special LINK items consist of the bit stream 100 followed by: a four-bit control field an optional A field consisting of a two-bit address type that is the same as the two-bit field above [i.e. the four types of relocatable items] except that 00 specifies absolute address [instead of Special LINK Item]. an optional B field consisting of 3 bits that give a symbol length and up to [up to?] 8 bits for each character of the symbol. [The B field is a name field] A general representation of a special LINK item is: 1 00 xxxx yy nn zzz + characters of symbol name ------- -------------------------------- A field B field xxxx Four-bit control field (0-15 below) yy Two-bit address type field nn 16 bit value [should be nnnnnnnnnnnnnnnn in this notation!] zzz 3-bit symbol length field [in 8-bit characters] [The four-bit control field:] The following special types have a B-field only: 0 Entry symbol (name for search) [the name this is known by] 1 Select COMMON block 2 Program name 3 Request library search [of library named in B-field] 4 Extension Link Items (see below) The following ... have both an A field and a B field: 5 Define COMMON size 6 Chain external (A is head of address chain, B is name of external symbol). 7 Define entry point (A is address, B is name) The following ... have an A field only. 8 External - offset. Used for JMP and CALL to externals. 9 External + offset. The A value will be added to the two bytes starting at the current location counter immediately before execution. 10 Define size of Data area (A is size) 11 Set loading location counter to A 12 Chain address. A is head of chain, replace all entries in chain with current location counter. The last entry in the chain has an address field of absolute zero. 13 Define program size (A is size) 14 End Program (forces to byte boundary) The following ... has neither an A nor a B field: 15 End file. [Extension LINK item:] An Extension LINK Item follows the general format of a B-field-only special LINK item [i.e. numbers 0 through 4 above], but the contents of the B-field are not a symbol name. Instead, the symbol area contains one character to identify the type of Extension LINK item, followed by from 1 to 7 characters of additional information. Thus, every Extension LINK item has the format: 1 00 0100 zzz i jjjjjjj where zzz [3-bit integer, but 000 represents 8] i is an eight bit Extension LINK item type identifier [in bit-wise notation ought to be iiiiiiii - 256 possibilities - but see below!] jjjjjjj are zzz-1 eight-bit characters of information whose significance depends on i At present, there is only one Extension LINK item[!]: i = x'35' COBOL overlay segment sentinel zzz = 010 (binary) j = COBOL segment number - 49 (decimal) When the [this] overlay segment sentinal is encountered by the linker, the current overlay segment number is set to the value of j+49. If the previously existing segment number was non-zero and a /N switch is in effect, the data area is written to disk in a file whose name is the current program name and whose extension is Vnn, where nn are the two hexadecimal digits representing the number j+49 (decimal). " ------------------------------------------------------------------------------ There you have it. I recommend examining a .REL file or two to see how all this plays. --
wilker@batcomputer.tn.cornell.edu (Clarence W. Wilkerson Jr.) (12/05/88)
I just ported the smallc version of mac over to Turbo C on my AT. It was non-trivial to port. I would like to tinker with the .REL output to allow longer symbol names. Is there another standard relocatable format besides .rel?