Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 29 May 2008 15:30:00 -0600

For client and server to speak the same language a DBR_LONG in the CA
protocol will need to remain 32 bits on the wire following past convention.
I suppose that we could add a new data type (maybe named DBR_LONG_LONG) that
would be a 64 bit integer, but perhaps that would need to be initially
justified based on a specific need. It _is_ too bad that DBR_INT wasn't 32
bits instead of, I believe that it is actually, 16 bits so that DBR_LONG
could have been reserved for 64 bit integers, but that's water under the
bridge in 1988.

Note also that there is probably code in the database that assumes that
DBR_XXX == DBR_XXX for the ranges that overlap.

No doubt that once nearly all machines are 64 bits we will eventually need
to support 64 bit data types. This might require also possibly software
emulation of 64 bit types on 32 bit architectures.

Jeff

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Andrew Johnson
> Sent: Thursday, May 29, 2008 10:48 AM
> To: Eric Norum
> Cc: EPICS core-talk; Mark Rivers; Marty Kraimer; Dirk Zimoch
> Subject: Fixes for 64-bit CPUs
> 
> 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System