www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - obj file format

reply quetzal <quetzal_member pathlink.com> writes:
Is there any reason for D compiler to use OMF object format? OMF is far more
complicated than other formats (ELF or PE). Sure, there are reasons for such
complexity, but nowadays it causes more troubles than good.
Jun 23 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cbbcv1$28d0$1 digitaldaemon.com>, quetzal says...
Is there any reason for D compiler to use OMF object format? OMF is far more
complicated than other formats (ELF or PE). Sure, there are reasons for such
complexity, but nowadays it causes more troubles than good.

Quetzal - any chance you could explain the difference in layperson's terms? In what way is OMF more complicated than ELF or PE? I'd be really intrigued to know that. In any case, I must /assume/ that the output of DMD is an artifact of this particular compiler, not of the D language itself. If D is successful, then one day, there will be Microsoft Visual D, Gnu-D, Borland D, and a whole host of other D compilers, and presumably, these will use whatever object format they deem fit, so I /assume/ this is nothing more than an implementation issue. In which case, presumably one can write (or there may even already exist) a conversion tool from OMF to ELF or PE, should you require the latter format. But I still don't understand why it matters? Any chance you could fill me in? Arcane Jill
Jun 23 2004
next sibling parent Arcane Jill <Arcane_member pathlink.com> writes:
In article <cbbe18$2a42$1 digitaldaemon.com>, Arcane Jill says...

In which case, presumably one can write (or there may even already exist) a
conversion tool from OMF to ELF or PE, should you require the latter format. But
I still don't understand why it matters? Any chance you could fill me in?

Arcane Jill

I should add that I'm not questioning you. I'm merely curious.
Jun 23 2004
prev sibling parent reply quetzal <quetzal_member pathlink.com> writes:
Quetzal - any chance you could explain the difference in layperson's terms? In
what way is OMF more complicated than ELF or PE? I'd be really intrigued to know
that.

