Newsgroups: | comp.compilers |
From: | tonyk@cybercom.net (Antoun Kanawati) |
Keywords: | architecture, optimize |
Organization: | at home |
References: | <4074ig$nh7@masala.cc.uh.edu> 95-08-140 |
Date: | Tue, 22 Aug 1995 11:28:47 GMT |
baynes@ukpsshp1.serigate.philips.nl wrote:
> I would agree with John that you don't realy need to know. What is more there
> are many cases where just big and little endian is not enough information
> about the processor to use it anyway. You are much better to use explicit
> shifts and masks.
>
> For example some machines can have different word endian from byte endian
> Ex 4 byte integer 0x12345678 can be stored as:
> 12 34 56 78
> 34 12 78 56
> 56 78 12 34
> 78 56 34 12
>
> Then there are machines with holes in their integers - ....
I believe that it is 'safe' to worry about the four variants above, as they
cover most, if not all, modern commonly used CPUs.
Then, we can easily figure out which arrangement we have:
int foo = 0x01020304;
char *p = (char *) &foo;
Given that, we can easily generate a #define, as is done in some
autoconfig programs. Or, we can test at run time, and customize the
program at runtime. The choice of methods depends on the problem.
The technique is used to generate conditional compilation flags in
some installation programs (GNU autoconfig, if I remember well).
Also, the runtime test maybe necessary if you're talking among
heterogenous architectures; use 0x00010203, sort the array of
characters, and you've got a quick tranasltion table for integers.
As long as we all have 2's complement, that is.
--
Antoun (Tony) Kanawati
tonyk@cybercom.net
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.