Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Mon, 27 Aug 2007 10:51:55 -0600

> Most operating systems nowadays already /have/ header files for 
> providing byte order information to compiled code. 

It's really too bad that byte order configuration information can't be
obtained from the compiler. Undoubtedly the compiler knows about byte
ordering and many other architecture specific details. From my perspective,
it's almost shameful that ANSI C hasn't defined anything in this regard at
this point in time (my understanding is that even C99 has done nothing). 

Lacking that, it's too bad that PSOIX has no standards defined relating to
endian parameters, but the idea of obtaining the byte ordering configuration
information from the OS still seems to be a good one. There would be clear
benefits when a widely used OS such as Linux is ported to a range of
different architectures.

There is reusable code in osi/os/default/osdWireFormat.h that works on most
architectures as long as some basic information about the byte ordering is
known. Therefore, presumably if the byte order configuration information is
in libCom/os/osi/Solaris/xxx.h then osi/os/default/osdWireFormat.h would
need to include xxx.h. That approach would still allow OS such as VMS (which
does not use IEEE FP) to provide alternative implementations of
osi/os/default/osdWireFormat.h. 

Jeff

-----Original Message-----
From: Andrew Johnson [mailto:[email protected]] 
Sent: Monday, August 27, 2007 9:38 AM
To: Dirk Zimoch
Cc: Jeff Hill; [email protected]
Subject: Re: Port of EPICS 3.14.9 to ETRAX CRIS architecture - Strange Data

Dirk Zimoch wrote:
> 
> In my opinion, the config files are a much better place to configure the 
> system than the source code.

Most operating systems nowadays already /have/ header files for 
providing byte order information to compiled code.  Personally I think 
we should be using these in libCom/osi/os files rather than defining our 
own:

On Linux, <endian.h> defines __BYTE_ORDER to be one of __LITTLE_ENDIAN, 
__BIG_ENDIAN or __PDP_ENDIAN, and similarly defines __FLOAT_WORD_ORDER 
since that is needed for the ARM Netwinder FP library.

On vxWorks, <vxWorks.h> includes <types/vxArch.h> which defines 
_BYTE_ORDER to be one of _BIG_ENDIAN or _LITTLE_ENDIAN

On Solaris, <sys/isa_defs.h> defines one or other of the macros 
_LITTLE_ENDIAN or _BIG_ENDIAN.

I don't know whether Windows has anything equivalent, but I'm not sure 
that it runs on any big endian architectures anyway so it may not need one.

If we make any more significant changes in this area it should be to 
using the above OS-defined macros, which should fix this problem once 
and for all.

- Andrew
-- 
When a distinguished but elderly scientist states that something is
possible, he is almost certainly right.  When he states that something
is impossible, he is very probably wrong.  -- Arthur C. Clarke

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System