2002 2003 2004 2005 2006 2007 <2008> 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 <2008> 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Fixes for 64-bit CPUs |
From: | Andrew Johnson <[email protected]> |
To: | Eric Norum <[email protected]> |
Cc: | EPICS core-talk <[email protected]>, Mark Rivers <[email protected]>, Marty Kraimer <[email protected]>, Dirk Zimoch <[email protected]> |
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 typeOn 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