> 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
- References:
- Port of EPICS 3.14.9 to ETRAX CRIS architecture - Strange Data Peter Zumbruch
- Re: Port of EPICS 3.14.9 to ETRAX CRIS architecture - Strange Data Dirk Zimoch
- Re: Port of EPICS 3.14.9 to ETRAX CRIS architecture - Strange Data Andrew Johnson
- Navigate by Date:
- Prev:
RE: Port of EPICS 3.14.9 to ETRAX CRIS architecture - Strange Data Jeff Hill
- Next:
Soft IOC for A GPIB Instrument Szalata, Zenon M.
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Port of EPICS 3.14.9 to ETRAX CRIS architecture - Strange Data Andrew Johnson
- Next:
RE: Port of EPICS 3.14.9 to ETRAX CRIS architecture - Strange Data Jeff Hill
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|