g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  Index 2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014 
<== Date ==> <== Thread ==>

Subject: Fixes for 64-bit CPUs
From: Andrew Johnson <anj@aps.anl.gov>
To: Eric Norum <norume@aps.anl.gov>
Cc: EPICS core-talk <core-talk@aps.anl.gov>, Mark Rivers <rivers@cars.uchicago.edu>, Marty Kraimer <mrk@aps.anl.gov>, Dirk Zimoch <dirk.zimoch@psi.ch>
Date: Thu, 29 May 2008 11:48:01 -0500
Eric Norum wrote:
> Andrew Johnson wrote:
../../asyn/devEpics/devAsynInt32.c: In function 'processMbbo':
../../asyn/devEpics/devAsynInt32.c:717: warning: assignment from incompatible pointer type

../../asyn/devEpics/devAsynUInt32Digital.c: In function 'processMbbo':
../../asyn/devEpics/devAsynUInt32Digital.c:578: warning: assignment from incompatible pointer type

../../asyn/devGpib/devCommonGpib.c: In function 'devGpib_initMbbi':
../../asyn/devGpib/devCommonGpib.c:657: warning: assignment from incompatible pointer type
../../asyn/devGpib/devCommonGpib.c: In function 'devGpib_initMbbo':
../../asyn/devGpib/devCommonGpib.c:839: warning: assignment from incompatible pointer type

On what compiler? I get no warnings for those -- the LHS and RHS of the assignments are both 'unsigned long *'.

I didn't look at them closely before, sorry; this is GCC on a 64-bit machine with some uncommitted changes I have in in my tree for 64-bit systems that change the expansion of DBF_ULONG fields from 'unsigned long' to 'epicsUInt32', etc.

This all relates to differences between db_access.h and dbAccess.h. For code using db_access.h as provided by CA, DBF_LONG maps to an epicsInt32 (which is actually an int), whereas for code using dbAccess.h from the database a DBF_LONG used to map directly to a regular long. On 64-bit CPUs though these two are not synonymous.

Despite this in most cases the existing database code is self-consistent and works Ok on 64-bit systems, but there are a few obscure spots where bugs show up, such as when requesting a DBR_GRAPHIC_DOUBLE through CA from a 64-bit IOC (IIRC the precision value is wrong). I think it's important that R3.14.10 properly supports 64-bit systems, so something has to be done.

I recently worked on fixing the database and dbAccess to change code that uses 'long' to make it use epicsInt32 instead. My changes only affect the field types generated when expanding the record.dbd files, not the recGbl APIs or RSET routine arguments, so the modifications needed in the record supports as a result of this are mostly minor and in many cases zero.

Unfortunately if I commit these changes (which provide a comprehensive solution) this will probably require *some* out-of-tree device and record support changes to match, as in the above warnings from asyn which are from pointers to the DBF_LONG state value fields (ZRVL etc) of the MBB* record types.

It might be possible to reduce the impact of the fix while still getting the IOC to work properly on 64-bit CPUs by not making DBF_LONG fields become an epicsInt32 type. In this case, my current changes would move to the main trunk for the R3.15 release.

My question for general developer discussion is therefore which solution should we adopt? Do it properly in R3.14.10, so on all architectures a DBF_LONG is 32 bits wide but some external device and record support code needs changing, or just fix up the code in R3.14.10 so it works on 64-bit IOCs but a DBF_LONG field is architecture-specific?

I am inclined to do it properly in R3.14.10.  Comments?

- Andrew
--
Talk is cheap. Show me the code. -- Linus Torvalds

Replies:
RE: Fixes for 64-bit CPUs Jeff Hill
A modern DVCS would help (was: Fixes for 64-bit CPUs) Ben Franksen

Navigate by Date:
Prev: Re: zombies Artem Kazakov
Next: RE: Fixes for 64-bit CPUs Jeff Hill
Index: 2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014 
Navigate by Thread:
Prev: Re: zombies Artem Kazakov
Next: RE: Fixes for 64-bit CPUs Jeff Hill
Index: 2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·