Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 28 Feb 2008 18:53:46 -0600

Heinrich,

I believe Jeff's recollection here is referring to the code that is found in CVS; I suspect Glen Wright's answer might be more useful to you if you're working with a released version of Base.  We have changed the way we find this configuration info since the R3.14.9 release so that in the future we should be getting all of the information about byte ordering for both integers and floating point numbers from the OS header files like Jeff describes.  VxWorks, Linux and Solaris all run on CPUs that can be big or little endian, and all provide the necessary information in their headers.

- Andrew

----- Original Message -----
From: Jeff Hill <[email protected]>
Date: Thursday, February 28, 2008 4:40 pm
Subject: FW: floating point problem in CA?
To: 'EPICS Techtalk' <[email protected]>

> Hello Heinrich,
> 
> Are you running Linux on your arm? Certain arm processors store the 8 
> byte
> IEEE floating point values in middle endian format. If you have the latest
> EPICS base I seem to recall that, on Linux, the configuration for
> EPICS_FLOAT_WORD_ORDER comes from sys/parm.h and that you need not do 
> any
> special to get it to work (unless we have it coded wrong :). The relevant
> code is in libCom/osi/default/osdWireFormat.h.
> 
> Jeff
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]
> > On Behalf Of Heinrich du Toit
> > Sent: Thursday, February 28, 2008 8:52 AM
> > To: EPICS Techtalk
> > Subject: floating point problem in CA?
> > 
> > Hi
> > 
> > This is weird and I'm not really sure how to track it down.
> > 
> > I have an embedded ARM board. I've compiled EPICS onto that.
> > 
> > I run vlinac (just to get something ) on my host PC (x86)
> > 
> > Then I take an ai variable. (in other words a floating point thing)
> > 
> > If I say from the ARM board caput  pvname value
> > Then the correct value gets into the pv on my host pc.
> > But.. the wrong value gets back via channel access.
> > if I caget the value I get the wrong answer.
> > 
> > It seems that the network byte order is done wrongly maybe.. I'm not 
> sure.
> > If I put 1.0
> > and then get again I get: 5.29981e-315
> > 
> > Which is almost like the wrong network byte order but not exactly it
> seems.
> > It could be that somewhere along the lines something thinks double 
> is 6
> > bytes only (rather than 8) and then also swaps the byte order.
> > 
> > Maybe there is an htons or something missing somewhere in the code?
> > But how this is possible baffles me. :/
> > 
> > I've written a small program to test the structure and layout off
> > "double" on both my PC and the ARM. it seems identical to me.
> > 
> > If anybody has any idea how I can "check" this or try and find the
> > problem it would be help full.
> > I am aware that the problem is not necessarily in epics but could be 
> in
> > the compiler options or something like that.
> > 
> > 
> > thanks
> > -Heinrich
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System