Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Thu, 30 Jun 2005 15:38:07 -0500

I am going back to a statement that started this entire discussion. It

may not have been stated exactly as follows but it is:

"A well defined set of basic types should be defined. The basic types

can be divided into primitive (octet, int16,...,float64) and aggregate

(string array, struct) types. Other well defined types can also be

defined such as timedStamp, enum,etc."

Again the reason for defining a well defined set of basic types is so

that network applications can easily share data.

Since the data is meant to be shared by applications running on

multiple architectures and written in multiple languages, it is

important that the basic data types be well defined.

type_info should be defined so that all the basic types can be

identified.

dataAccess should adapt the set of basic types instead of using the C++

primitive types (char,short,etc).

The epicsTypes.wiki is an attempt to define such a set. It lacks a way

to define hierarchies and a way to associate array element types with

basic types but if these are defined than perhaps it is the basis for

the set of network accessible basic data types.

If dataAccess adapts these basic types then perhaps a way to define

type_info is via propertyIds, e.g.

propertyId propertyTypeOctet ("epicsTypeOctet");
propertyId propertyTypeInt16("epicsTypeInt16");
...

The set of basic types should also describes the set of basic types for

the network protocal, which requires a 1-1 mapping between the

type_info and the type id used in network packets.

Marty

On Jun 30, 2005, at 7:00 AM, Ralph Lange wrote:

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