Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: RE: CA on alphas
From: johill@lanl.gov (Jeff Hill)
To: "'Marty Kraimer'" <mrk@aps.anl.gov>, epics tech-talk <TECH-TALK@aps.anl.gov>, "'Geoff Savage'" <savage@fnal.gov>
Date: Thu, 11 Feb 1999 16:19:24 -0700
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

Navigate by Date:
Prev: Digital Unix gcc for 68k and PowerPC Geoff Savage
Next: RE: My fix to CA on alphas Jeff Hill
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: CA on alphas Marty Kraimer
Next: Anyone using Mercury Race Systems with EPICS? Paul Stomski
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·