• quetzal (3/3) Jun 23 2004 Is there any reason for D compiler to use OMF object format? OMF is far ...
• Arcane Jill (13/16) Jun 23 2004 Quetzal - any chance you could explain the difference in layperson's ter...
• Arcane Jill (2/6) Jun 23 2004 I should add that I'm not questioning you. I'm merely curious.
• quetzal (15/26) Jun 23 2004 OMF was designed in late 1970 when it was absolutely necessary to save m...
• Daniel Horn (5/41) Jun 23 2004 Is this what impacts the max (16384) number of fixups in a given .obj
• Arcane Jill (14/18) Jun 24 2004 Nowadays, in this era of Unicode, identifiers for linker symbol names no...
• Charlie (3/21) Jun 24 2004 Unicode identifiers ? Dear god no... :).
• Martin M. Pedersen (6/7) Jun 25 2004 They are part of the C99 standard. If not for any other reason, D needs ...
• =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= (14/17) Jun 23 2004 There are, afaik, linkers that can work with different formats, such as
• Walter (8/11) Jun 23 2004 Good guess! I should amend that, though, that it has a lot to do with

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.

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

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.

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.

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>

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>
 
 

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

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

"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

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

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