Re: Help: How to determine big/little endian?

Chris Fraser <cwf@research.att.com>
Fri, 25 Aug 1995 12:26:58 GMT

          From comp.compilers

Related articles
[3 earlier articles]
Re: Help: How to determine big/little endian? pardo@cs.washington.edu (1995-08-21)
Re: Help: How to determine big/little endian? mw@ipx2.rz.uni-mannheim.de (1995-08-22)
Re: Help: How to determine big/little endian? tonyk@cybercom.net (1995-08-22)
Re: Help: How to determine big/little endian? paysan@informatik.tu-muenchen.de (1995-08-21)
Re: Help: How to determine big/little endian? tim@franck.Princeton.EDU (1995-08-25)
Re: Help: How to determine big/little endian? meissner@cygnus.com (Michael Meissner) (1995-08-25)
Re: Help: How to determine big/little endian? cwf@research.att.com (Chris Fraser) (1995-08-25)
Re: Help: How to determine big/little endian? nr@cs.purdue.edu (1995-08-25)
Re: Help: How to determine big/little endian? doug@netcom.com (1995-08-26)
Re: Help: How to determine big/little endian? meissner@cygnus.com (Michael Meissner) (1995-09-01)
Re: Help: How to determine big/little endian? mab@wdl.loral.com (1995-09-01)
Re: Help: How to determine big/little endian? erik@kroete2.freinet.de (1995-09-03)
Re: Help: How to determine big/little endian? daniels@cse.ogi.edu (1995-09-13)
[2 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: Chris Fraser <cwf@research.att.com>
Keywords: C, architecture
Organization: Compilers Central
References: 95-08-120
Date: Fri, 25 Aug 1995 12:26:58 GMT

I haven't followed this thread much -- like our moderator, I've seldom
needed to use endianness -- but here's a bit from that gripping book, A
Retargetable C Compiler: Design and Implementation, by Dave Hanson and me,
that might interest those interested in this thread.


Chris Fraser, AT&T Bell Laboratories


---CUT HERE---
LCC assumes that it is running on and compiling for machines with
IEEE floating-point arithmetic. The host and target machines need not
be the same, but both must use IEEE floating-point arithmetic.
This assumption was once constraining, but it sacrifices little now.


The discussion about the interface procedure defconst in
Chapter 5 explained that code generators for C must
encode floating-point numbers themselves. That is, they must emit
equivalent hexadecimal constants and shun the assembler directives
that convert a textual representation of a floating-point constant to
its internal form.


LCC can emit a single word for each single-precision float, but it
must emit two words for doubles. If LCC is running on a
little endian *and* compiling for a little endian, or if both
machines are big endian, then both encode doubles the same way, and the
code generator can emit in order the two words that comprise the
double. But if one machine is a big endian and the other a
little endian, then one expects the high-order word first and the other
expects the low-order word first. defconst must exchange the two
halves as it emits them.


The interface flag little_endian classifies the target, but
nothing in the interface classifies the host. LCC classifies the
host automatically during initialization:


int `swap;
...
{
union {
char c;
int i;
} u;
u.i = 0;
u.c = 1;
swap = (u.i == 1) != IR->little_endian;
}


Little-endian machines define u.c on top of the low
bits of u.i, so the assignment to u.c above sets u.i
to 1. Big-endian machines define u.c on top of the high
bits of u.i, so the assignment to u.c to sets u.i to
0x01000000 on LCC's 32-bit targets.
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.