EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: synApps usage on 64 bit systems
From: Mark Rivers <[email protected]>
To: "'Henrique Dante de Almeida'" <[email protected]>, "[email protected]" <[email protected]>
Date: Tue, 22 Jul 2014 18:07:10 +0000
I have tested the scaler record on a 64-bit Windows system and it worked, but that is because in Visual Studio a "long" is 32-bits even on a 64-bit system.  Pointers are 64-bits, but longs are not.  You are probably the first to use it on a 64-bit Linux system.

I think that converting the scaler record to use a fixed 32-bit type is a good idea.  It might also be a good idea to define a new type locally which is set to epicsUInt32.  That way if EPICS ever supports a 64-bit integer DBR type for record fields only 1 line would need to be changed.  64-bit integers would be very useful for the scaler record, since there a currently a number of scalers with 64-bit counter depth.

Mark


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Henrique Dante de Almeida
Sent: Tuesday, July 22, 2014 12:08 PM
To: [email protected]
Subject: synApps usage on 64 bit systems

Hello, while using synApps with a test scaler IOC in a 64 bit linux machine I noticed some problems while reading and writing PV values. The problem was tracked down by another developer, some time ago, to be in synApps/support/std-*/src/scalerRecord.c, where the scalerRecord elements pr1, pr2, etc. are accessed using an unsigned long pointer (a type coercion to handle them as if they were a simple array). For example, in process():


static long process(pscal)
scalerRecord *pscal;
{
(...)
        unsigned long *ppreset = (unsigned long *)&(pscal->pr1);
(...)

Since pr1 and all other pr* are type epicsUInt32, using ppreset to access
the preset values is not supposed to work. Can anyone confirm this ?

The proposed patch was to replace the cast to unsigned long * to epicsUInt32 *,
or similar. Changing only process() and updateCounts() to use a 32 bit type was
enough to make the test scaler to work. I noticed that there are other variables
of type unsigned long, though. Would it make sense to write a patch to change all
the relevant variables to a fixed 32 bit type ?



References:
synApps usage on 64 bit systems Henrique Dante de Almeida

Navigate by Date:
Prev: RE: security rules and autosave Mooney, Tim M.
Next: RE: security rules and autosave Mooney, Tim M.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: synApps usage on 64 bit systems Henrique Dante de Almeida
Next: RE: synApps usage on 64 bit systems Mooney, Tim M.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·