Re: User level Macros for Endianess

Re: User level Macros for Endianess

[Stephane GEORGES]

I use my own executable compiled by GNU before compiling anything else:

bigendian.c
-----------

int main()
{
  unsigned short val = 0x0011;
  unsigned char* str = (unsigned char*)&val;
  if ( str[0] == 0x00 )
    return 1;
  else
    return 0;
}

in my GNUmakefile
-----------------

- one rule to compile bigendian.c if exe not compiled
- one rule testing the return value of exe and setting

    MEMORY_IS_LITTLE_ENDIAN or MEMORY_IS_BIG_ENDIAN

That way I do not need to look for the right MACRO on the right SYSTEM.

I compile my code on IRIX (SGI), Solaris (SUN), intel Linux and LinuxPPC.

--

/====================================================================/|
| Stephane GEORGES                     |                             ||
| DALiM SOFTWARE GmbH      R&D         |    Tel: +49 7851 9196 40    ||
| Strassburger Str.6                   |    Fax: +49 7851 7357 6     ||
| D-77696                              |                             ||
| Kehl-Sundheim (Germany)              |    E-mail: sg@dalim.de      ||
|____________________________________________________________________|/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: User level Macros for Endianess

[David A. Gatwood]

On Thu, 13 Jan 2000, Stephane GEORGES wrote:

> I use my own executable compiled by GNU before compiling anything else:
> 
> bigendian.c
> -----------
> 
> int main()
> {
>   unsigned short val = 0x0011;
>   unsigned char* str = (unsigned char*)&val;
>   if ( str[0] == 0x00 )
>     return 1;
>   else
>     return 0;
> }
> 
> in my GNUmakefile
> -----------------
> 
> - one rule to compile bigendian.c if exe not compiled
> - one rule testing the return value of exe and setting
> 
>     MEMORY_IS_LITTLE_ENDIAN or MEMORY_IS_BIG_ENDIAN
> 
> That way I do not need to look for the right MACRO on the right SYSTEM.
> 
> I compile my code on IRIX (SGI), Solaris (SUN), intel Linux and LinuxPPC.

One worry here is that there are a few obscure (and generally, pretty
out-of-date) architectures that are neither big nor little.  Since this
only checks the first byte against the big value, it will return little
endian on a few oddball machines.  Other than that, though, yes, that
should work.


David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: User level Macros for Endianess

[Gabriel Paubert]

On Thu, 13 Jan 2000, David A. Gatwood wrote:

> > int main()
> > {
> >   unsigned short val = 0x0011;
> >   unsigned char* str = (unsigned char*)&val;
> >   if ( str[0] == 0x00 )
> >     return 1;
> >   else
> >     return 0;
> > }
> > 
> > in my GNUmakefile
> > -----------------
> > 
> > - one rule to compile bigendian.c if exe not compiled
> > - one rule testing the return value of exe and setting
> > 
> >     MEMORY_IS_LITTLE_ENDIAN or MEMORY_IS_BIG_ENDIAN
> > 
> > That way I do not need to look for the right MACRO on the right SYSTEM.
> > 
> > I compile my code on IRIX (SGI), Solaris (SUN), intel Linux and LinuxPPC.
> 
> One worry here is that there are a few obscure (and generally, pretty
> out-of-date) architectures that are neither big nor little.  Since this
> only checks the first byte against the big value, it will return little
> endian on a few oddball machines.  Other than that, though, yes, that
> should work.

Indeed, I don't think that there are so many PDP around here any more, but
what about cross compiling (for a PDP you would cross compile for sure) ?

The exe runs on the build machine, not the target. And many archs can run
right^Wbig- or wrong^Wlittle-endian: Alpha, ARM, IA64, MIPS, PPC, SH,
SPARC. (I thought HPPA could but gcc only knows the big endian version).

I don't know of any arch switchable between 3 or more different byte
orders, however (from gcc source the 1750 is as weird as the PDP, maybe
they are related).

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: User level Macros for Endianess

[Jesper Skov]

>>>>> "iweiny" == iweiny  <iweiny@pacbell.net> writes:

iweiny> What Macros should I be using to key off of for this?  I have
iweiny> looked through /usr/include/endian.h and
iweiny> /usr/include/bits/endian.h.  BYTE_ORDER (without the leading
iweiny> underscores) is only defined if __USE_BSD is defined.  BOTH
iweiny> __BIG_ENDIAN and __LITTLE_ENDIAN are defined as are BIG_ENDIAN
iweiny> and LITTLE_ENDIAN.  I'm so confused?

#include <asm/byteorder.h>

then use __le32_to_cpu and friends (see
/usr/include/linux/byteorder/generic.h)

I'm not sure if that's the Proper Way(TM) to do it from user land
though.

Jesper

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: User level Macros for Endianess

[Gabriel Paubert]

On 12 Jan 2000, Jesper Skov wrote:

> #include <asm/byteorder.h>
> 
> then use __le32_to_cpu and friends (see
> /usr/include/linux/byteorder/generic.h)
> 
> I'm not sure if that's the Proper Way(TM) to do it from user land
> though.

No, it's very different between application and kernel code (unfortunately
since this forced me to write 2 very different vme.h include files for VME
systems, it's not only a simple cp). Under Linux, asm/byteorder.h is the
right way to get the correct macros, and either LITTLE_ENDIAN or
BIG_ENDIAN is defined.

>From userland both are defined and then BYTE_ORDER is set to one of these
(strange architecture might even have a byte order which is neither like
the PDP) so the check is #if __BYTE_ORDER==__BIG_ENDIAN ...

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: User level Macros for Endianess

[Charles Lepple]

iweiny@pacbell.net wrote:
> What Macros should I be using to key off of for this?  I have looked through
> /usr/include/endian.h and /usr/include/bits/endian.h.  BYTE_ORDER (without the
> leading underscores) is only defined if __USE_BSD is defined.  BOTH
> __BIG_ENDIAN and __LITTLE_ENDIAN are defined as are BIG_ENDIAN and
> LITTLE_ENDIAN.  I'm so confused?

You can take advantage of the fact that "network byte order" is
big-endian, allowing you to use the hton?() and ntoh?() macros. I
realize that this is specific to a big-endian device (such as the camera
interface you have) but this is certainly easier than shoehorning an
existing project into the GNU autoconf model.

That said, you wouldn't want to use this hack for a new project -- an
autoconf-style test would be cleaner (IMHO). I would welcome any
suggestions, however.

-- 
Charles Lepple
clepple@mitre.org


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: User level Macros for Endianess

[David A. Gatwood]

On Wed, 12 Jan 2000 iweiny@pacbell.net wrote:

> Unfortunately I don't have an x86 Linux machine and he has been reluctant to
> change his code because he feels this is not the "proper" way to detect
> endianess across Linux's, Solaris, and possibly other UNIX's.

Well, if you really want it to be completely cross-platform, you could do
something like:


int a = 0x33323130;
char *b, d[5];
int c;

for (b=(char *)&a, c=0; c<4; c++,b++)
    {
	d[c]=*b;
    }
d[5]=0;



I believe that the Linux macros do this same basic thing, if memory
serves....  BTW, if you printf("%s", d) you'll get 3210 on big endian,
0123 on little.  You could also do it as short integers instead of
characters by subtracting 48 in the d[c]=*b line.

Just a sick thought.  :-)


Later,
David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/