Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 5 Dec 2002 11:25:06 -0700

> long is used MANY places in epics. In most uses it silently
> assumes that long means int32.

The CA client library has been used before on ALPHA machines where a
pointer was 64 bits after ironing out some initial problems. I assumed
at the time that a long was also 64 bits on these machines. 

> 
> 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. 

This might cause problem with wasted space, but perhaps does not
otherwise indicate that a run time failure will occur since the data
being stored is always 32 bits in scope?

> 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.

The CA codes that do the endian swapping are designed to use
architecture independent types. I will be the first to admit that there
are many places where this is done and I could have missed something,
but I think that the majority of these situations are dealt with. I
doubt however that anyone has tested on a 64 bit platform recently. 

> 
> Conversion routines are involved in transfering data to/from
> network buffers.

I think that at least in the portable server and in the CA client
library that most if not all of these issues are dealt with because
architecture independent types are used, and these types do not have 64
bit datums. The rsrv code does not do its own conversion and seems to
have very little use of type long. I have generally been quite careful
about truncating a "long" to an "int" w/o doing a range check first for
quite some time now, but some of my older codes might cast w/o a range
check.

> 
> Data is transfered between fields of records and network
> buffers.
> 

I can imagine that there could be problems there. However note that this
code has never run outside of a 32 bit vxWorks environment until R3.14,
and it will not be surprising that a few issues will need to be
addressed.

> > 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.

I am going to guess that a double must be on a natural 8 byte boundary
similar to SPARC and other RISC processors.

> > EPICS has the
> > types like epicsInt32 that are defined for their size

Note that we have dbr_long_t based on epicsInt32_t because it needs to
be clear to CA client side coders that their code will port only if they
use dbr_long_t when they specify type code DBR_LONG.

> >
> > 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.
> > But then we'll know the size we expect the
> > structure to have,

There is nothing wrong with use of dbr_long_t to specify 4 bytes of pad.
Certainly nothing would work correctly if all of the dbr_xxx_t fields in
these data structures were not the same predictable size on all systems,
and the size of dbr_long_t is quite clear once you are familiar with the
small set of architecture independent primitive types in db_access.h.
The name "long" in dbr_long_t and DBR_LONG may now appear to be
unfortunate, but we can't change that in the legacy db_access.h /
cadef.h interface because it is used in many places outside of base.
Replacement interfaces are planned, and in some case implemented, but
are not integrated at this time.

> > and can even have test
> > code to check that these structures are arranged as we intend.

The 32 bit RISC processors place strict requirements on alignment. That
fact, and the fact that we don't transfer 64 bit primitive types at this
time, leads to the conclusion that we do not have alignment problems in
any data structure that are defined in db_access.h, or in caProto.h. Our
regression tests use all of the different data types. The places where
the architecture independent types are not used in db_access.c and in
the databases conversion jump table will of course need to be fixed. The
original ca server, rsrv, has also never been used on a 64 bit platform
so it's possible that there will be issues with it also. At quick check
in the rsrv directory indicates that it makes very few uses of type
"long" with most of them being associated with the status returned from
the database access routines.

Jeff

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System