and disk space. To do so OMF divides file into small sections which are processed in sequence (each section even has a checksum byte.. but that's another paper tape story) and utilizes several techniques to make those sections as small as possible: all strings are variable length ones (with length byte going first), all strings are being indexed and even indice size is different (one or two bytes depending on value), i'd even say that everything is indiced there. Also format itself was developed for 16bit microprocessors and current Intel OMF (that is used by D) is a union of original one and several extensions (to make it work on 32bit systems). I really see no reasons to support it anymore, there are better formats anyways.
In any case, I must /assume/ that the output of DMD is an artifact of this
particular compiler, not of the D language itself. If D is successful, then one
day, there will be Microsoft Visual D, Gnu-D, Borland D, and a whole host of
other D compilers, and presumably, these will use whatever object format they
deem fit, so I /assume/ this is nothing more than an implementation issue.

becomes pretty annoying. For example I got problems when I tried to link .obj files produced by masm into my D project.
In which case, presumably one can write (or there may even already exist) a
conversion tool from OMF to ELF or PE, should you require the latter format. But
I still don't understand why it matters? Any chance you could fill me in?

Jun 23 2004
next sibling parent reply Daniel Horn <hellcatv hotmail.com> writes:
Is this what impacts the max (16384) number of fixups in a given .obj 
file. That's making it necessary to split up certain files in a lib I 
was writing (i.e. have like 4 different functions for template 
instantiations)--reminds me of VC6.0 :-/

quetzal wrote:
Quetzal - any chance you could explain the difference in layperson's terms? In
what way is OMF more complicated than ELF or PE? I'd be really intrigued to know
that.

OMF was designed in late 1970 when it was absolutely necessary to save memory and disk space. To do so OMF divides file into small sections which are processed in sequence (each section even has a checksum byte.. but that's another paper tape story) and utilizes several techniques to make those sections as small as possible: all strings are variable length ones (with length byte going first), all strings are being indexed and even indice size is different (one or two bytes depending on value), i'd even say that everything is indiced there. Also format itself was developed for 16bit microprocessors and current Intel OMF (that is used by D) is a union of original one and several extensions (to make it work on 32bit systems). I really see no reasons to support it anymore, there are better formats anyways.
In any case, I must /assume/ that the output of DMD is an artifact of this
particular compiler, not of the D language itself. If D is successful, then one
day, there will be Microsoft Visual D, Gnu-D, Borland D, and a whole host of
other D compilers, and presumably, these will use whatever object format they
deem fit, so I /assume/ this is nothing more than an implementation issue.

Sure. But majority of windows compilers use COFF and this "implementation issue" becomes pretty annoying. For example I got problems when I tried to link .obj files produced by masm into my D project.
In which case, presumably one can write (or there may even already exist) a
conversion tool from OMF to ELF or PE, should you require the latter format. But
I still don't understand why it matters? Any chance you could fill me in?

I tried by best.. looks messy but quite understandable. <g>

Jun 23 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
quetzal wrote:
 
 OMF was designed in late 1970 when it was absolutely necessary to save memory
 and disk space.


Nowadays, in this era of Unicode, identifiers for linker symbol names no longer have to be pure ASCII. If you want a linker symbol consisting entirely of Chinese or Russion letters, this is not a problem. Of course, D does not /generate/ such symbols, since it has its own rules for identifier syntax. However, another compiler (say, for a different, possibly future, language) might. These international identifiers would end up in a .obj file somewhere. Presumably, then, we would want D to be able to link against such .obj files. I believe that ELF format can cope with Unicode identifier names. I'm not sure about OMF or the others - maybe someone else could clarify. In any case, I think that the DMD compiler/linker ought to be able to cope with these modern ideas, so either it does already, or a quick rethink might be in order. Arcane Jill
Jun 24 2004
parent reply Charlie <Charlie_member pathlink.com> writes:
Unicode identifiers ?  Dear god no... :).

Charlie

In article <cbeb7j$me0$1 digitaldaemon.com>, Arcane Jill says...
quetzal wrote:
 
 OMF was designed in late 1970 when it was absolutely necessary to save memory
 and disk space.


Nowadays, in this era of Unicode, identifiers for linker symbol names no longer have to be pure ASCII. If you want a linker symbol consisting entirely of Chinese or Russion letters, this is not a problem. Of course, D does not /generate/ such symbols, since it has its own rules for identifier syntax. However, another compiler (say, for a different, possibly future, language) might. These international identifiers would end up in a .obj file somewhere. Presumably, then, we would want D to be able to link against such .obj files. I believe that ELF format can cope with Unicode identifier names. I'm not sure about OMF or the others - maybe someone else could clarify. In any case, I think that the DMD compiler/linker ought to be able to cope with these modern ideas, so either it does already, or a quick rethink might be in order. Arcane Jill

Jun 24 2004
parent "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"Charlie" <Charlie_member pathlink.com> wrote in message
news:cbfvcn$2nn$1 digitaldaemon.com...
 Unicode identifiers ?  Dear god no... :).

They are part of the C99 standard. If not for any other reason, D needs them in order to be link-compatible with C. Regards, Martin M. Pedersen
Jun 25 2004
prev sibling parent reply =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
quetzal wrote:

 Sure. But majority of windows compilers use COFF and this "implementation
issue"
 becomes pretty annoying. For example I got problems when I tried to link .obj
 files produced by masm into my D project.

There are, afaik, linkers that can work with different formats, such as ALink (OMF/Win32COFF: http://alink.sourceforge.net/), WLink (OMF/Win32COFF/ELF - comes with Watcom C++ which iirc is available for free these days? (not sure)), and TLink32(OMF/Win32COFF: comes with Borland compilers, and ought to be available for free afaik). I've never used any of these myself, so I can't vouch for how they work, but it should be possible to mix OMF/COFF with a certain level of convenience. I'm guessing Walter's sticking to OMF has something to do with the fact that the Digital Mars backend can produce 16 bit/32 bit DOS/Windows executables, a feature that in some cases can be very handy. Cheers, Sigbjørn Lund Olsen
Jun 23 2004
parent "Walter" <newshound digitalmars.com> writes:
"Sigbjørn Lund Olsen" <sigbjorn lundolsen.net> wrote in message
news:cbcle4$16ni$1 digitaldaemon.com...
 I'm guessing Walter's sticking to OMF has something to do with the fact
 that the Digital Mars backend can produce 16 bit/32 bit DOS/Windows
 executables, a feature that in some cases can be very handy.

Good guess! I should amend that, though, that it has a lot to do with compatibility with existing OMF tools for both 16 and 32 bits. BTW, the back end can produce ELF format, otherwise the linux DMD would not work. I'm painfully aware of the inadequacies of OMF, but I'm stuck with it for the foreseeable future.
Jun 23 2004