Post by thread:[PIC] 2 questions about 18f4550.

To weigh in on this a little. I am one of Canada's representatives on ISO-WG14 (Group responsible for ISO C standards) The C standards for embedded systems basically addresses three common but non standard extensions. 1) Fract and Accum data types to better support embedded applications. dSPIC type applications will probably benefit from these most. 2) Support for multiple address spaces. Most small embedded systems have multiple address spaces. Many embedded systems applications have user defined data spaces. Developers can define support for example for serial RAM located on a software driven I2C port that will be managed by the compilers symbol table. 3) Direct access to the registers including the condition code registers, which should eliminate the need for asm except for cycle specific precise timing. The kind of extension you are suggesting would not need any changes to the language definitions. C99 has an "as if" rule that allows a lot of compiler implementation creativity. "The job of an embedded system compiler is to wiggle the bits at all the right times" w.. William Killian wrote: {Quote hidden}> There is an ISO committee working on a standard embedded extension for > ISO C > > An extension could be something like 'no_return' as in use entry instead > of no-return for a function that starts off the whole processor for > reboot or any task that can not return - for multi-tasking systems any > of the task entry points. Another extension could be forcing this > 'function' to an absolute address. That embedded committee is putting > in things to allow memory partitioning so that might very well be > enough. >

Maybe they need someone like me on these committees. "As if" is all good and well. When I looked at the documents from the embedded extension documents they do indeed specifically address the issues you mention. These were discussed else where on the lists. Some of the issues I specifically addressed here have not been addressed and are not addressed by invoking the C99 "as if" rule. There is no compiler that can take a function and not generate the return or the 'as if' version of return without guidance. Such a compiler would have to be pretty good to identify a function that will never return but know it is not a mistake. I don't want the compiler to identify an endless loop condition and silently ignore it or always flag it as an error. They also did not address the ISR handler function as far as I can tell as well which is another non-standard function entrance and on all processors I have used distinctly different from either a normal function - either the full stack frame type or the ones alluded to in the parallel thread. The embedded document from 2003 is rather complex. For what it did try to address it might suit my needs or it might not. I had a lengthy comment on it but decided to just delete it as this is not an appropriate forum. > {Original Message removed}

> -----Original Message----- > From: spam_OUTpiclist-bouncesTakeThisOuTmit.edu [.....piclist-bouncesKILLspam@spam@mit.edu] On Behalf > Of piclistKILLspamxargs.com > Sent: Thursday, February 23, 2006 6:58 PM > To: Microcontroller discussion list - Public. > Subject: RE: [PIC] 2 questions about 18f4550. > > On Thu, 23 Feb 2006, William Killian wrote: > > > There is no > > compiler that can take a function and not generate the return or the 'as > > if' version of return without guidance. > > I've been using one for years that does it. I've never had a function > that mysteriously failed to return. And I'm sure this compiler is not > unique. There is nothing mysterious. Obviously I am not getting my point across. I guess I'll have to explain things more simply. When a processor starts it always jumps to some address. Jump not call. Some are direct, some are indirect but a jump is made to that address. It is not a call. Branch on some processors is a jump and on others is a call so I'll stick with the simplest jump and call terms. Now there are two approaches we can use for the first executed code, one is have a C function at that address, while the other is an assembly language mainline code as opposed to a subroutine. The C language is defined to only have subroutines called functions. It does not have non returning 'function' types. Too bad; it is indeed a weakness for embedded work and in some cases even for non-embedded. > > > Such a compiler would have to > > be pretty good to identify a function that will never return but know it > > is not a mistake. > > I don't see it as such a difficult problem. If the last statement of > the function branches to the beginning of the function, and there are > no breaks/gotos in between that branch beyond the end of the outer > loop, why would the function need a return? There is no coding problem; the problem lies elsewhere possibly in comprehension. Since I intend to assume the best about you, it seems you obviously are not getting the point. It does not need a return. You are indeed correct. That is my entire point. But, how does the compiler know that? How does it know that it can appropriately not generate any entrance and exit code? Because you wrote the function like that? What if that is an error and you would have wanted a warning about 'non reachable code' or 'function does not exit'. Sure in a non multitasking word that is sometimes 'just one function'. In a multi-tasking world it is not. Quite a few times I've stumbled across applications - such as the slot machine I am working on now - that has quite a few layers of functions called before you even get into the one that has the endless loop. This is a PIC list but the issue is relevant more to non PIC chips in this case. ------------------------------------- Notice of Confidentiality ---------------------------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify .....postmasterKILLspam.....vgt.net. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

