EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Newport XPS-Q8 and Motor Record - armv5teb architecture
From: Jens Eden <[email protected]>
To: <[email protected]>
Date: Wed, 7 May 2014 18:01:28 +0200


I don't know if this is the cause of the problem, but even on a single architecture,
you will need a correct entry in this switch in motorApp/MotorSrc/motor.h

#if defined(_WIN32) || defined(_M_IX86) || defined(_X86_)
    #define LSB_First (TRUE)  /* LSB is packed first. */
#elif defined(__i386__) || defined(_armv4l_) || defined(_X86_64_) || defined(__APPLE__)
    #define LSB_First (TRUE)  /* LSB is packed first. */
#elif defined(i386)
    #define LSB_First (TRUE)  /* LSB is packed first. */
#elif defined(sparc) || defined(m68k) || defined(powerpc)
    #define MSB_First (TRUE)  /* MSB is packed first. */
#elif (CPU == PPC604) || (CPU == PPC603) || (CPU == PPC85XX) || (CPU == MC68040) || (CPU == PPC32)
    #define MSB_First (TRUE)  /* MSB is packed first. */
#else
    #error: unknown bit order!
#endif

Since (CPU == PPC604) is true for all cases where CPU is undefined, the
arm compiler will not fall through to the error message in the else case.
This fixes this part
--- #elif (CPU == PPC604) || (CPU == PPC603) || (CPU == PPC85XX) || (CPU == MC68040) || (CPU == PPC32)
+++ #elif defined(CPU) && ((CPU == PPC604) || (CPU == PPC603) || (CPU == PPC85XX) || (CPU == MC68040) || (CPU == PPC32))

Assuming that on all gnu compilers bit stuffing is related to endianess,
(which was stated in an internet forum, but I do not know if it is correct in all cases)
I used this to solve the problem for the raspberry pi arm gnu cross-compiler.

#if defined(_WIN32) || defined(_M_IX86) || defined(_X86_)
    #define LSB_First (TRUE)  /* LSB is packed first. */
#elif defined(__i386__) || defined(_armv4l_) || defined(_X86_64_) || defined(__APPLE__)
    #define LSB_First (TRUE)  /* LSB is packed first. */
#elif defined(i386)
    #define LSB_First (TRUE)  /* LSB is packed first. */
#elif defined(sparc) || defined(m68k) || defined(powerpc)
    #define MSB_First (TRUE)  /* MSB is packed first. */
#elif defined(CPU) && ((CPU == PPC604) || (CPU == PPC603) || (CPU == PPC85XX) || (CPU == MC68040) || (CPU == PPC32))
        #define MSB_First (TRUE)  /* MSB is packed first. */
#elif defined(__GNUC__)
        #include <epicsEndian.h>
    #if (EPICS_BYTE_ORDER == EPICS_ENDIAN_LITTLE)
        #define LSB_First (TRUE)
         #else
        #define MSB_First (TRUE)
         #endif
#else
    #error: unknown bit order!
#endif


Jens


Am 06.05.2014 14:24, schrieb Mark Rivers:
If I were trying to access the same object on an x86 and an ARM then indeed packing could be an issue.  But I am NOT trying to access the object on 2 different architectures. It is a simple structure that is being accessed only on the ARM.  There is no need to worry about whether a double is the same size on the 2 architectures, it is only required that the ARM be internally consistent, which it certainly should be.

The queue is a very well tested code in asynManager, used on ARM and dozens of other architectures with no problems.  It is not a fixed size queue.

Mark

________________________________
From: Stephen Beckwith [[email protected]]
Sent: Tuesday, May 06, 2014 7:04 AM
To: Mark Rivers
Cc: J. Lewis Muir; Tonia Batten; [email protected]
Subject: Re: Newport XPS-Q8 and Motor Record - armv5teb architecture

You miss my point:
Since the issue is between two different ISA's (x86, which is byte addressable memory vs. ARM v5 which is 4 byte (32 bit) addressable memory), you WILL have alignment issues in certain cases.  In addition, supporting libraries and other code may have issues with the "native types" - make sure the double is the same width (in bytes) on each architecture.
Another idea:  Dump (in hex) the message pointed to by the pmsg pointer.

you mention a Queue - if you're doing memory copies (??) then size becomes an issue.  The other possibility is,again, due to a size issue, there is a clash between this structure and another one next to it and the dvalue is getting overwritten.

Stephen Beckwith



On Tue, May 6, 2014 at 7:18 AM, Mark Rivers <[email protected]<mailto:[email protected]>> wrote:
Could be padding issue in how the compilers for different ISA handle the alignment.

That should not be an issue because the structure is only being accessed by code using the same definition of the structure.  The structure is written to in one function and read from in another function in the same source code module.  Packing should be irrelevant.

Does the ARM compiler being used has proper library support for double?

It certainly appears to.  The double values are being computed correctly in the motor record, and they are being printed correctly in this device support code.

Mark


________________________________
From: Stephen Beckwith [[email protected]<mailto:[email protected]>]
Sent: Monday, May 05, 2014 10:00 PM
To: J. Lewis Muir
Cc: Mark Rivers; Tonia Batten; [email protected]<mailto:[email protected]>
Subject: Re: Newport XPS-Q8 and Motor Record - armv5teb architecture

Intel is Little Endian - ARM can be either - how is the ARMv5 setup?  Big Endian or Little Endian?
What OS are you dealing with?  What compiler?
What happens if you move the double and int?  Could be padding issue in how the compilers for different ISA handle the alignment.  Is the Intel a 64bit CPU? (I know ARMv5 is not, that’s a “StrongArm” variant basically or Marvell. . .
Does the ARM compiler being used has proper library support for double?
Stephen Beckwith



On Sat, May 3, 2014 at 8:39 PM, J. Lewis Muir <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote:
On 5/3/14, 5:32 PM, Mark Rivers wrote:
Any idea how this could happen?

Hi, Mark.

Compiler bug?  Maybe try turning off all optimizations?

Lewis







Replies:
Re: Newport XPS-Q8 and Motor Record - armv5teb architecture J. Lewis Muir
References:
RE: Newport XPS-Q8 and Motor Record - armv5teb architecture Mark Rivers
Re: Newport XPS-Q8 and Motor Record - armv5teb architecture J. Lewis Muir
Re: Newport XPS-Q8 and Motor Record - armv5teb architecture Stephen Beckwith
RE: Newport XPS-Q8 and Motor Record - armv5teb architecture Mark Rivers
Re: Newport XPS-Q8 and Motor Record - armv5teb architecture Stephen Beckwith
RE: Newport XPS-Q8 and Motor Record - armv5teb architecture Mark Rivers

Navigate by Date:
Prev: Re: Device/Driver Support for Stepper Motor Control J. Lewis Muir
Next: Re: Newport XPS-Q8 and Motor Record - armv5teb architecture J. Lewis Muir
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Newport XPS-Q8 and Motor Record - armv5teb architecture Stephen Beckwith
Next: Re: Newport XPS-Q8 and Motor Record - armv5teb architecture J. Lewis Muir
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·