EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Fundamental Types document
From: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Sat, 18 Jun 2005 00:53:47 +0200
On Thursday 16 June 2005 17:34, Marty Kraimer wrote:
> Benjamin Franksen wrote:
> >I am astonished that we have this kind of discussion again. I may be
> >mistaken but I had the impression that it was agreed upon to use DA
> > for IOC internal acess to records and to abandon the efforts Marty
> > started to define internal implementation of epics types until we
> > have got the interfaces right. And that dbd definitions should be
> > compiled into C/C++ code implementing DA interfaces, views, etc.pp.
> >
> >If indeed DA does not suffice as a (the) generic interface to record
> >fields, as Andrew suggested, then maybe DA should be extended or
> >revised accordingly?
>
> At some point something other than interfaces has to be created!!
> What Andrew and I are attempting is to define a small basic set of
> standard types including strings and arrays that have built-in
> support. For these types it should be easy to gererate code that
> implements dataAccess interfaces to access the data.
>
> Does anyone really want to have record support, device support, etc
> ALL access data only via dataAccess?
> That means everything will need to provide it's own set of code to
> use dataAccess. I am again haunted by Doug's request for "hello
> world".

My apologies, I didn't quite get the point here, obviously.

Of course, we need a /representation/ of the various kinds of data that 
can be specified in a dbd file. And of course record support 
should /not/ need to go through DA to access its own record data but 
instead should access this data in the most direct manner possible.

I always imagined the data representation to be as low-level and 
immediate as possible. I see no need to make access to it generic in 
any way, other than providing the DA interface.

For instance, a dbd-struct is translated as a C struct. No more, no 
less. No need for introspection, since the record support (or struct 
support, if there is one) includes the header file and is anyway 
specialized to this one record type only. Everything else is taken care 
of by the generated implementation of the DA interface which, I repeat, 
will typically not be used by record support. After reading teh 
epicsTypes document, I think we agree here.

Regarding enums: Have I mentioned that enums are just a special case of 
tagged unions? <grin> Anyway, these can be represented as a C struct 
containing tag (integer) and optionally a C union containing additional 
data. For plain enums the C union is left out, thus there are no other 
fields beside the tag in this struct. I really don't see the point in 
carrying a pointer to the table of string representations (plus a 
pointer to the virtual function table) along with each copy of the 
index value, as is done in class EpicsEnum. Why not simply /generate/ 
overloaded C++ inline functions for each enum type that handle the 
string-to-index (and vice versa) conversion, using the array of strings 
specified as a property to the enum field? I take it the 
string-array /itself/ (though not its data) is a statically known 
entity and its address can thus be hard-coded into these generated 
routines. And since now each enum field has its own type (because it is 
always wrapped inside a struct) we can use C++ overloading to 
statically dispatch on the type at compile time. And BTW, please let us 
use plain int for the index and /not/ epicsUInt16 or the like. A size 
locked type is /not/ necessary here, and saving the two bytes is 
ridiculous if one is OTOH willing to carry alltogether *two* pointers 
along with each enum value, both of which are absolutely unnecessary 
with the approach I sketched above. And also BTW, having a separate 
type for each of these enum fields is Good Thing, since mixing 
different enum indexes in an expression is most probably an error.

(Multidimensional) arrays and strings are an alltogether different 
matter. The reason is that they require dynamic memory management; 
arrays and strings have no fixed size. I agree that there is a need to 
provide ADTs for these, and it probably makes sense to provide an 
abstract framework to capture the commonalities.

Morale: The key points to make low-level access to record fields type 
safe, convenient and still as efficient as possible are:

* C++'s ability to dispatch on types at compile time (overloading)
* C++'s inline functions
* a decision to generate from dbd definitions not only data layout but 
also a number of (low-level) access routines exploiting the above 
features

Cheers,
Ben

References:
RE: Fundamental Types document Jeff Hill
Re: Fundamental Types document Benjamin Franksen
Re: Fundamental Types document Marty Kraimer

Navigate by Date:
Prev: Re: Fundamental Types document / unsigned integers Eric Norum
Next: RE: Fundamental Types / Gateway Jeff Hill
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Fundamental Types document / unsigned integers Jeff Hill
Next: V4 Data Types: Request for tagged unions Ralph Lange
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·