If someone is fixing the sequencer it would be good to eliminate as many
of the following warnings when building on 64-bit Linux as possible:
[epics@localhost 2-0-12]$ make > /dev/null
../devSequencer.c: In function 'seqShowScanPvtInit':
../devSequencer.c:191: warning: comparison between pointer and integer
../devSequencer.c:198: warning: comparison between pointer and integer
../devSequencer.c:199: warning: assignment makes integer from pointer
without a cast
../phase2.c: In function 'gen_defn_c_code':
../phase2.c:432: warning: format '%s' expects type 'char *', but
argument 2 has type 'struct expression *'
../phase2.c: In function 'gen_global_c_code':
../phase2.c:450: warning: format '%s' expects type 'char *', but
argument 2 has type 'struct expression *'
../phase2.c: In function 'assign_next_delay_id':
../phase2.c:592: warning: cast to pointer from integer of different size
../gen_ss_code.c: In function 'eval_delay':
../gen_ss_code.c:263: warning: cast from pointer to integer of different
size
../gen_ss_code.c: In function 'gen_action_func':
../gen_ss_code.c:302: warning: format '%s' expects type 'char *', but
argument 2 has type 'struct expression *'
../gen_ss_code.c: In function 'eval_expr':
../gen_ss_code.c:569: warning: format '%s' expects type 'char *', but
argument 2 has type 'struct expression *'
../gen_ss_code.c: In function 'special_func':
../gen_ss_code.c:633: warning: cast from pointer to integer of different
size
../gen_ss_code.c: In function 'gen_pv_func':
../gen_ss_code.c:769: warning: 'ep3' may be used uninitialized in this
function
/corvette/usr/local/epics/base-3.14.11/bin/linux-x86_64/antelope: 474
shift/reduce conflicts, 270 reduce/reduce conflicts.
In file included from ../snc.y:476:
../snc_lex.l: In function 'yy_get_next_buffer':
../snc_lex.l:446: warning: implicit declaration of function 'read'
y.tab.c: In function 'yyparse':
y.tab.c:1100: warning: implicit declaration of function 'yyerror'
../snc.y:113: warning: implicit declaration of function 'program'
../snc.y:117: warning: implicit declaration of function 'snc_err'
../snc.y:121: warning: implicit declaration of function 'program_name'
../snc.y:144: warning: implicit declaration of function 'assign_single'
../snc.y:146: warning: implicit declaration of function 'assign_subscr'
../snc.y:149: warning: implicit declaration of function 'assign_list'
../snc.y:164: warning: implicit declaration of function 'monitor_stmt'
../snc.y:173: warning: implicit declaration of function
'set_debug_print'
../snc.y:179: warning: implicit declaration of function 'decl_stmt'
../snc.y:224: warning: implicit declaration of function 'sync_stmt'
../snc.y:229: warning: implicit declaration of function 'syncq_stmt'
../snc.y:239: warning: implicit declaration of function 'defn_c_stmt'
../snc.y:243: warning: implicit declaration of function 'option_stmt'
../snc.y:256: warning: implicit declaration of function 'entry_code'
../snc.y:258: warning: implicit declaration of function 'exit_code'
../snc.y:456: warning: implicit declaration of function 'pp_code'
../snc.y:468: warning: implicit declaration of function 'global_c_stmt'
y.tab.c: At top level:
../snc_lex.l:554: warning: 'yyunput' defined but not used
../snc_lex.l:661: warning: 'yyrestart' defined but not used
../snc_lex.l:673: warning: 'yy_switch_to_buffer' defined but not used
../snc_lex.l:597: warning: 'input' defined but not used
Mark
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Eric Norum
Sent: Thursday, September 10, 2009 9:10 AM
To: Dirk Zimoch
Cc: [email protected]
Subject: Re: sequencer feature request
Yeah, I thought about that, but 200 bytes isn't that much, and this
code is not too far down a call chain, so I thought that things would
be o.k.
FWIW, stacks sizes small, medium and large on RTEMS are 5000, 8000,
and 11000 bytes, respectively.
On Sep 10, 2009, at 8:46 AM, Dirk Zimoch wrote:
> Hi Mr. Small IOC,
>
> What is the stack size of your small IOC? Is allocating 200 bytes on
> the stack OK? Apart from that, I cannot find any impact on the rest
> of the sequencer code.
>
> There are other occurrences of MAX_STRING_SIZE but they are probably
> OK:
>
> seq/seq_main.c line 98:
> #define SCRATCH_SIZE (MAX_MACROS*(MAX_STRING_SIZE+1)*12)
> But SCRATCH_SIZE is never used. It should be deleted.
>
> seq/seq_main.c line 563:
> } typeMap[] = {
> ...
> {
> "string", pvTypeSTRING, pvTypeTIME_STRING,
> MAX_STRING_SIZE, OFFSET(pvTimeString, value[0])
> },
>
> snc/phase2.c line 153:
> printf("#define MAX_STRING_SIZE 40\n");
>
> snc/phase2.c line 400:
> printf("[MAX_STRING_SIZE]");
>
> These occurrences are related to string variables and seem to be OK
> for the moment.
>
>
> I also looked for other hard coded limits and found:
>
> seq/seq_mac.c line 47:
> char name[50], *pValue, *pTmp;
>
> This limits the length of a macro name (not its value) to 49 chars.
> Probably not a serious problem but still quite unnecessary. A
> dynamic solution would be to temporarily allocate memory of the size
> of the substitution sting.
>
> The number of macros is limited to 50 by
> seq/seqPvt.h line 226:
> #define MAX_MACROS 50
> This can be made dynamic by replacing the table with a linked list
> of macros.
>
> In principle, it is not necessary to use a macro table. Whenever a
> macro is referenced, it can be looked up in the substitution string.
> The performance loss should be negligible. Macros are only looked up
> during initialization.
>
> Dirk
>
>
> Eric Norum wrote:
>> MACRO_STR_LEN is used only in that one function -- here's my
>> suggestion
>> /*
>> * Evaluate channel names by macro substitution.
>> */
>> #define MACRO_STR_LEN 200
>> LOCAL void seqChanNameEval(pSP)
>> SPROG *pSP;
>> {
>> CHAN *pDB;
>> int i;
>> pDB = pSP->pChan;
>> for (i = 0; i < pSP->numChans; i++, pDB++)
>> {
>> char cbuf[MACRO_STR_LEN+1];
>> seqMacEval(pDB->dbAsName, cbuf, MACRO_STR_LEN, pSP->pMacros);
>> pDB->dbName = epicsStrDup(cbuf);
>> #ifdef DEBUG
>> printf("seqChanNameEval: \"%s\" evaluated to \"%s\"\n",
>> pDB->dbAsName, pDB->dbName);
>> #endif /*DEBUG*/
>> }
>> }
>> On Sep 9, 2009, at 12:54 PM, Chestnut, Ronald P. wrote:
>>> Mr. Expedient here.
>>>
>>> With any luck, all the code in the sequencer uses MACRO_STR_LEN,
>>> and a change to something larger but static (perhaps 61 or 100?)
>>> might just work after a recompile. Doing something dynamic
>>> requires actual thinking and more extensive testing. How about an
>>> initial static bump with a subsequent dynamic solution?
>>>
>>> Ron Chestnut
>>>
>>>
>>> -----Original Message-----
>>> From: [email protected]
[mailto:[email protected]
>>> ] On Behalf Of Eric Norum
>>> Sent: Wednesday, September 09, 2009 6:15 AM
>>> To: [email protected] Techtalk
>>> Subject: Re: sequencer feature request
>>>
>>> Mr. Small IOC here.
>>> Rather than allocating the maximum-sized space for every single
>>> name,
>>> why not expand the name into a 'big-enough' buffer and then allocate
>>> only the required size and copy the result?
>>>
>>> On Sep 9, 2009, at 5:13 AM, Dirk Zimoch wrote:
>>>
>>>> I found several places in the code where the sequencer uses
>>>> MAX_STRING_SIZE+1 for string lengths of PV names and macros. In
>>>> EPICS base MAX_STRING_SIZE is defined as 40. For example in
>>>> seq_main.c:
>>>>
>>>> /*
>>>> * Evaluate channel names by macro substitution.
>>>> */
>>>> #define MACRO_STR_LEN (MAX_STRING_SIZE+1)
>>>> LOCAL void seqChanNameEval(pSP)
>>>> SPROG *pSP;
>>>> {
>>>> CHAN *pDB;
>>>> int i;
>>>>
>>>> pDB = pSP->pChan;
>>>> for (i = 0; i < pSP->numChans; i++, pDB++)
>>>> {
>>>> pDB->dbName = calloc(1, MACRO_STR_LEN);
>>>> seqMacEval(pDB->dbAsName, pDB->dbName, MACRO_STR_LEN, pSP-
>>>> >pMacros);
>>>> #ifdef DEBUG
>>>> printf("seqChanNameEval: \"%s\" evaluated to \"%s\"\n",
>>>> pDB->dbAsName, pDB->dbName);
>>>> #endif /*DEBUG*/
>>>> }
>>>> }
>>>>
>>>> It might help to replace those uses of MAX_STRING_SIZE+1 with
>>>> PVNAME_STRINGSZ.
>>>>
>>>> Dirk
>>>>
>>>>
>>>>
>>>> Dirk Zimoch wrote:
>>>>> I tested the sequencer with a long name and it seems that it
>>>>> truncates the PV name to 41 chars.
>>>>> A seqChanShow shows the difference between the name used in assign
>>>>> and the actual name used in CA:
>>>>> Channel name: "DZ:45678901234567890123456789012345678901"
>>>>> Unexpanded (assigned) name: "DZ:
>>>>> 456789012345678901234567890123456789012345678901234567890"
>>>>> Dirk
>>>>> Mark Rivers wrote:
>>>>>> EPICS base defines the maximum length of the PV name to be
>>>>>> PVNAME_STRINGSZ, which is currently 61 including the nil
>>>>>> terminator.
>>>>>> What length limitation does the sequencer impose? Is it more
>>>>>> restrictive than this?
>>>>>> Mark
>>>>>>
>>>>>> ________________________________
>>>>>>
>>>>>> From: [email protected] on behalf of Patrick Thomas
>>>>>> Sent: Thu 9/3/2009 6:29 PM
>>>>>> To: [email protected]
>>>>>> Subject: sequencer feature request
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I was wondering if I could ask for a feature request for the next
>>>>>> version of the sequencer? Is there any chance that it would be
>>>>>> possible
>>>>>> to use unlimited length record names in assign to statements?
>>>>>>
>>>>>> Thank you,
>>>>>> Patrick
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>> --Dr. Dirk Zimoch
>>>> Paul Scherrer Institut, WBGB/006
>>>> 5232 Villigen PSI, Switzerland
>>>> Phone +41 56 310 5182
>>>
>>> --Eric Norum <[email protected]>
>>> Advanced Photon Source
>>> Argonne National Laboratory
>>> (630) 252-4793
>>>
>>>
>>>
>> --Eric Norum <[email protected]>
>> Advanced Photon Source
>> Argonne National Laboratory
>> (630) 252-4793
>
> --
> Dr. Dirk Zimoch
> Paul Scherrer Institut, WBGB/006
> 5232 Villigen PSI, Switzerland
> Phone +41 56 310 5182
--
Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793
- Replies:
- Re: sequencer feature request Eric Norum
- References:
- sequencer feature request Patrick Thomas
- RE: sequencer feature request Mark Rivers
- Re: sequencer feature request Dirk Zimoch
- Re: sequencer feature request Dirk Zimoch
- Re: sequencer feature request Eric Norum
- RE: sequencer feature request Chestnut, Ronald P.
- Re: sequencer feature request Eric Norum
- Re: sequencer feature request Dirk Zimoch
- Re: sequencer feature request Eric Norum
- Navigate by Date:
- Prev:
Re: sequencer feature request Eric Norum
- Next:
RE: Access security problem GOURNAY Jean-Francois
- 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: sequencer feature request Eric Norum
- Next:
Re: sequencer feature request Eric Norum
- 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
|