Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 30 Jun 2005 16:05:54 -0500

Ralph Lange wrote:

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.

Interesting idea, although I worry slightly about what it will do to

performance. See below though...

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)

Can we add a generic 8-bit byte type, which allows specialized data

types to be stored in an array of bytes. In RDB terms this gives us BLOBs.

float_format = ieee32 | ieee64 | ieee80

I don't particularly like the "ieee32" and "ieee64" encoding, why not

just use a bitwidth?

IEEE 754 defines single precision (32-bit) and double precision (64-bit)

formats explicitly, but beyond that it defines a *class* of double

extended precision formats which are not portable between CPU families.

 SPARC uses a quadruple precision format which is 128 bits wide, while

68k and x86 have 80-bit formats which actually take 96 bits to store (16

of these are unused, and there are also endian differences which affect

the layout). I don't think we should be adding long double (ieee80)

because of this portability issue, and also because I've not heard

anyone suggesting they might need more precision.

Annotations:

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

<pedantic>

I think you mean "fundamental" rather than "atomic", to which I agree.

To me the term "atomic type" means one which can be read/written in a

single CPU read/write cycle so that it will always self-consistent even

in the presence of interrupts, DMA or multiple threads or processors

that could cause the value to be changed while you're accessing it.

</pedantic>

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

I still question the need to support unsigned integer types at all. If

we want to transfer bit-array data (the most common use for unsigned

types if you exclude Jeff's code), they should be sent as an array of bytes.

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.

Our basic array types should only support a zero-based index; anything

else can easily be derived.

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.

It's not a union (which is not type-safe); it's a pointer to an abstract

base class, and a set of derived classes with a single instance of each

type.

Inside the IOC we'd be passing around and comparing these pointers.

Hmm, those object could provide methods to allow you to manipulate and

string-convert values. We could even make use of the C++ std::type_info

class and the std::typeid() routine somehow...

Am I heading off in completely the wrong direction here?

Possible DBD look-and-feel:
Wouldn't have to change.

Agreed. In the IOC code we'll use concrete types like epicsInt32, and

the DBD file will define fields of that type using "int32".

- Andrew
--
Podiabombastic: The tendency to shoot oneself in the foot.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System