Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · 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.

Paul

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System