When DOS released in 1981, the assembler that came with it produced .OBJ files that were OMF format. However there was a predecessor to it, M80.COM that ran under CP/M and also used .OBJ as the file extension for object files.

Were these files also OMF, or did they use a different file format?

  • 2
    M80 typically created REL files, which were quite different - seasip.info/Cpm/rel.html – scruss Jun 20 '19 at 22:07
  • 1
    @scruss Turn that comment into an answer, and I'll mark it as the accepted solution. That said, is my memory failing me? I would have sworn that M80 turned FOO.ASM into FOO.OBJ, not FOO.REL. Mind you, this is from something around 35 years ago, so I'm a little hazy on the details. – dgnuff Jun 20 '19 at 22:13

Were these files also OMF, or did they use a different file format?

Short answer: Nope, all the same (with some extensions over the years)

The long story.

Intel originally intended PL/I to be the main language for 8008 and 8080 systems and made their PL/M compiler able to produce absolute code as well as relocatable one.

  • There where variations for each CPU, including the 8080, but the basic format was all the same.

  • The original Digital Research ASM did create Intel hex files, marked .HEX. Similar did their Macro Assembler MAC.

  • Digital's Relocating Macro Assembler (RMAC) later added the optional ability to produce relocatable output (.REL) as described in the LINK-80 manual

  • Microsoft's M80 turned assembly output by default into relocatable format as it was meant to work in cooperation with other high level languages from Microsoft which only created relocatable formats.

Microsoft as well as Digital Research used Intel's format for their relocatable formats. After all, it makes sense to be compatible as newcomer, doesn't it?

Intel called their files already .OBJ, DR decided on .REL while MS stuck with .OBJ. They are all Intel OMF with the same basic logic and encoding format for all (ofc, MS added a lot over the years - already starting with M80). In theory, even the latest (separate) MS linker should be able to decode all records and produce 8080 .COM files. In theory at least :))

P.S.: The history then continued with Microsoft switching for (their version of) COFF - which by MASM 8.0 (ca.2005) even became default format.

| improve this answer | |
  • 1
    I think you mean PL/M not PL/I (which was an IBM mainframe programming language, and having used it for several years the idea of porting it to something as tiny as an 8008 is … well, let's call it surreal! – alephzero Jun 20 '19 at 23:50
  • @alephzero Who says it was ported to 8008? To be used it just needed to target 8008 - same way it was used to target 8048 and 8051. And PL/I was rather great to generate tight code - which would be a must for the 8008 (And yes,intel's implementation was PL/M and more like PL/S or XPS then again, Kidall who did PL/M later made aswell PL/I for CP/M :)) . The smallest CPU Intel ported it to was (AFAIR) the 8080 based ISIS II systems. – Raffzahn Jun 21 '19 at 0:03
  • MAybe it depends which version of PL/I you are talking about. I remember looking at porting some PL/I apps to an "IBM compatible" mainframe that claimed to have a PL/I compiler - except that about half of the language features we were using in the IBM language weren't implemented, which killed the idea dead. The ANSI language standard didn't appear until more than 10 years after the IBM implementation. The early "Multics PL/I" was a subset. IBM produced their own subset of the language (the PL/I D compiler). – alephzero Jun 21 '19 at 13:15
  • @alephzero Sure. Not to mention, that, AFAIR, IBM as well defined several levels (or subsets) of PL/I - not to mention variants like PL/S. The point here is more about using PL/M to target an 8008/8080 than to port it. After all, most development for the real early micros happened on larger machines, with their tools, 'only' targeting the MPU. BTW, I did like PL/I and it's offsprings (like SPL). It offers a great control over data and data structures, making it quite fit to target very specific issues. – Raffzahn Jun 21 '19 at 13:35
  • 1
    There are two answers to this question. One says that files produced by M80 (whether named .OBJ or .REL) are in Intel OMF format. The other says that .REL is a completely different format. They can't both be right! The OMF definition given by Wikipedia at en.wikipedia.org/wiki/Relocatable_Object_Module_Format looks very different from .REL, so I'd be interested in seeing documentation explaining how they're the same. – john_e Jun 24 '19 at 23:52

They were .REL files, not .OBJ files. The format is fully described here. It was a bitstream containing 9-bit bytes, 18-bit addresses, and 6-bit markers some of which in their turn contained either 18-bit addresses or 3+8n-bit names or both.

I once wrote a utility which consisted of a small loader which installed the main body of the utility in high memory: thus it read the .REL file directly and relocated the code into high memory where it could be executed. An interesting exercise!

The background is that you need far more relocation in 8080 than in 8086, since in 8080 all data and program addresses are absolute, whereas in 8086 they are mostly relative, either by instruction set design (near calls and jumps are relative) or by usage (data are mostly referred to a base register rather than at absolute location). Moreover, in 8080 every bit counts, as can be seen from the format. Though they wasted bits by making the name string 3+8n bits instead of 3+7n!

| improve this answer | |
  • 1
    Relative code was also one of the benefits the Z80 had over the 8080. I could shrink my bios enough by converting to give enough space for other features. – Thorbjørn Ravn Andersen Jun 24 '19 at 12:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.