"Sergio Masci" <sergio@NO.SPAM.xcprod.com> writes:> You don't need a new storage class to do this. The compiler just needs to be > intelligent enough to analyse the code, determin that a function is not > reenterent and allocate locals accordingly.The compiler doesn't really have enough information to deternine that. Suppose you have a source file like this: extern void func1 (int c); static void func2 (int b) { int foo = b % 6; // do some stuff with foo func1 (foo - 7); // do some other stuff with foo } void func3 (int a) { func2 (a + 3); } Even though func2() is declared static, and even though there is only a single place that calls func2(), the compiler cannot determine whether it can be called recursively because it has no way to know whether the external func1() might call func3(). The best the compiler can do in this case is decide that func2 *might* be called recursively, and thus take the proper actions to guarantee that local variable foo meets the defined semantics for the automatic storage class. Typically this would involve storing foo in a stack frame, or pushing it prior to the call to func1() and restoring it afterward, though other mechanisms not involving a stack could also be used. If you restrict the program to a single compilation, or get the linker involved, you can statically determine which functions are not recursively called provided that you don't use function pointers. The point of my suggestion is that the programmer generally has some idea as to whether the function can be called recursively (though he or she may be mistaken), and it is much easier for the programmer to provide a hint to the compiler than for the compiler to figure it out.
Which PIC18 C Compiler?
Started by ●July 8, 2004
Reply by ●July 9, 20042004-07-09
Reply by ●July 10, 20042004-07-10
On Thu, 8 Jul 2004 15:34:43 -0500, "Talal Itani" <titani@airmail.net> wrote:>Hello, > >I currently have an ICD2 from Microchip. I use it to develop PIC16 code >using the MPLAB debugger and assembler. I need to move to the PIC18 parts >and C language, but I am struggling figure out the development tools to get. >Do you have any experience with the CCS compiler running with MPLAB and >ICD2? ($175 solution) > >Thanks, >Talal >I am wondering why you choose the 18 series PICs at all. I suggest to use the Atmel AVR flash MCU for development in c language. I think the Atmel parts offer better value for money and are very well suited to c language. Imagecraft sell a very efficient ansi C compiler for the AVR for $200. I can't recommend this highly enough. best regards, Johnny.
Reply by ●July 10, 20042004-07-10
>The compiler doesn't really have enough information to deternine that.It does, but not when compiling a separate file. Classic C compilers don't do much when sperately compiled files are linked, but that is the moment such information is available. One more argument against separate compilation for (small) embedded programs. Wouter van Ooijen -- ------------------------------------ http://www.voti.nl PICmicro chips, programmers, consulting
Reply by ●July 10, 20042004-07-10
"Johnny" <john_wr@NOSPAM.hotmail.com.> wrote in message news:vb4ve0haqkhm85bqmu0bsdv8nodsienlta@4ax.com...> On Thu, 8 Jul 2004 15:34:43 -0500, "Talal Itani" <titani@airmail.net> > wrote: > > >Hello, > > > >I currently have an ICD2 from Microchip. I use it to develop PIC16 code > >using the MPLAB debugger and assembler. I need to move to the PIC18parts> >and C language, but I am struggling figure out the development tools toget.> >Do you have any experience with the CCS compiler running with MPLAB and > >ICD2? ($175 solution) > > > >Thanks, > >Talal > > > > I am wondering why you choose the 18 series PICs at all. I suggest to > use the Atmel AVR flash MCU for development in c language. I think > the Atmel parts offer better value for money and are very well suited > to c language. Imagecraft sell a very efficient ansi C compiler for > the AVR for $200. I can't recommend this highly enough. > > best regards, > Johnny.Why stick with eight bit if he's going to consider a change ? Most of the new and just to be released arm7 parts from Philips, Atmel, Analog, ST and others are around the same price in small quantity as pics and other 8 bitters. Philips -lpc2000 http://semiconductors.philips.com/catalog/219/282/45988/45993/index.html#45993 Analog http://www.analog.com/IST/SelectionTable/?selection_table_id=212 http://www.analog.com/Analog_Root/sitePage/mainSectionHome/0,2130,level4%253D%25252D1%2526Language%253DEnglish%2526level1%253D117%2526level2%253D140%2526level3%253D%25252D1,00.html Atmel Sam7 http://www.atmel.com/dyn/products/product_card.asp?part_id=3397 ST http://www.st.com/stonline/products/support/micro/arm/str7.htm eg http://semiconductors.philips.com/pip/LPC2106.html philips lpc2106 128KB flash 64KB ram 60MHz , 2x usart, spi, I2C, 6x pwm , also available in -40 to +85 http://semiconductors.philips.com/pip/LPC2129.html philips lpc2129 256KB flash 16KB ram 60MHz 4x 10 bitADC, 2x usart, spi, I2C, 6x pwm, 2x CAN , -40 to +85 philips supposedly to release a chip next year with usb and another with ethernet link to dev tools http://semiconductors.philips.com/markets/mms/products/microcontrollers/support/development_tools/tools_by_family/arm7tdmi/index.html choice of compilers around about 15 or so with more on the way gcc arm - ads IAR Green hills keil own compiler still beta, currently supply repackaged gcc Apogee Intel Microsoft for windows ce Metaware TI WindRiver compilers on the way Borland, Imagecraft Alex
Reply by ●July 10, 20042004-07-10
I wrote:> The compiler doesn't really have enough information to deternine that.wouter@voti.nl (Wouter van Ooijen (www.voti.nl)) writes:> It does, but not when compiling a separate file. Classic C compilersYes, I explained that in my post if you'll read it carefully. However, in most non-trivial C programs there is some use of function pointers. If a pointer to a function anywhere but at the leaves of the call graph is stored, it is unlikely that the compiler can then prove that functions that are not leaves are not called recursively. I have yet to see any C compilation system for the PIC that does interprocedural optimization, let alone optimization across multiple source files, so the ability to provide hints to the compiler as I suggested would still be useful. Since it's unlikely to be adopted as part of the C standard, a compiler vendor that wanted to do this could provide it as an implementation-defined pragma.
Reply by ●July 10, 20042004-07-10
Pete Fenelon wrote:> In comp.arch.embedded Talal Itani <titani@airmail.net> wrote: >> Hello, >> >> I currently have an ICD2 from Microchip. I use it to develop PIC16 code >> using the MPLAB debugger and assembler. I need to move to the PIC18 >> parts and C language, but I am struggling figure out the development >> tools to get. Do you have any experience with the CCS compiler running >> with MPLAB and ICD2? ($175 solution) >> > > If you're going for C on the PIC18, the only professional-quality > solution is the IAR compiler. It's expensive, but you get what you pay > for. Microchip's compiler lags it significantly on code density and > quality, and (IMHO) CCS takes too many liberties with the standard to > actually be called C. It's a C subset with some semantic differences and > some PIC-specific enhancements. This might not matter to you if you're > just using it instead of assembler to save the hassle of low-level > programming, but if you have any interest in migrating C code to/from > the PIC, IAR is the one and only choice. > > peteThe portability is overplayed with small microcontrollers. The PIC is not made for C language. CCS does a very good job at optimizing the code and that it very important when code memory usage is high. I don't think that the fact that IAR is more ANSI compliant is a good justification for the high price. I don't see the logic is making it easier to swith a design from a PIC to a mainframe. -- John Kerry for president http://www.johnkerry.com/ http://www.netonecom.net/~bbcat
Reply by ●July 11, 20042004-07-11
In comp.arch.embedded Michel Catudal <bbcat@netonecom.net> wrote:> > The portability is overplayed with small microcontrollers.It's not. We have customers in automotive who demand portability, they want the same platform running on platforms from PIC right up to PowerPC. For people who are building one or two products, yes, portability is not important. For big customers, it is.> The PIC > is not made for C language.The PIC18 was intended to be C-friendly. Microchip knew they'd screwed up with the PIC17.> CCS does a very good job at optimizing > the code and that it very important when code memory usage is high. > > I don't think that the fact that IAR is more ANSI compliant is a > good justification for the high price.I do, and so do large customers. pete -- pete@fenelon.com "there's no room for enigmas in built-up areas"
Reply by ●July 11, 20042004-07-11
This is the very reason that we link the intermediate code from the compiler and don't begin to do code generation until we know the entire structure of the application. The other similar issue is pointers to functions. Walter Banks www.bytecraft.com Eric Smith wrote:> "Sergio Masci" <sergio@NO.SPAM.xcprod.com> writes: > > You don't need a new storage class to do this. The compiler just needs to be > > intelligent enough to analyse the code, determin that a function is not > > reenterent and allocate locals accordingly. > > The compiler doesn't really have enough information to deternine that. > Suppose you have a source file like this: > > extern void func1 (int c); > > static void func2 (int b) > { > int foo = b % 6; > // do some stuff with foo > func1 (foo - 7); > // do some other stuff with foo > } > > void func3 (int a) > { > func2 (a + 3); > } > > Even though func2() is declared static, and even though there is only a > single place that calls func2(), the compiler cannot determine whether it > can be called recursively because it has no way to know whether the > external func1() might call func3(). The best the compiler can do in > this case is decide that func2 *might* be called recursively, and thus > take the proper actions to guarantee that local variable foo meets the > defined semantics for the automatic storage class. Typically this would > involve storing foo in a stack frame, or pushing it prior to the call > to func1() and restoring it afterward, though other mechanisms not > involving a stack could also be used. >
Reply by ●July 11, 20042004-07-11
On 8 Jul 2004 22:32:36 -0700, tronnort@yahoo.com (David L. Jones) wrote:>"Talal Itani" <titani@airmail.net> wrote in message news:<cckb50$cl9@library2.airnews.net>... >> Hello, >> >> I currently have an ICD2 from Microchip. I use it to develop PIC16 code >> using the MPLAB debugger and assembler. I need to move to the PIC18 parts >> and C language, but I am struggling figure out the development tools to get. >> Do you have any experience with the CCS compiler running with MPLAB and >> ICD2? ($175 solution) >> >> Thanks, >> Talal > >I don't have experience with the 18 series compilers, but for the 16 >series the HiTech ones beats the pants off the CCS compiler, much more >professional. At the time I needed to do floats in printf() and the >CCS compiler wouldn't do it. >The HiTech compiler also sensibly uses the acutal register names as >used in the datasheet, so you can simply go PORTA=123 etc. I would >avoid any compiler which doesn't allow this as standard. > >The 18 series HiTech compiler uses their new HiTide windows interface. >Gotta be better than the DOS version on the 16 series compiler. >Although I now integrate the PIC-C compiler with the MPLAB program, >it's painless. > >If you can afford it, go for the HiTech compiler. Although the CCS one >will probably do you just fine if you are on a budget. > >Dave :)I've used both HiTech and CCS compilers and prefer the CCS. The main reason is that at the time HiTech operated in a DOS window and you could only see something like 14 lines of code at a time and long comments would extend past the limits of the DOS window. I am using CCS now with both 16 and 18 series PIC microcontrollers with no problems. The issue of CCS not using the actual register names is a disappointment but is remedied by creating a header file that assigns those names. This is how HiTech does it--you just have to provide the file yourself if you use CCS and want to use the register names verbatim. I used the HiTech header file as a guide to create one for CCS. TP
Reply by ●July 12, 20042004-07-12
>Yes, I explained that in my post if you'll read it carefully. However, >in most non-trivial C programs there is some use of function pointers.In a 1k-code microcontroller application you will be happy to sacrifice the use of function pointers anb recursion for the benefit of (much) compacter code. Wouter van Ooijen -- ------------------------------------ http://www.voti.nl PICmicro chips, programmers, consulting
