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

> From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On
Behalf

> Of Walter Banks

> Sent: Thursday, February 23, 2006 4:43 PM

> To: Microcontroller discussion list - Public.

> Subject: Re: [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:

> 

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

> >

> 

> 

> --

> 

> View/change your membership options at

> http://mailman.mit.edu/mailman/listinfo/piclist



-------------------------------------  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 
postmaster@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.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist