Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 10 May 2013 17:20:24 -0500

Hi Michael,

On 2013-05-10 you wrote:
> On 05/10/2013 03:55 PM, Till Straumann wrote:
> > ...
> > Let's face it: Reordering of loads even to guarded and cache-inhibited
> > memory is not prohibited and thus could happen. ...
> 
> I would agree with Till in this case.  Existing hardware probably isn't
> taking advantage of all the reordering allowed by the PPC ISA.  So even
> if this isn't a problem with current hardware, future hardware could.
> So I think it is prudent to do the "right thing".

I agree.  I'd like to add the following article into the conversation, which I 
found informative even though the later parts mostly talk about AIX:
  http://www.ibm.com/developerworks/systems/articles/powerpc.html

I suspect that the (older) PowerPC CPUs that we mostly use at the APS don't 
actually do reordering (on guarded memory at least) which is why we haven't 
seen the need for this here yet.  The FreeScale e500 family CPUs such as on 
the MVME3100 may be a different matter however.

> In the interest of making this easier to do I'm proposing that the MMIO
> wrappers from devLib2 be included in EPICS Base 3.15.
> 
> https://code.launchpad.net/~epics-core/epics-base/devlib2mmio/+merge/163365
> 
> I would ask that those interested (Till and Eric especially) please look
> this over and see if it is sufficient.  Right now it has
> speciallizations only for vxWorks and RTEMS (PPC and x86 only). Other
> targets fall back to C volatile pointers, which are better than nothing.

We will also need this to work on vxWorks-68040 where the compiler will pull 
in your vxWorks/epicsMMIO.h header but the BSPs don't have any of the 
sys{In,Out}{Byte,16,32,Word,Long} routines (that CPU doesn't do any reordering 
either).

On the VxWorks PowerPC targets there is the problem that Wind River's mv2100 
BSP provides these routines:
    UCHAR  sysInByte (ULONG);
    void   sysOutByte (ULONG, UCHAR);
    USHORT sysInWord (ULONG);
    void   sysOutWord (ULONG, USHORT);
    ULONG  sysInLong (ULONG);
    void   sysOutLong (ULONG, ULONG);
The mv2700 and mv5100 BSPs provides these:
    UCHAR  sysInByte (ULONG);
    void   sysOutByte (ULONG, UCHAR);
    UINT16 sysIn16 (UINT16 *);
    void   sysOut16 (UINT16 *, UINT16);
    UINT32 sysIn32 (UINT32 *);
    void   sysOut32 (UINT32 *, UINT32);
while the mv6100 BSP provides these:
    UCHAR  sysInByte (ULONG);
    void   sysOutByte (ULONG, UCHAR);
    UINT16 sysIn16 (UINT32);
    void   sysOut16 (UINT32, UINT16);
    UINT32 sysIn32 (UINT32);
    void   sysOut32 (UINT32, UINT32);
The mv3100 has these:
    UCHAR  sysInByte (UCHAR *)
    VOID   sysOutByte (UCHAR *, UCHAR);
    USHORT sysInWord (ULONG address);
    VOID   sysOutWord (ULONG address, UINT16 data);
    ULONG  sysInLong (ULONG address);
    VOID   sysOutLong (ULONG address, ULONG data);
and the mv7100 BSP these:
    UCHAR  sysInByte (ULONG);
    VOID   sysOutByte (ULONG, UCHAR);
    USHORT sysInWord (ULONG address);
    VOID   sysOutWord (ULONG address, UINT16 data);
    ULONG  sysInLong (ULONG address);
    VOID   sysOutLong (ULONG address, ULONG data);

Note the subtle differences in argument types (which don't really matter) and 
routine names (which do).  We may have to get users to install aliases for 
these routines in their BSPs, since the same generic vxWorks-ppc32 binary can 
be loaded on almost all those boards but would only succeed on half of them.

Should we consider merging this into 3.14 instead of 3.15?  I'm open to 
discussion of that.

- Andrew
-- 
It is difficult to get a man to understand something, when his salary
depends upon his not understanding it. -- Upton Sinclair

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System