|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:||david lindauer <email@example.com>|
|Date:||20 Sep 2001 00:27:37 -0400|
|References:||01-09-019 01-09-055 01-09-058|
|Posted-Date:||20 Sep 2001 00:27:37 EDT|
"Oleg T." wrote:
> 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?
You are probably going to find that most 8-bit processors will adapt
easily to IEEE-695... however there may be some problems with
bit-oriented architectures like the 8051 bit accessible memory. The
primary problem with this format is that it doesn't readily lend
itself to segmented architectures like the x86 in real mode, or the
C167. Although I think the HP version of the format *may* have taken
this into account.
I think this format is in general both more verbose and simpler than
other formats and would readily lend itself to translation into other
formats, as long as you didn't go hog-wild using various features of
the format that just nothing else supports.
I haven't heard of any breakdown of which architectures use which
formats. You would have to contact emulator/simulator vendors for
your architecture to see what they support.
Return to the
Search the comp.compilers archives again.