> From: EraseMEpiclist-bouncesspam_OUTTakeThisOuTmit.edu [piclist-bouncesspam_OUTmit.edu] On Behalf > Of William Killian > > > From: @spam@piclist-bouncesKILLspammit.edu [KILLspampiclist-bouncesKILLspammit.edu] On > Behalf > > Of RemoveMEpiclistTakeThisOuTxargs.com > > Sent: Thursday, February 23, 2006 6:58 PM > > <snip> > > > Such a compiler would have to > > > be pretty good to identify a function that will never return but > know it > > > is not a mistake. > > > > I don't see it as such a difficult problem. If the last statement of > > the function branches to the beginning of the function, and there are {Quote hidden}> > no breaks/gotos in between that branch beyond the end of the outer > > loop, why would the function need a return? > > There is no coding problem; the problem lies elsewhere possibly in > comprehension. Since I intend to assume the best about you, it seems > you obviously are not getting the point. It does not need a return. > You are indeed correct. That is my entire point. > > But, how does the compiler know that? How does it know that it can > appropriately not generate any entrance and exit code? Because you > wrote the function like that? What if that is an error and you would > have wanted a warning about 'non reachable code' or 'function does not > exit'. Sure in a non multitasking word that is sometimes 'just one > function'. In a multi-tasking world it is not. Quite a few times I've > stumbled across applications - such as the slot machine I am working on > now - that has quite a few layers of functions called before you even > get into the one that has the endless loop. This is a PIC list but the > issue is relevant more to non PIC chips in this case. I've seen this handled two ways: 1) Issue a warning and generate non-returning code anyway 2) Include a special directive for the compiler I just started working with IAR C for the AVR and it uses approach #2. If I remember right they have two ways of dealing with it. An ANSI compliant #pragma and an extended __noreturn modifer. -Mike

{Quote hidden}> -----Original Message----- > From: spamBeGonepiclist-bouncesspamBeGonemit.edu [TakeThisOuTpiclist-bouncesEraseMEspam_OUTmit.edu] On Behalf > Of Michael Dipperstein > Sent: Thursday, February 23, 2006 7:45 PM > To: Microcontroller discussion list - Public. > Subject: RE: [PIC] 2 questions about 18f4550. > > > It does not need a return. > > You are indeed correct. That is my entire point. > > > > But, how does the compiler know that? How does it know that it can > > appropriately not generate any entrance and exit code? Because you > > wrote the function like that? What if that is an error and you would > > have wanted a warning about 'non reachable code' or 'function does not > > exit'. Sure in a non multitasking word that is sometimes 'just one > > function'. In a multi-tasking world it is not. Quite a few times > I've > > stumbled across applications - such as the slot machine I am working > on > > now - that has quite a few layers of functions called before you even > > get into the one that has the endless loop. This is a PIC list but > the > > issue is relevant more to non PIC chips in this case. > > I've seen this handled two ways: > 1) Issue a warning and generate non-returning code anyway > 2) Include a special directive for the compiler > > I just started working with IAR C for the AVR and it uses approach #2. > If I remember right they have two ways of dealing with it. An ANSI > compliant #pragma and an extended __noreturn modifer. > > -Mike The entire point has been, "it would be nice if the ISO committee recommended a 'standard' special directive for non-returning functions". Of course that leads to some portability not across platforms but across compilers - some vendors might tremble at that. Some small code space savings that is more significant on small microcontrollers than larger ones with larger address spaces. Plus a bit of that clichÃ©d self-documentation to code. Others were sort of hinting at that as well but not always actually saying such. Few of the compilers I'ev used had such directives - might be that I've spent far more C or C++ time on processors not necessarily destined for embedded use like the several RISC, current Intel and 68K families. ------------------------------------- Notice of Confidentiality ---------------------------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify RemoveMEpostmasterTakeThisOuTvgt.net. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

> -----Original Message----- > From: piclist-bouncesEraseME.....mit.edu [EraseMEpiclist-bouncesmit.edu] On Behalf {Quote hidden}> Of RemoveMEpiclistEraseMEEraseMExargs.com > Sent: Thursday, February 23, 2006 8:46 PM > To: Microcontroller discussion list - Public. > Subject: RE: [PIC] 2 questions about 18f4550. > > On Thu, 23 Feb 2006, William Killian wrote: > > > But, how does the compiler know that? How does it know that it can > > appropriately not generate any entrance and exit code? Because you > > wrote the function like that? > > Yes. Just like any other construct, I expect the compiler to > interpret it the way I wrote it. I am certainly not that perfect. > > What if that is an error and you would > > have wanted a warning about 'non reachable code' or 'function does not > > exit'. > > I don't want that warning, but if I did, I would tell my compiler > vendor I think a necessary warning is missing from their compiler. > But I'm more interested in having the compiler not generate dead code > than having it generate superfluous warnings on standard constructs. You don't want any compilers errors or warnings except the ones you want and they are required. I'm done. I'm afraid of perfect people. ------------------------------------- Notice of Confidentiality ---------------------------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify RemoveMEpostmasterspam_OUTKILLspamvgt.net. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.