EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <2010>  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <2010>  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>
Subject: RE: CALC expression
From: "Redman, Russell" <[email protected]>
To: "Eric Norum" <[email protected]>, "Andrew Johnson" <[email protected]>
Cc: [email protected]
Date: Wed, 29 Sep 2010 10:30:27 -0700
I do not do much EPICS anymore, but this thread triggers memories on annoying issues.  The main issue seems to be memory usage, but this affects many other aspoects of the IOC. 
 
Can I make a suggestion that the length of the CALC field be fixed by the designer, but configurable through a new field, perhaps called CLEN.  The default value of CLEN would of course be 40 if not otherwise specified.
 
Yes, I know that this is a BIG change in a fundamental record type and must be handled with real care for backwards compatability.  It is surely too late to make such a major change in the 3.14 code, but aiming the change at 3.15 would give time to think the issues through in more detail.
 
Some points:
1) Most CALC expressions are quite small and fixed, so in memory-challenged applications it would be useful to set CLEN to some small number like 5.
 
2) If increasing the size of CALC makes RPCL too big, can I point out that cascading CALC records because the CALC field is too small also chews up memory. 
 
3) Expressions can be considerably clarified with the addition of whitespace and parentheses, but the current tight limitation seriously discourages developers from including these useful characters.  Anthing that improves the clarity of the calculation will cut developer time and make subsequent maintenace easier.
 
4) Cascading CALC records because the CALC field is too small makes the expressions more difficult to read, and the overhead of processing multiple records can impact the performance of the whole IOC.
 
5) Way back, around 2004 I think it was, Tim Mooney helped me with a with a customization of the postfix and calcPerform routines that allowed expressions like MAX(A,B,C), which are much more compact than MAX(A,MAX(B,C)).  These never made it into base because they broke expressions like A?B, which I never used because they leave unpredictable numbers of items on the stack, but which turn out to be common in some applications.  If the CALC record is reworked, can I suggest that this issue be re-examined at the same time?
I will shut up now,
Russell O. Redman
From: [email protected] [mailto:[email protected]] On Behalf Of Eric Norum
Sent: Wednesday, September 29, 2010 9:15 AM
To: Andrew Johnson
Cc: [email protected]
Subject: Re: CALC _expression_

On Sep 29, 2010, at 9:02 AM, Andrew Johnson wrote:
...

We *could* make RPCL into a char* pointer and allocate it dynamically
according to the particular _expression_, but that means making code changes to
the record and also opens up the possibility of free memory fragmentation on
vxWorks IOCs (none of the other standard record types allocate memory after
initialization to avoid that).  I think it's too late to make those kind of
changes at this point.
How long has it been since someone actually tested vxWorks to see if it still exhibit this fragmentation issue?
Sometimes urban legends are just that.


Alternatively we could add integer literal support to the code in libCom/calc,
which would reduce the incremental expansion factor from 21/4 to 10/3 or
better, but again that would be making code changes uncomfortably late in the
development cycle for 3.14.12.
Are the changes that extensive?


I would not worry /too/ much about wasted space.  After all, every record
has a 41-character DESC field, most of them are permanently empty, and I
don't recall hearing complaints about that.

Making CALC 80 translates to RPCL being 419 bytes instead of its current 209
bytes.  Lewis' suggestion of 64 bytes translates to RPCL being 335 bytes.

Do any small-IOC guys want to weigh in on these suggestions?
I'm about ready to admit defeat.
Plus, making the integer literal change could make the RPCL increase much less significant (or even non-existent)

-- 
Eric Norum
[email protected]




Replies:
Re: CALC expression Ralph Lange
Re: CALC expression Andrew Johnson
References:
CALC expression Andrew Wagner
Re: CALC expression Andrew Johnson
Re: CALC expression Tim Mooney
Re: CALC expression Andrew Johnson
Re: CALC expression Eric Norum
Navigate by Date:
Prev: Re: archiving system emmanuel_mayssat
Next: Re: CALC expression Ralph Lange
Index: 1994  1995  1996  1997  1998  1999  2000  2001  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: CALC expression Andrew Johnson
Next: Re: CALC expression Ralph Lange
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <2010>  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 29 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·