Searching \ for '[PIC] 2 questions about 18f4550.' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=18F
Search entire site for: '2 questions about 18f4550.'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] 2 questions about 18f4550.'
2006\02\23@164414 by Walter Banks

picon face
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}

2006\02\23@180443 by William Killian

flavicon
face
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}

2006\02\23@185817 by piclist

flavicon
face
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.

> 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?

--
John W. Temples, III

2006\02\23@192309 by William Killian

flavicon
face


> -----Original Message-----
> From: spam_OUTpiclist-bouncesTakeThisOuTspammit.edu [.....piclist-bouncesKILLspamspam@spam@mit.edu] On
Behalf
> Of piclistspamKILLspamxargs.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
.....postmasterKILLspamspam.....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.

2006\02\23@194437 by Michael Dipperstein

face
flavicon
face


> From: EraseMEpiclist-bouncesspam_OUTspamTakeThisOuTmit.edu [piclist-bouncesspamspam_OUTmit.edu] On
Behalf
> Of William Killian
>
> > From: @spam@piclist-bouncesKILLspamspammit.edu [KILLspampiclist-bouncesKILLspamspammit.edu] On
> Behalf
> > Of RemoveMEpiclistTakeThisOuTspamxargs.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}

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

2006\02\23@204610 by piclist

flavicon
face
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.

> 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.

--
John W. Temples, III

2006\02\24@102235 by William Killian

flavicon
face

{Quote hidden}

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
RemoveMEpostmasterspamTakeThisOuTvgt.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.

2006\02\24@104723 by William Killian

flavicon
face


> -----Original Message-----
> From: piclist-bouncesEraseMEspam.....mit.edu [EraseMEpiclist-bouncesspammit.edu] On
Behalf
{Quote hidden}

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_OUTspamKILLspamvgt.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.

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...