RE: CA on alphas

[johill@lanl.gov (Jeff Hill)]

Sorry about the late response to this ...

On Thursday, February 11, 1999 9:40 AM, Marty Kraimer [SMTP:mrk@aps.anl.gov] wrote:
> Geoff Savage wrote:
> > 
> > To get running on our alphas I grabbed the compiled libraries and binaries
> > for the alpha from Mark Rivers web site.  Thanks :) These are for EPICS
> > R3.12.  While using these I have encountered an interesting problem.  I
> > receive unaligned access errors from ca_array_put().  I traced them back to
> > issue_ca_array_put() in access.c.  When pdest and pvalue are incremented by
> > size_of_one.  At this point dbr_long_t has a size of 4 bytes (epicsInt32).
> > A long on an alpha is 8 bytes.  When the assignment is made between the two
> > arrays the type of long is used.  size_of_one needs to be 8 bytes.
> > 
> > I'm looking at R3.13.beta11 code.
> > 
> > Any suggestions.  The problem will appear when an extra 4 bytes is written
> > at the end of pdest.
> 
> The problem is the structures in db_access.h. They described the data that is
> passed across the network. They assume a 32 bit architecture. CA does take care
> of byte order. My guess is that it may take a lot of work to properly support 64
> bit architectures.
> 

In fact the ca libraries do work correctly on 64 bit architectures.

If you are writing a portable EPICS CA application (client side tool) then
when you write a DBR_LONG with ca_put() you must be consistent and supply
a pointer to type "dbr_long_t". If you supply a pointer to the C type "long"
your application will, as you have observed, fail on 64 bit machines. The
data type "dbr_long_t" is configured to be a 32 bit integer on all hosts. This
data type uniformity approach we have applied to network communication
is very similar to what is used in RPC based systems such as DCE, sun RPC
or CORBA.

Jeff