Experimental Physics and Industrial Control System

Hi,

I have split my original answer up into ths separate sub-topics.

On Tuesday 22 February 2005 16:44, Andrew Johnson wrote:
> Marty Kraimer wrote:
> > Benjamin Franksen wrote:
> >> (1) I don't think type BOOL is needed. We can use a MENU instead, e.g.
> >>
> >> menu(menuBool) {
> >>    choice(menuBoolFalse,"False")
> >>    choice(menuBoolTrue,"True")
> >> }
> >
> > Perhaps bool is such a fundamental data type that we should support it?
>
> Both the C++ and C99 standards committees decided that bool should be
> added to their respective languages and we need a way to be able to
> interface to their types anyhow.

Of course we want to do that. That doesn't mean we have to follow C99 in 
making it a basic type. As the current proposal stands, none of the basic 
field types get directly translated to a standard C type. The intervening 
typedef is there to ensure that we can garantee sizes on each platform and 
compiler. Why should bool be any different?

[Aside: Is this definition in epicsTypes.h:

typedef int                epicsInt32;

garanteed to work even on 64 bit systems? AFAIK, int is supposed to be 
whatever is the most natural (=fast) signed integral value on the given 
architecture. Correct me if I am wrong here.]

> The problem with using a menu is that 
> an IOC designer might think they're allowed to change the menu
> definition, such as swapping the order of the choices or adding extra
> onces.

Why would anyone want to do that? I think a strong warning in the docs would 
suffice to scare off at least any non-expert. It is true that with 'include' 
as the basic tool for modularization, stability of standard definitions is 
hard to enforce. OTOH, at the moment nothing prevents users from exchanging 
the choices in menuYesNo, which would surely have fatal consequences. In 
fact, /all/ the dbd files that get compiled into the core must never be 
changed without recompiling base.

> Trying that would reveal the hidden internal dependencies that 
> exists - False must always be the first choice, and any extra choices
> will probably act as synonyms for True, but some code might not work
> with them.  I'd rather just have a fundamental type for boolean values -
> there are fields in the current dbCommon that are defined as DBF_CHAR to
> minimize memory usage (note that ENUM/MENU are both currently 16 bits),
> but which are used to hold boolean values.

I will not insist on my POV but neither am I convinced. Whether boolean is a 
basic type or not is probably not an issue important enough to warrant such a 
lengthy discussion. Therefore let me put the question into a larger context.

If we are really so concerned about memory consumption per record, then I'd 
suggest to change menu choices to use only 8 bit, at least as regards memory 
layout for records and CA data types. I'd be very much surprised if there is 
any menu definition in the world that uses more than 256 choices (other 
than /maybe/ some instances of menuConvert because of many breaktables; this 
necessity to extend menuConvert for each breaktable is a mis-feature we we 
should get rid of anyway).

OTOH, any code that handles choices internally should use plain int rather 
than any kind of size locked type; int is always the fastest integral type 
and is trivially converted from/to byte or short, signed or unsigned. Also, 
handling non-int integral values is error-prone in C because of very 
non-obvious silent integral promotions (for instance whenever you use bitwise 
operations).

One could go even further and consider dbToRecordtypeH to perform 
optimizations like using bit fields for consecutive booleans. Of course this 
would complicate the access code a bit, but if memory per record is *that* 
important, shouldn't it be worthwhile?

So long,
Ben

Replies:

EPICS base V4 Marty Kraimer

References:

Re: EPICS base V4: iocCore database Marty Kraimer

Re: EPICS base V4: iocCore database Andrew Johnson

Navigate by Date:

Prev: RE: [Fwd: RE: EPICS base V4: iocCore database] Jeff Hill

Next: Re: EPICS base V4: iocCore database: registrar, special Benjamin Franksen

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 Andrew Johnson

Next: EPICS base V4 Marty Kraimer

Index: 2002  2003  2004  <2005>  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024