From: Maarten B. <sou...@ds...> - 2004-10-22 08:40:47
|
Fellow developers, I would like to hear some comments on this from you. I see three approaches: 1) keep it as it is 2) change according to the request 3) accept "critical" before as well as after the function specifier and change behaviour accordingly. Your opinion please? Maarten > Feature Requests item #992518, was opened at 2004-07-16 23:13 > Message generated for change (Comment added) made by stsp > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=350599&aid=992518&group_id=599 > > Category: None > Group: None > Status: Open > Priority: 5 > Submitted By: Stas Sergeev (stsp) > Assigned to: Nobody/Anonymous (nobody) > Summary: "critical" could do better job > > Initial Comment: > Hi. > > I have a program here that sits very low on memory. > Something like 35 bytes are free. One function in that > program is a stack-eater - it eats up about 20 bytes on > a stack. If the interrupt handler is executed while whithin > that function - stack overflow. > I tried to avoid the problem by marking the stack-hungry > function "critical" to prevent the possibility of it to be > interrupted. But it still locked up after some time. > It turned out that the interrupts gets disabled after the > stack pointer gets incremented in the function prolog, > which leaves a small window where the inthandler kills > the program. > I think making sdcc to disable the interrupts before > incrementing the stack pointer, may not be difficult. > Can this be done? > Right now I have to enforce the callers to > disable/reenable interrupts themselves. > > ---------------------------------------------------------------------- > > >Comment By: Stas Sergeev (stsp) > Date: 2004-10-19 20:45 > > Message: > Logged In: YES > user_id=501371 > > Yes, but it is really only one-two asm instructions, and as the > reward you get something really usefull. > Actually, expecting that the "critical" will prevent the > stack overflows on an interrupts, is very natural. It almost > looks like a bug that it doesn't. > Note: if you want to protect only some code, you can use > the "critical" keyword locally. It is probably even the > preferred > way. So when I use it globally, I really mean that I don't care > about the higher interrupt delays, but I really want to be > protected. > > ---------------------------------------------------------------------- > > Comment By: Maarten Brock (maartenbrock) > Date: 2004-10-19 15:59 > > Message: > Logged In: YES > user_id=888171 > > This clashes with the desire to keep interrupts off as short as > possible. > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=350599&aid=992518&group_id=599 > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Jonathan D. <jdu...@ci...> - 2004-10-22 12:39:17
|
isn't possible to use a special keyword or argument parameter to use this feature ? Jonathan ----- Original Message ----- From: "Maarten Brock" <sou...@ds...> To: <sdc...@li...> Sent: Friday, October 22, 2004 4:40 AM Subject: Re: [sdcc-devel] [ sdcc-Feature Requests-992518 ] "critical" could do better job > Fellow developers, > > I would like to hear some comments on this from you. I see three > approaches: > 1) keep it as it is > 2) change according to the request > 3) accept "critical" before as well as after the function specifier and > change behaviour accordingly. > > Your opinion please? > Maarten > >> Feature Requests item #992518, was opened at 2004-07-16 23:13 >> Message generated for change (Comment added) made by stsp >> You can respond by visiting: >> https://sourceforge.net/tracker/?func=detail&atid=350599&aid=992518&group_id=599 >> >> Category: None >> Group: None >> Status: Open >> Priority: 5 >> Submitted By: Stas Sergeev (stsp) >> Assigned to: Nobody/Anonymous (nobody) >> Summary: "critical" could do better job >> >> Initial Comment: >> Hi. >> >> I have a program here that sits very low on memory. >> Something like 35 bytes are free. One function in that >> program is a stack-eater - it eats up about 20 bytes on >> a stack. If the interrupt handler is executed while whithin >> that function - stack overflow. >> I tried to avoid the problem by marking the stack-hungry >> function "critical" to prevent the possibility of it to be >> interrupted. But it still locked up after some time. >> It turned out that the interrupts gets disabled after the >> stack pointer gets incremented in the function prolog, >> which leaves a small window where the inthandler kills >> the program. >> I think making sdcc to disable the interrupts before >> incrementing the stack pointer, may not be difficult. >> Can this be done? >> Right now I have to enforce the callers to >> disable/reenable interrupts themselves. >> >> ---------------------------------------------------------------------- >> >> >Comment By: Stas Sergeev (stsp) >> Date: 2004-10-19 20:45 >> >> Message: >> Logged In: YES >> user_id=501371 >> >> Yes, but it is really only one-two asm instructions, and as the >> reward you get something really usefull. >> Actually, expecting that the "critical" will prevent the >> stack overflows on an interrupts, is very natural. It almost >> looks like a bug that it doesn't. >> Note: if you want to protect only some code, you can use >> the "critical" keyword locally. It is probably even the >> preferred >> way. So when I use it globally, I really mean that I don't care >> about the higher interrupt delays, but I really want to be >> protected. >> >> ---------------------------------------------------------------------- >> >> Comment By: Maarten Brock (maartenbrock) >> Date: 2004-10-19 15:59 >> >> Message: >> Logged In: YES >> user_id=888171 >> >> This clashes with the desire to keep interrupts off as short as >> possible. >> >> ---------------------------------------------------------------------- >> >> You can respond by visiting: >> https://sourceforge.net/tracker/?func=detail&atid=350599&aid=992518&group_id=599 >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >> Use IT products in your business? Tell us what you think of them. Give us >> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out >> more >> http://productguide.itmanagersjournal.com/guidepromo.tmpl >> _______________________________________________ >> sdcc-devel mailing list >> sdc...@li... >> https://lists.sourceforge.net/lists/listinfo/sdcc-devel >> > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out > more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > |
From: Erik P. <epe...@iv...> - 2004-10-22 15:51:50
|
On Fri, 22 Oct 2004, Maarten Brock wrote: > I would like to hear some comments on this from you. I see three > approaches: > 1) keep it as it is > 2) change according to the request > 3) accept "critical" before as well as after the function specifier and > change behaviour accordingly. > > Your opinion please? > Maarten > [Feature request #992518 asks that interrupts are disabled prior to stack frame setup rather than after for functions with the "critical" attribute] If the syntax of option #3 is implemented (so that the syntax is similar to the C standard's handling of the "inline" keyword), I would prefer that the alternate syntax not change the behavior. That is, there should only be one behavior for "critical" at the function scope. The tricky bit with implementing the request is keeping the stack offsets correct. If the psw if pushed before the stack frame is set up, the offsets to the parameters will need adjusting. Although aopGet/aopPut could compensate for this in the backend, the debugging symbols are generated elsewhere and would not reflect the offset change. This was as far as I originally pondered the request, since it seemed to need more extensive changes than I was comfortable with. On a second look, I think I see a fairly simple solution. SDCCast.c's createFunction() already handles other cases of discontinuities on the stack between a function's parameters and its local variables; we could simply add something like: if (IFFUNC_ISCRITICAL (name->type)) stackPtr -= port->stack.direction * port->stack.critical_overhead; with the appropriate additions to port.h, */main.c, and */gen.c (of course, the port implementation can set port->stack.critical_overhead to 0 if this change in behavior is inconvenient or undesired and leave the backend code generator alone). As far as I can tell, there is no run-time penalty for this change, so I would opt to implement as requested. Erik |
From: Frieder F. <fri...@we...> - 2004-10-22 16:25:16
|
Hi, maybe I'm missing something, but can't the requested functionality be achieved by this? extern void f(unsigned char c); void main() { critical { f(4); }; } This compiles to: ; genCritical setb c jbc ea,00103$ clr c 00103$: push psw ;critical2.c:6: f(4); ; genCall mov dpl,#0x04 lcall _f ; genEndCritical pop psw mov ea,c 00101$: ret Regards, Frieder |
From: Erik P. <epe...@iv...> - 2004-10-22 17:13:08
|
On Fri, 22 Oct 2004, Frieder Ferlemann wrote: > maybe I'm missing something, but can't the requested > functionality be achieved by this? > > > extern void f(unsigned char c); > void main() > { > critical > { > f(4); > }; > } Yes. But it can get a bit awkward if the function returns a value and even more so if used in a conditional: unsigned char f(unsigned char c) { // do something } void main(void) { unsigned char flag; do { critical { flag = f(4); } if (flag) { // do something } while (flag); } or: unsigned char f(unsigned char c) { // do something } void main(void) { critical { while (f(4)) { // do something } } } versus: unsigned char f(unsigned char c) critical { // do something } void main(void) { while (f(4)) { // do something } } Erik |
From: Frieder F. <fri...@we...> - 2004-10-22 18:06:38
|
Hi Erik, Erik Petrich wrote: > Yes. But it can get a bit awkward if the function returns a value and > even more so if used in a conditional: I see the point now.) Thanks for clarifying! Frieder |
From: Vangelis R. <vr...@ot...> - 2004-10-22 19:25:30
|
On Fri, 22 Oct 2004, Erik Petrich wrote: > On a second look, I think I see a fairly simple solution. SDCCast.c's > createFunction() already handles other cases of discontinuities on the > stack between a function's parameters and its local variables; we could > simply add something like: > > if (IFFUNC_ISCRITICAL (name->type)) > stackPtr -= port->stack.direction * port->stack.critical_overhead; > > with the appropriate additions to port.h, */main.c, and */gen.c (of > course, the port implementation can set port->stack.critical_overhead to 0 > if this change in behavior is inconvenient or undesired and leave the > backend code generator alone). Nice approach. I agree with you and implement it like this. There is no point in having a 'critical' function that might crash from time to time! BTW, critical isn't yet implemented in pic16, I'll fix this in the next weeks. Your proposal also gave me other ideas on how to handle stack offsets. Currently I have an ad hoc offset mechanism to modify stack offsets. Modifying createFunction() would give standard and more robust results. regards, Vangelis |
From: Maarten B. <sou...@ds...> - 2004-10-22 19:34:15
|
Hi again, Comments in the middle ;-) > > On Fri, 22 Oct 2004, Maarten Brock wrote: > > > I would like to hear some comments on this from you. I see three > > approaches: > > 1) keep it as it is > > 2) change according to the request > > 3) accept "critical" before as well as after the function specifier and > > change behaviour accordingly. > > > > Your opinion please? > > Maarten > > > [Feature request #992518 asks that interrupts are disabled prior to stack > frame setup rather than after for functions with the "critical" attribute] > > If the syntax of option #3 is implemented (so that the syntax is similar > to the C standard's handling of the "inline" keyword), I would prefer that > the alternate syntax not change the behavior. That is, there should only > be one behavior for "critical" at the function scope. That is not what I meant, I guess. I meant: critical void foo (void) { } /* go critical as early as possible */ void foo (void) critical { } /* go critical as late as possible */ Otherwise I see no reason to change the language. Or at least there is no RFE for it. And I don't like the solution of an extra parameter or more keywords either. > The tricky bit with implementing the request is keeping the stack offsets > correct. If the psw if pushed before the stack frame is set up, the > offsets to the parameters will need adjusting. Although aopGet/aopPut > could compensate for this in the backend, the debugging symbols are > generated elsewhere and would not reflect the offset change. This was as > far as I originally pondered the request, since it seemed to need more > extensive changes than I was comfortable with. > > On a second look, I think I see a fairly simple solution. SDCCast.c's > createFunction() already handles other cases of discontinuities on the > stack between a function's parameters and its local variables; we could > simply add something like: > > if (IFFUNC_ISCRITICAL (name->type)) > stackPtr -= port->stack.direction * port->stack.critical_overhead; > > with the appropriate additions to port.h, */main.c, and */gen.c (of > course, the port implementation can set port->stack.critical_overhead to 0 > if this change in behavior is inconvenient or undesired and leave the > backend code generator alone). > > As far as I can tell, there is no run-time penalty for this change, so I > would opt to implement as requested. > > Erik |
From: Vangelis R. <vr...@ot...> - 2004-10-22 21:23:41
|
----- Original Message ----- From: "Maarten Brock" <sou...@ds...> To: <sdc...@li...> Subject: Re: [sdcc-devel] [ sdcc-Feature Requests-992518 ] "critical" could do better job > > If the syntax of option #3 is implemented (so that the syntax is similar > > to the C standard's handling of the "inline" keyword), I would prefer that > > the alternate syntax not change the behavior. That is, there should only > > be one behavior for "critical" at the function scope. Right. > That is not what I meant, I guess. I meant: > critical void foo (void) { } /* go critical as early as possible */ > void foo (void) critical { } /* go critical as late as possible */ > > Otherwise I see no reason to change the language. Or at least there is > no RFE for it. And I don't like the solution of an extra parameter or > more keywords either. Why one would want to use a 'late' critical? If a function is critical ain't prologue/epilogue also critical? In addition I think it would be confusing to use the same keyword with different semantics depending on its position. I there is need for implementing both behaviours there should be two different keywords. regards, Vangelis |
From: Brian W. <bw...@ma...> - 2004-10-23 00:20:24
|
On Sat, 23 Oct 2004, Vangelis Rokas wrote: > > That is not what I meant, I guess. I meant: > > critical void foo (void) { } /* go critical as early as possible */ > > void foo (void) critical { } /* go critical as late as possible */ > > > > Otherwise I see no reason to change the language. Or at least there is > > no RFE for it. And I don't like the solution of an extra parameter or > > more keywords either. > > Why one would want to use a 'late' critical? If a function is critical > ain't prologue/epilogue also critical? > > In addition I think it would be confusing to use the same keyword with > different semantics depending on its position. I there is need for implementing > both behaviours there should be two different keywords. > The second form (as late as possible) means the gramamr for block-of-code might not need changing. [Of course the production (and code inside SDCC) is different in both case, I assume.] void foo() block_of_code .. and .. int x = start_addr(); critical { ... } // block_of_code where: block_of_code : [ "critical" ] "{" statement_list "}" ; Putting it earlier allows it to look like an "inline" modifier. I like that, cuz it feels like syntactic-sugar for the _whole_ function. inline critical const float * mywilfunc( int ) { .. } :) > > regards, > Vangelis > Food for thought. kind regards, *brian --------------------------------------------------------------------- brian witt Railroads, computers, sailboats, etc. bw...@va... |
From: Erik P. <epe...@iv...> - 2004-10-22 21:35:33
|
On Fri, 22 Oct 2004, Maarten Brock wrote: > > If the syntax of option #3 is implemented (so that the syntax is similar > > to the C standard's handling of the "inline" keyword), I would prefer that > > the alternate syntax not change the behavior. That is, there should only > > be one behavior for "critical" at the function scope. > > That is not what I meant, I guess. I meant: > critical void foo (void) { } /* go critical as early as possible */ > void foo (void) critical { } /* go critical as late as possible */ > > Otherwise I see no reason to change the language. Or at least there is > no RFE for it. And I don't like the solution of an extra parameter or > more keywords either. In the context of the current RFE, my preference is to avoid requiring genFunction() & genEndFunction() to support multiple meanings of "critical". The logic there is convoluted enough already. Erik |