At 06:38 AM 5/6/2005, Robert Adsett wrote: >... > > > >Never trust the compiler for this sort of work. Do it in > >assembler. I've > > > >run into too many compilers with either poor or outright broken > >code > > > >generation in this area to ever rely on it. > > > > > > > >Robert > > > > > > That's kind of sad statement to make. > > > >That might seem sad and cynical, but I think it is true. > > > >THose compilers that generate ISR wrappers with prgmas etc only cater > >for a limited interrupt handling model. To get a reliable system you > >are far better off doing all the interrupt wrapping yourself in > >assembly, then calling regular C functions (without wierd attributes). > >This gives you more flexibility (different irq models), better > >portability (between compilers) and better maintainability (more > >predictable, not subject to problems with different versions of > >compilers). > >Well put. In the end compiler writers have limited resources to develop >and test. If I have a choice about where I want them to put their efforts >it's in basic code generation. Interrupt epilogue and prologue (or task >switching or machine register access or.... ) are easily handled in >assembly leaving the bulk of the code to standard C or C++ code. > >Robert Keep in mind that I am one of those compiler writers. Regardless whether a compiler company can reasonably support certain extensions that some customers may need, my comments about it being "sad statement to make" is a response to your statement basically saying that you were not getting good results from the compilers and the implications is that you were not getting good responses from the compiler vendors for support either. // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com)
Message
Re: [lpc2000] Re: IAR C and FIQ isr
2005-05-06 by Richard
Attachments
- No local attachments were found for this message.