Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Mon, 21 Feb 2005 08:41:35 -0600

Jeff Hill wrote:

Hello Marty,

Here are my comments.

Yes, PP should be on the list for next rev of CA.

Primitive Types
---------------

o Past versions of CA were based on size locked types - i.e.
"typedef epicsInt16 dbr_int_t;". However, my experience is that
users seldom bothered to use dbr_xxx_t, and my current
perspective is that size locked types should not be in interfaces
used by users. Data access is an example of an interface that
binds to the user's selected primitive data type instead of
requiring that users recode to yet-another size locked data type

system.

o Data access is more fool proof because it uses overloaded
functions instead of a data type code and a void pointer.

o We can generate C and Java bindings for data access as needed.

Don't these, or at least the set that reproduces V3 functionality, need

to be defined now?

The problem I have with Data access is that it seems to be a solution to

a set of undefined requirements.

Let me focus the problem a little more.

What will the V4 Gateway be?  How will it store data?

I think that answering these two questions will go a long way to

deciding if and how Data access is a necessary component.

o Data access supports safe conversion between all of the
primitive types available in C. If the source is out of range for
the destination the operation is not performed and an error is
returned to the user. This has already been implemented.

Is this what we want?
Let me give an example

An IOC has a field that is an unsigned 32 bit integer.
A java application asks for the fields as a signed 32 bit integer.
The java application only uses the field as a bit mask.

Should CA return an error if the value happens to have the high order

bit = 1?

I say no.

For an IOC perhaps we should just not support conversions that can cause

problems.

This is what I proposed in "EPICS V4 epicsTypes".

On
linux-x86 the object code is less than 16kB of object code for
scalars and 26kB for arrays. The array code includes a high speed
loop customized to each conversion. We could use a type
independent loop to save space, but that would not perform as

well.

DBD
---
o For multi-dimensional arrays I see an element count (capacity)
for each dimension, but not a starting element for each
dimension. This is probably correct for specifying fields.

Correct. The offsets, etc are an issue for database access but not

database definition.

For
links it might be important to specify the starting element when
targeting a slice from another record's array.

Good point.

String Lib
----------
o This interface precludes implementations which store the string
in homogenous fixed sized non-contiguous blocks. This is
important when avoiding memory fragmentation, and when
efficiently using available memory. The data access interface
*does* allow storage of strings in fixed sized non-contiguous
blocks. Admittedly, the data access daString interface has
postponed the numeric conversion issue by leaving that up to the
string storage implementation. In any case memory management is a
*very* important issue that has side effects in other parts of
the design.

How to implement arbitrary length strings is a big issue especially

memory management.

Also supporting UTF-8 is a big issue.

We do NOT want to create our own complete string library including the

equivalent of the printf and scanf family. But what do we need? Big issue.

Struct Lib
----------

o This seems to be a subset of the data access interface and
associated libraries.

And perhaps the only subset needed?

o Indexing structure fields using a field name string may be too
inefficient for high throughput situations?

Agreed. The example was only to show that applications that do not know

about the structs can still access elementary fields.

I am envisioning that structs will be the way to make "atomic" access to

multiple fields. To make the atomic access the an application will have

to work with the struct rather than just accessing individual fields.

o There is no way to introspect the available fields, and there
values, in an unknown structure (i.e. traverse functionality in
data access).

It should be easy to provide introspection for structs. Thus generic

applications can be written that can access arbitrary structs. The V4

gateway, for example, will probably need to support arbitrary structs.

Marty

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System