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  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: EPICS base V4: iocCore database
From: Marty Kraimer <mrk@aps.anl.gov>
To: benjamin.franksen@bessy.de, Andrew Johnson <anj@aps.anl.gov>, Marty Kraimer <mrk@aps.anl.gov>
Date: Mon, 21 Feb 2005 10:36:10 -0600


Benjamin Franksen wrote:

Hi Marty

On Friday 18 February 2005 18:12, you wrote:
I have again updated dbd.html which is available via

http://www.aps.anl.gov/asd/people/mrk/epics/base/V4

I have received  a lot of input from Andrew. Many of the changes result
from Andrew's suggestions.

I have not received any input from anyone else. I guess that means
everyone thinks it is great :-)

I began writing this as soon as I got your first message. Then I got stuck because I had the feeling I need to understand the problems better before sending comments. I still think so but anyway, here we go:

(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?


(2) The keyword "registrar" is obscure, IMO. Why not name it something like "function" (in accordance with keyword "variable")?

Andrew,

What about this and also variable. What do we want to do for V4?

(3) record support's special: At the moment, special processing is not as useful as it could be. This is because the new value is only accessible after the old value has been overwritten. We can save the old value in another field (permanently wasting storage) or we can malloc/free storage in pass 0/1 (wasting processing time). Ideally we would want (the possibility to) to save the old value temporarily on the stack.

I order to do this, we must give a function argument to the special routine, so that special can be defined like this:

long special(putAction *put, dbAddr *pdbaddr, putArgs *pargs)
{
   do_stuff_before_the_put();
   put(pargs);
   do_stuff_after_the_put();
}

The 'pass' argument is no longer needed, but instead we need to pass a routine that actually overwrites the field, together with the needed arguments (like dbr type, options, etc) packed together into a structure 'putArgs'.


Interesting thought. Of couse storage must be obtained for putArgs but that is not much difference than dbAddr.


(4) include "filename": At the moment it is used for two purposes:

(a) At the beginning of a record type declaration. This is poor man's inheritance. It can be replaced by *naming a struct or record type* to be included at this point. (The same goes for the new 'struct'). Like this:

struct(dbCommon) {
   fields...
}

record(name) {
   inherit "dbCommon"
   fields...
}

The "inherited" part can be declared in the same file, or imported from another one (see (b) below).

The same mechanism can be used for menus.

(b) At the top-level: This is poor man's modularization. But complete textual inclusion is often too coarse. I propose a limited form of module import (allowed only at the top-level):

import <module-name> (<element-name>, ...)

for element-wise import (i.e. only the listed names are imported) or

import <module-name> [ hiding (<element-name>, ...) ]

for importing everything, where the optional 'hiding' clause can be used to list names that should not be imported. <module-name> would be the filename of the imported module without the extension.

I will let Andrew comment about include since he has thought more about parsing dbd files than anyone.

More comments will follow...

Ben




Replies:
Re: EPICS base V4: iocCore database Benjamin Franksen
Re: EPICS base V4: iocCore database Andrew Johnson

Navigate by Date:
Prev: Re: [Fwd: RE: EPICS base V4: iocCore database] Ralph Lange
Next: Re: EPICS base V4: iocCore database Marty Kraimer
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: RE: dataAccess Jeff Hill
Next: Re: EPICS base V4: iocCore database Benjamin Franksen
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
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 ·