Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 24 Nov 2014 18:08:52 -0600

On 11/24/2014 02:48 AM, [email protected] wrote:
> Interesting.  I know I'd convinced myself some time ago that DBF_CHAR was
> unsigned, but I guess that was by inspecting some code ... and it looks
> as if different corners of EPICS do this differently.  Certainly where I
> looked I found the following mappings:
> 
> 	CHAR		8-bit unsigned
> 	SHORT		16-bit signed
> 	LONG		32-bit signed
> 	ENUM		16-bit unsigned (plus the strings)
> 	STRING	40 8-bit bytes (indeterminate sign? haven't checked)
> 	FLOAT		32-bit floating point
> 	DOUBLE	64-bit floating point
> 
> That is, as I understand it, the complete list of transportable EPICS CA
> datatypes.

That looks correct. The STRING representation uses the native char of
the client's ABI, so the characters may be signed or unsigned.

> However it sounds as if things aren't as well defined as I thought.

Inside the IOC database we use a wider set of types and different (and
incompatible) definitions for the field index enum values DBF_STRING,
DBF_CHAR etc.

> Is it worth digging deeper into the definitions of these types?  I
> don't remember where I got the list above, but my understanding was
> that it was definitive ... but you're saying that things are not so clear.

The CA client data types are defined in db_access.h, while the IOC's
types are in dbFldTypes.h. I don't have time to explain the history of
this split right now...

>> I will be introducing two 64-bit integer field types into the IOC
>> database on the 3.16 branch which will require changes to some external
>> software (the new DBF_INT64 and DBF_UINT64 values appear in the middle
>> of the enum dbfType range, they can't be appended to it). I could take
>> that opportunity to try fixing some of these other type issues as well
>> if the community wants that and is willing to accept more breakage.
>>
>> This work would not affect CA clients though, I am not going to be
>> touching that protocol or the db_access.h types which are used by
>> clients.
> 
> If you're not changing CA how do you propose to transport 64-bit
> integers?  Without CA support I don't think I understand your proposal.

The V4 pvAccess protocol can transport 64-bit integer values, so this
will eventually allow them to be passed over the network natively. For
CA the DBF_INT64 and DBF_UINT64 field types will appear as DBF_DOUBLE
and automatically converted, just like DBF_ULONG fields are currently
represented.

If someone wants to look at adding 64-bit support to CA they can of
course do that, but I don't think it'll be easy [Required: Maintain
compatibility with older CA client/servers; modify both RSRV + CAS
servers; modify PV Gateway as well] and I suspect is not be worth doing
at all.

- Andrew
-- 
People everywhere confuse what they read in newspapers with news.
-- A. J. Liebling

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System