Experimental Physics and Industrial Control System
Benjamin Franksen wrote:
Hello,
I must say that I strongly agree with most of Jeff's arguments. (Maybe
not so much the 'unsigned' story, but practically everything else).
The current definition of epicsTypes does NOT include unsigned types.
The reason is Java. If we allow unsigned types it makes it very
difficult to complely support Java.
The only place we see that V3 epics records need unsigned is for bit masks.
However there is a big problem with the mask fields in the the mbbXXX
records.
The mask field is 32 bits. How do we handle a 64 bit I/O module?
OK with V4 we can make the mask fields be 64 bits.
But how do we handle a 128 digital I/O module?
Also a 16 bit digital I/O module has many unused bits.
A way to handle this is to make the mask fields an array of octets.
The byte and bit order must still be decided but at least any multiple
of 8 bits can be handled.
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?
Ben
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".
Marty
- Replies:
- RE: Fundamental Types document Jeff Hill
- Re: Fundamental Types document Ralph Lange
- Re: Fundamental Types document Benjamin Franksen
- References:
- RE: Fundamental Types document Jeff Hill
- Re: Fundamental Types document Benjamin Franksen
- Navigate by Date:
- Prev:
Re: Fundamental Types document Marty Kraimer
- Next:
RE: Fundamental Types document 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
- Navigate by Thread:
- Prev:
Re: Fundamental Types document Benjamin Franksen
- Next:
RE: Fundamental Types document 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