Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Thu, 30 Jun 2005 14:00:49 +0200

Marty Kraimer wrote:

I suspect, however, that specifying how type_info is defined will lead

to lots of debate starting with the definition of primitive types and

then strings and arrays and then structured data.

Benjamin and I didn't want to lose discussion time and decided to go

ahead starting that debate ....

Our idea is to /not/ make that type info a simple fixed enumeration of

fixed types, but use a dynamic structure to describe a type. We came up

with the following:

type         =   string                      1)
              | timestamp                   2)
              | signed (bitwidth)           3)
              | unsigned (bitwidth)         3)
              | float (float_format)
              | struct                      4)
              | array (base_type, size)     5)

float_format = ieee32 | ieee64 | ieee80

Annotations:

1) String should be a basic atomic type - regardless of its implementation.

2) For efficiency reasons (as timestamps are shipped around and handled

all the time) the timestamp should be an atomic type that can easily be

mapped and assigned to the EPICS supported C/C++ types.

3) A server or client app can choose any locally available data type

that is appropriate and wide enough to store the data. Future wider

integers are supported. As for signedness, alternatively there could be

one integer type with another parameter giving the integer format:

              | integer (int_format, bitwidth)
with
int_format   =   unsigned |signed

4) This basic type is needed for properties that actually are a

contained list of other properties.

5) base_type is another type_info. If we need a type where arrays do not

start with element zero, size might be replaced by a (min, max) pair.

Multi-dimensional arrays are represented as arrays of arrays.

This type_info has a dynamic size (it's a union - which really seems to

be a natural way to describe lots of things...). Making itself a

property catalog seems a slim and convenient way to interface it.

IOC side ideas:

It is perfectly allright for the IOC Database implementation to use a

fixed enumerated number of fixed types. This may be the most efficient

implementation. When the CA connection is made, the CA server will have

to find out about the types of a property catalog owned by a record

using the type_info to decide which network representation it uses for

the data.

In case of a fixed list of enumerated fixed types, a bunch of static

property catalogs will be enough to fulfill most of these type_info

requests. A plain table can hold the connections between fixed types and

their type_infos. (There's no need to generate a type_info property

catalog for each record instance nor for each record type.)

For menus, the needed bitwidth could be reported correctly to the CA

server, as the number of choices is fixed at compile time. This would

allow CA and the client side to optimize storage - independent from the

implementation in the IOC Database.

Possible DBD look-and-feel:

Wouldn't have to change. If the Database is implemented using predefined

fixed types, everything stays the same. Otherwise, the parametrized

types would be used instead of the fixed ones, i.e.

int32    would become  signed(32)
float64  would become  float(ieee64)
and so on.

So much for the first iteration....

Benjamin and Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System