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.

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

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.

>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>

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>
> 
> 

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

"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.

>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

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
>
>

"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