|Object Module Formats firstname.lastname@example.org (2001-09-05)|
|Re: Object Module Formats email@example.com (david lindauer) (2001-09-11)|
|Re: Object Module Formats firstname.lastname@example.org (Paul Carroll) (2001-09-11)|
|Re: Object Module Formats email@example.com (2001-09-11)|
|Re: Object Module Formats firstname.lastname@example.org (Aaron Gray) (2001-09-11)|
|Re: Object Module Formats email@example.com (2001-09-16)|
|Re: Object Module Formats firstname.lastname@example.org (david lindauer) (2001-09-20)|
|From:||email@example.com (Oleg T.)|
|Date:||16 Sep 2001 00:26:39 -0400|
|Posted-Date:||16 Sep 2001 00:26:39 EDT|
Hi! Thanks for all your replies!
Currently, I am going to target 68HC08 core. However, it would be nice
to have possibity to switch to another one with the same Object Format
easyly. Also, it whould be interesting to see a statistic table,
listing different CPU families and formats used more or less with each
The most suitable format should be able to be converted to another,
even if some debugging tools will require it. I would not like to get
a situation when info included into format A whould not be enough to
compose format B. For example, OMF-51 has some limitations, and
sometimes a debugger is not able to reflect actual values of a
variable. I am not sure such problem could be solved even if the
OMF-51 whould be converted to the IEEE-695 or other.
And something else. What is purpose to design an own format instead of
using some popular and standard one? I see some companies have done
it, equipping thier tools with ELF/IEEE-695/.. converters. Does it
mean thier own format is more simple, or more full than ELF/IEEE-695?
>IEEE-695 is a very nice format, very flexible and relatively easy to
>implement, but it may not be practical for the processor you are
The 68HC08 core is not listed in the IEEE-695 spec. Does it mean the
format is going to be as not practical for the core? Which CPUs are
not freandly to the IEEE-695 format?
Return to the
Search the comp.compilers archives again.