Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Fri, 30 May 2008 09:27:26 -0600

Sorry, I meant to say (I changed DBR to DBF), "note also that there is
probably code in the database that assumes that DBR_XXX == DBF_XXX for the
ranges that overlap."

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