RE: EPICS base V4: iocCore database

[Jeff Hill <johill@lanl.gov>]

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.

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. 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. For
links it might be important to specify the starting element when
targeting a slice from another record's array.

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.

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

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

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

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

Jeff



> -----Original Message-----
> From: Marty Kraimer [mailto:mrk@aps.anl.gov]
> Sent: Friday, January 14, 2005 8:20 AM
> To: Marty Kraimer; Bob Dalesio; Ned Arnold; Andrew Johnson;
> Eric Norum; Janet Anderson; Jeff Hill; Ralph Lange; Matej
> Sekoranja; Ken Evans; Benjamin Franksen
> Subject: Re: EPICS base V4: iocCore database
> 
> I have updated the www page at:
> 
> http://www.aps.anl.gov/asd/people/mrk/epics/base/V4
> 
> I will be on vacation for two weeks visiting my daughter in
> Australia. I
> will take my laptop are try to keep up on any Email messages
> the updated
> www page generates.
> 
> Marty