Experimental Physics and Industrial Control System
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
- Replies:
- RE: EPICS base V4: iocCore database Jeff Hill
- References:
- RE: EPICS base V4: iocCore database Jeff Hill
- Navigate by Date:
- Prev:
RE: EPICS base V4: iocCore database Jeff Hill
- Next:
Re: [Fwd: RE: EPICS base V4: iocCore database] Ralph Lange
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: EPICS base V4: iocCore database Jeff Hill
- Next:
RE: EPICS base V4: iocCore database Jeff Hill
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024