On Aug 19, 2010, at 8:38 PM, Angus Gratton wrote:
> Hi Eric,
>
> On Thu, 2010-08-19 at 19:13 -0700, Eric Norum wrote:
>> The 1<<N form seems reasonable, but I'm not 100% that the bitXX names are a good idea. My concern stems from the fact that some architectures number bits from the right (which is what I presume this patch does) while others number them from the left. Thus 'bit14' is somewhat ambiguous.
>
> That seems fair enough. I hadn't considered different bit numbering
> conventions. FWIW, the documentation section describes 'bitX' as
> equivalent to '1<<X', but I can still see your point.
>
> I have no objection to swapping the string "bit" for "1<<" in the patch.
>
> The reason why I didn't go with '1<<' up front is that this implies
> there may be a more complete set of expressions available to the user.
> Which could also be nice to have, but I think would require a more
> complex parser for @asynMask fields. Unless there's one elsewhere in
> EPICS (CALC?) that could readily be plugged in?
>
Sure.
Have a look at 'postfix()' and 'calcPerform()' in the appDevGuide.
--
Eric Norum
[email protected]
- Replies:
- Re: Small patch for asynMask bitmask values Angus Gratton
- References:
- Small patch for asynMask bitmask values Angus Gratton
- Re: Small patch for asynMask bitmask values Eric Norum
- Re: Small patch for asynMask bitmask values Angus Gratton
- Navigate by Date:
- Prev:
Re: Small patch for asynMask bitmask values Angus Gratton
- Next:
procServ dies quietly when log file > 2G Bruce Hill
- 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: Small patch for asynMask bitmask values Angus Gratton
- Next:
Re: Small patch for asynMask bitmask values Angus Gratton
- 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
|