Experimental Physics and Industrial Control System

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'.

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

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  <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: dataAccess Jeff Hill

Next: Re: EPICS base V4: iocCore database 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