EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

<20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  Index <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022 
<== Date ==> <== Thread ==>

Subject: Re: RISC_pad in dbr_time_double
From: Marty Kraimer <[email protected]>
To: "TYLER, Paul" <[email protected]>
Cc: "'Jeff Hill'" <[email protected]>, "'Andrew Johnson'" <[email protected]>, "'Janet Anderson'" <[email protected]>, [email protected]
Date: Thu, 05 Dec 2002 09:13:40 -0600
The problem is worse than just what is passed across the network and the db_access.h/db_access.c problem.
long is used MANY places in epics. In most uses it silently assumes that long
means int32.
For example the status value returned by many functions is a long. The status
value is encoded so that the upper 16 bits refers to a system and the lower 16
bits a status value for the system. This was modeled after what vxWorks does. I
put this into base and I think it was a major mistake. But that is another
topic. I wonder what will happen if a long is 64 bits and architecture is little
endian? Maybe it will still work but it should be tested.
Conversion routines are involved in transfering data to/from network buffers.

Data is transfered between fields of records and network buffers.

I have been looking at some of these changes and will send another message.

One other item for Paul. dbAccess was created in 1990. At that time it was assumed that db_access would go away in a short time. This was before epics was chosen as the name to replace gtacs. Gtacs was used by the GTA project at LANL and the GTA users refused to accept any changes that might cause them any problems. Since getting rid of db_access would have required changes to CA clients (not many at the time) we could never get rid of db_access.
TYLER, Paul wrote:
Hi everyone.

I thought I might just stick my 2c worth in only because I have ported a fair amount of code to the
alpha and it is a pain!  Also, sorry this is long.

I concur with Jeff that I know of no modern compiler for which "int" is anything other than a 32 bit
integer.  (I know of a DOS/PC compiler of 10 yrs ago where the default was 16 bit.)

Remember that epics evolved from gtacs which was started about 15 years ago. As
I recall the PDP11 also made int a 16 bit integer. At that time 64 bit
architectures were a distant dream.
My lesson from the alpha has been that for platform independent structures, you cannot rely on
native types (ints, longs, shorts) and if you are going to pass structures over the network, then
you must also consider carefully how each platform might pack the structure.  So there are two
issues: the size of the native types, and then the alignment of those types.  The problem for the
alpha is that a "long" is 8 bytes and must be aligned on byte addresses divisible by 8.  I'm not
sure if a "double" must also be aligned on an address divisible by 8 or only 4, and whether this is
different to the i86 architecture.  I will check in the coming days.
Jeff already made structures in db_access.h use a 32 bit integer for all
dbr_long_t. When db_access.c uses the same definitions then I think all the
padding will work correctly. The padding was put in when we had to support
solaris instead of the 68K sun workstations. The padding was done so that
everything falls on it's natural boundary, i.e. a 4 byte item falls on a 4b byte
boundary, an 8 byte item on an 8 byte boundary.
Note that this means that epics will not support 64 bit integers. I don't think
we should until dataAccess replaces db_access.
 My understanding is that a
"long" is usually the size required to hold a pointer.  That is why it is 8 bytes on the 64 bit
alpha.  Typically when porting to the alpha I'd check the use of every long in the code.  I'd only
use a long if either (1) it had to hold a pointer or (2) it held the result of a system call that
returned a long.  Unfortunately I don't have the time for going through all the EPICS code and
assessing the use of "long".  Our use of it as an IOC under Digital Unix is for interfacing with our
legacy system.  It appears to work, so I'm happy enough!

I currently only work 3 days a week for ANSTO on contract for the next year so time it tight.  But
I'll volunteer to assess all the dbr_... structures common between CA and the database for size and
alignment.  I concur with Jeff that the structures really should only be defined once - though I'd
suggest a separate include file for these structures that is then included in db_access.h and
db_access.c.  I also agree with the use of defined types that are of a known size.  EPICS has the
types like epicsInt32 that are defined for their size.  If an architecture arises where "int" isn't
32 bit (and to be honest, I don't see that happening), then the definition of epicsInt32 can be
"#ifdef"ed for different architectures.

I'd also suggest changing all the RISC_pad fields to arrays of characters so that the padding is
explicit, and the alignment effectively being handled by hand.  This will break some of the test
code though.  But then we'll know the size we expect the structure to have, and can even have test
code to check that these structures are arranged as we intend.  If you're willing to give me a
couple of days, I'll create an include file of dbr_ structures with these things in mind and post it
to whoever is willing to accept them.
I dont see how making the padding arrays of chars makes things better. Again I
will state that once dbr_long_t is make a 32 bit int then all the existing
padding is OK.

P.S.  I excluded core-talk as I'm not a member and wasn't sure of the suitability.

This is cerrainly suitable for core-talk.

Marty Kraimer

RE: RISC_pad in dbr_time_double Jeff Hill

Navigate by Date:
Prev: RE: RISC_pad in dbr_time_double Jeff Hill
Next: Re: RISC_pad in dbr_time_double Marty Kraimer
Index: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022 
Navigate by Thread:
Prev: RE: RISC_pad in dbr_time_double Jeff Hill
Next: RE: RISC_pad in dbr_time_double Jeff Hill
Index: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·