RE: CALC expression

["Redman, Russell" <Russell.Redman@nrc-cnrc.gc.ca>]

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: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Eric Norum
Sent: Wednesday, September 29, 2010 9:15 AM
To: Andrew Johnson
Cc: tech-talk@aps.anl.gov
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
eric@norum.ca