From: Antonio T. B. <an...@pr...> - 2012-08-25 21:56:00
|
Is There someone analyzing the document? http://www.microchip.com/mplabxc8guide Specially the Chapter 2, about CCI (Common C Interface) Think that some changes in the newest SDCC version are very near to this idea, i.e. CONFIG pragma Well... IMHO, could be good to follow the same syntax to promote a standard and encourage the portability from XC8 and others to SDCC in the future. We are not so far this. I.e. __asm could have an replace macro as asm() (2.5.15 at that doc), but interrupts declarations are so far this that I cannot think how to do this. Comments? Regards, Antonio Augusto Todo Bom Neto Boole Embedded gTalk: an...@bo... Office....: +55 41 3015-2819 (Curitiba) TIM-Mobile: +55 41 9942-9245 (Curitiba) TIM-Mobile: +55 12 8171-1222 (São J. dos Campos - SP) Utilize a imagem abaixo para inserir meu cartão de visitas diretamente em seu smartphone. *Please, use the image below to insert my contact* *card directly **into **your smartphone.* Para Iphone experimente o app leitor bakodo<http://itunes.apple.com/us/app/bakodo-scanner/id371932548?mt=8> Para Android experimente o ZXing Barcode Reader<http://code.google.com/p/zxing/downloads/detail?name=BarcodeScanner3.51b1.apk&can=2&q=> *To Iphone, you can use** bakodo<http://itunes.apple.com/us/app/bakodo-scanner/id371932548?mt=8> reader app.* *To Android use ZXing Barcode Reader<http://code.google.com/p/zxing/downloads/detail?name=BarcodeScanner3.51b1.apk&can=2&q=> apk* |
From: Philipp K. K. <pk...@sp...> - 2012-08-26 04:09:59
|
On 26.08.2012 06:55, Antonio Todo Bom wrote: > Is There someone analyzing the document? > http://www.microchip.com/mplabxc8guide > > Specially the Chapter 2, about CCI (Common C Interface) > > Think that some changes in the newest SDCC version are very near to this > idea, i.e. CONFIG pragma > > Well... IMHO, could be good to follow the same syntax to promote a > standard and encourage the portability from XC8 and others to SDCC in > the future. > > We are not so far this. I.e. __asm could have an replace macro as asm() > (2.5.15 at that doc), but interrupts declarations are so far this that I > cannot think how to do this. > > Comments? > > Regards, > > Antonio Augusto Todo Bom Neto > Boole Embedded 1) AFAIK, the CCI is a kind of Microchip Technology Ltd. company standard. For them it seems like a big step in the right direction, since it seems more standard-compliant than what they did before (e.g. __near instead of near). 2) Programmers should try to rely on implementation-defined behaviour as less as possible. That one will avoid most portability issues by itself. 3) IMO, the C standard itself is the most important thing sdcc should follow. This IMO fully includes the ISO C90, C99 and C11 standards, and to some degree the embedded C standard. There is still work to be done here, which IMO is more important. 4) CCI does some things in a different way from the standard, e.g. C11 _Alignas vs. CCI __align. This doesn't mean we should never support the CCI way, too; but IMO supporting the standard way is what matters. 5) Not everything in the CCI makes sense for non-PIC processors, and the non-PIC processors is what currently works in sdcc. For the pics the priority should IMO be to make the ports work (i.e. pass regression tests). 6) 2.5.1 mandates all compiler-specific stuff to reside in xc.h. Doing so will break existing code, which IMO is not worth it. 7) Nevertheless we should keep CCI in mind. In an ideal case, a more cross-vendor standard will evolve, maybe in the form of an update of the Embedded C standard. AFAIK, the popular MISRA-C also places some requirements on the implementation (though it is mostly a coding standard). Philipp |
From: Sebastien L. <seb...@lo...> - 2012-08-27 12:50:29
|
Hello, said shortly, this CCI seems to be a microchip tentative to encapsulate a load a proprietary microchip concepts, and arbitrary programming practices into a "specification everyone should follow". xc ic the brand name for microchip's new compilers in mplabx. on the other hand, CCI's role is clear enough: CCI-conforming code would make it easier to port from a PIC18 MCU using the MPLAB XC8 C compiler to a PIC24 MCU using the MPLAB XC16 C compiler. Regards, Sebastien Le 26/08/2012 06:09, Philipp Klaus Krause a écrit : > On 26.08.2012 06:55, Antonio Todo Bom wrote: >> Is There someone analyzing the document? >> http://www.microchip.com/mplabxc8guide >> >> Specially the Chapter 2, about CCI (Common C Interface) >> >> Think that some changes in the newest SDCC version are very near to this >> idea, i.e. CONFIG pragma >> >> Well... IMHO, could be good to follow the same syntax to promote a >> standard and encourage the portability from XC8 and others to SDCC in >> the future. >> >> We are not so far this. I.e. __asm could have an replace macro as asm() >> (2.5.15 at that doc), but interrupts declarations are so far this that I >> cannot think how to do this. >> >> Comments? >> >> Regards, >> >> Antonio Augusto Todo Bom Neto >> Boole Embedded > 1) AFAIK, the CCI is a kind of Microchip Technology Ltd. company > standard. For them it seems like a big step in the right direction, > since it seems more standard-compliant than what they did before (e.g. > __near instead of near). > > 2) Programmers should try to rely on implementation-defined behaviour as > less as possible. That one will avoid most portability issues by itself. > > 3) IMO, the C standard itself is the most important thing sdcc should > follow. This IMO fully includes the ISO C90, C99 and C11 standards, and > to some degree the embedded C standard. There is still work to be done > here, which IMO is more important. > > 4) CCI does some things in a different way from the standard, e.g. C11 > _Alignas vs. CCI __align. This doesn't mean we should never support the > CCI way, too; but IMO supporting the standard way is what matters. > > 5) Not everything in the CCI makes sense for non-PIC processors, and the > non-PIC processors is what currently works in sdcc. For the pics the > priority should IMO be to make the ports work (i.e. pass regression tests). > > 6) 2.5.1 mandates all compiler-specific stuff to reside in xc.h. Doing > so will break existing code, which IMO is not worth it. > > 7) Nevertheless we should keep CCI in mind. In an ideal case, a more > cross-vendor standard will evolve, maybe in the form of an update of the > Embedded C standard. AFAIK, the popular MISRA-C also places some > requirements on the implementation (though it is mostly a coding standard). > > Philipp > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: Philipp K. K. <pk...@sp...> - 2012-08-27 13:15:32
|
On 27.08.2012 21:48, Sebastien Lorquet wrote: > Hello, > > said shortly, this CCI seems to be a microchip tentative to encapsulate a load a > proprietary microchip concepts, and arbitrary programming practices into a > "specification everyone should follow". > > xc ic the brand name for microchip's new compilers in mplabx. > > on the other hand, CCI's role is clear enough: > CCI-conforming code would make it easier to port from a PIC18 MCU using the > MPLAB XC8 C compiler to a PIC24 MCU using the MPLAB XC16 C compiler. > > Regards, > Sebastien IMO, another important aspect is trying to make programmers feel good about writing non-portable code, as long as they follow the CCI - code which will be easy to port between PICs, but not to other platforms. Philipp |
From: John P. <jd...@sy...> - 2012-08-25 22:30:15
|
this kind of portability (between compilers for a target) is good for work related to code generation On Sat, Aug 25, 2012 at 5:55 PM, Antonio Todo Bom <an...@pr...>wrote: > Is There someone analyzing the document? > http://www.microchip.com/mplabxc8guide > > Specially the Chapter 2, about CCI (Common C Interface) > > Think that some changes in the newest SDCC version are very near to this > idea, i.e. CONFIG pragma > > Well... IMHO, could be good to follow the same syntax to promote a standard > and encourage the portability from XC8 and others to SDCC in the future. > > We are not so far this. I.e. __asm could have an replace macro as asm() > (2.5.15 at that doc), but interrupts declarations are so far this that I > cannot think how to do this. > > Comments? > > Regards, > > Antonio Augusto Todo Bom Neto > Boole Embedded > > -- http://www.google.com/profiles/john.douglas.pritchard |