Re: Newport XPS-Q8 and Motor Record - armv5teb architecture

[Jens Eden <jens.eden@ptb.de>]

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 [embeddedsteve@gmail.com]
> Sent: Tuesday, May 06, 2014 7:04 AM
> To: Mark Rivers
> Cc: J. Lewis Muir; Tonia Batten; Tech-talk@aps.anl.gov
> 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 <rivers@cars.uchicago.edu<mailto:rivers@cars.uchicago.edu>> 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 [embeddedsteve@gmail.com<mailto:embeddedsteve@gmail.com>]
> Sent: Monday, May 05, 2014 10:00 PM
> To: J. Lewis Muir
> Cc: Mark Rivers; Tonia Batten; Tech-talk@aps.anl.gov<mailto:Tech-talk@aps.anl.gov>
> 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 <jlmuir@imca-cat.org<mailto:jlmuir@imca-cat.org><mailto:jlmuir@imca-cat.org<mailto:jlmuir@imca-cat.org>>> 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