|[Help] Endian Problem firstname.lastname@example.org (Yunseok Rhee) (1998-09-13)|
|Re: [Help] Endian Problem email@example.com (Max TenEyck Woodbury) (1998-09-18)|
|Re: [Help] Endian Problem firstname.lastname@example.org (Michael Meissner) (1998-09-18)|
|Re: [Help] Endian Problem email@example.com (1998-09-18)|
|Re: [Help] Endian Problem firstname.lastname@example.org (1998-09-22)|
|From:||email@example.com (Mike Albaugh)|
|Date:||22 Sep 1998 01:23:40 -0400|
|Organization:||Atari Games Corporation|
I refrained from posting, assuming that somone else would,
but this thread seems to be running out without anybody else getting
around to the main point (IMHO).
Zalman Stern (firstname.lastname@example.org) wrote:
: Yunseok Rhee (email@example.com) wrote:
: : Conseqently, if any, I want to know how to generate the little-endian
: : executables in MIPS machines. Though it is impossible, please let me
: : know if you have any other idea with the problem.
: For example, if you just need MIPS executables from complete sources
: and don't have fixed compiler requirements, you could build a
: little-endian MIPS cross compile version of the GNU tool chain for the
: x86 system and do quite well.
This makes rather a large assumption: that the original
sources don't implicitly encode an expectation of BigEndian data.
Admittedly, this problem is less common than the reverse; a program
coming from the PC world where not only endianness, but alignment (or
the lack thereof) is assumed, sometimes in very subtle ways,
throughout the code. "Just recompile" assumes well-written source
which is, to quote Perry Mason "Facts not in evidence" :-)
But yes, Little-Endian MIPS is no big deal. Older DEC systems
with MIPS CPUS were LE, and many of our embedded products are too. If
one is using components originally designed for the PC, it is best not
to lean too heavily on the assurance of the sales-droid that they are
| firstname.lastname@example.org, speaking only for myself
Return to the
Search the comp.compilers archives again.