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.
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.
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.
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
formatting link
Analog
formatting link
formatting link
Atmel Sam7
formatting link
ST
formatting link
eg
formatting link
philips lpc2106 128KB flash 64KB ram 60MHz , 2x usart, spi, I2C, 6x pwm , also available in -40 to +85
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. 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.
The 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
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.
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.
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.
We are talking about the PIC18 though, which comes with up to
128K bytes of code memory/4K of RAM.
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
This is nonsense. You cannot conjure the address of a function out of thing air. All functions that are invoked by a pointer to function are easily identified. All function pointers are easily identified. The assignment of a function address to a function pointer is easily identified. All function pointers can be easily tracked at compile time. The only way the compiler would loose track is if the execution path passed through some assembler code or C code for which the source is not available AND the function pointer is passed into that code by reference.
There is no way a function address can be computed using a mathematical expression, you have to look them up. Yes I know you can load an object file into a running program, locate functions by name and then execute them via a function pointer BUT this is the same situation I mentioned above where the compiler does not have access to the source and in any case you wouldn't be doing this on a small embedded system.
Conclusion: the number of situations where a function cannot be proven to be either reenterant or non-reenterent is increadibly small and would involve increadibly complex function pointer manipulation. Such functions could be treated as reenterant (or flagged by the compiler as being too complex) while all the other functions in the system would be well defined and treated accordingly.
This is complete BS. On the one hand you talk about how things are not done and on the other how things could be done. You use the argument that existing compilers don't do blah blah to support your argument for not being able to gather the information required and you use the argument for adding new facilities to show how it can only be done your way. This is gibberish. If you're going to modify a compiler you can make it do what you want. If you're not going to modify it then what does this "hints" thing mean. Do you intend shouting at the compiler to get it to do what you want?
Ok, lets say for the sake of argument that you implement this "hints" thing. Are you going to make the compiler varify that the hint is valid or are you going to blindly generate code that will crash because the hint is not valid.?Are you going to analyse the generated code in some way to identify how "hinted" variable RAM will be re-used or are you going to treat them like static varaible are not bother with a static stack?
Wouter, Walter and I have all told you that you don't need this "hints" thing, that all the info is there. Go back and think about how you would solve the problems you think you have and then tell us why you think it is impractical (forget impossible).
Yes but you still would not want to loose the advantage of the extra code space by filling it with inefficient code, or the advantage of a faster processor by giving it unnecessary code to execute.
I find it VERY unlikely that any of your customers demand that the code be portable between PICs and Power PCs.
Why? I have found after doing this for over 20 years that in "big" projects COST is the big factor. Not once did anyone ask me to make sure that the code that runs on one of our gaming voucher printers be portable to a Wintel bos, but they sure ask about the price. When you say "big" I take it you mean big numbers of shipped units.
Many of us have sucessfully completed 17 series parts using 'C'. Just as many of us learned to deal with the limitations of the Intel segmented architecture of the X86 we have learned to deal with the oddities of small MCUs.
Ideally, I would like to have the choice, not to have a non-standard limitation imposed that breaks existing C code.
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
No. All functions that *might* be invoked by a pointer are identifiable. But they are not necessarily identifiable through static analysis of only the file defining those functions (unless the functions are declared static).
No. I've got real-world examples in two IP router code bases I've worked on at past jobs.
The whole point of my suggestion was that the programmer may KNOW that a particular function with never be called reentrantly, and could give a hint to the compiler rather than relying on the compiler to possibly figure it out.
Of course, if the programmer supplies a hint that is wrong, all bets are off.
I *never* said it can only be done my way. I provided a reasonable argument for why it might be desirable to do it the way I suggest, though I stated outright that I thought it unlikely that my proposal would be adopted (only because it doesn't benefit mainstream C users).
You can rant all day about how my idea is "complete BS", but such ranting is not likely to convince anyone.
Another very insightful and constructive bit of criticism.
Truly you have a dizzying intellect. -- The Man in Black, "The Princess Bride", screenplay by William Goldman
Blindly generate code that may produce undesired results. If the programmer tells the compiler that it's allowed to do something, then the compiler is allowed to do it.
On two occasions I have been asked [by members of Parliament!], "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." -- Charles Babbage
Of course, if the compiler can prove that the programmer is wrong, it can ignore the hint and/or produce a compile time warning or error. In fact, the compiler can ignore the hint for any reason or none at all. But if the programmer supplies the hint and the compiler chooses to act on it, the programmer is responsible for the consequences.
The compiler is allowed to use the hint to do any sort of optimization that is guaranteed to still yield the defined C automatic storage class semantics under the restriction that the function is not called reentrantly. The compiler could treat the variable as static, or it could treat it as automatic, or it could do something else we haven't thought of. The C standard doesn't define a specific mechanism by which an implmentation is required to implement the automatic storage class, and similarly there is no reason why it would dictate an implementation mechanism for the proposed hint.
You have told me it is unnecessary but you have provided no evidence or concrete argument to counter the code example I provided. The most coherent criticism of my proposal that you've managed to produce is the claim that it is "complete BS".
I stated myself that it is impractical because the C committee has no motivation to add a feature that only benefits programmers of very small embedded systems.
Other than that, speaking as someone who has actually written small compilers (for special-purpose languages) I am fairly certain that there is no particular reason why the proposal it is impractical from a technical perspective.
I have many years experience with AVR and WinAVR (GCC) Recently I have started a new job where only the PIC18 and PIC16 familie are allowed. I started with Microchip's C18 compiler and got frustrate with it when I could only have 256 bytes of global variables. Th compiler would give a message saying something along the lines that I hav run out of RAM. I guess the PICs have the RAM in banks of 256 bytes, s you need to manually assign the global variables into different banks. couldn't figure out how to do this, so I bought the CCS compiler hopin for a better experience. CCS solved the banking issue, but the C18 appears to be more "ANSI compliant". for example: GCC and the C18 will compile this code, but not the CCS union hello { struct { unsigned char a; unsigned char b; }; unsigned char ppp[2]; };
union hello test;
void main(void) { test.a = 5; test.ppp[0] = 50;
/* ------ MAIN CONTROL LOOP ------ */ for (;;) {
} } The CCS compiler is saying that " test.a = 5;" is not a valid member :( And I have to use this work around for printing strings in ROM on the CCS void print_string(char rom *pBuf) { unsigned int16 temp, *data_prog; unsigned char a[1]; temp = &pBuf; data_prog = temp; temp = *data_prog; a[0] = "a"; while (a[0]!=0) { read_program_memory(temp, a, 1); txbyte(a[0]); temp++; } } Instead of this: void print_string(char rom *pBuf) { unsigned char a[1]; a[0] = "a"; while (a[0]!=0) { read_program_memory(pBuf, a, 1); txbyte(a[0]); pBuf ++; } } Conclusion, If you have to use PICs and are on a budget, buy HiTe compiler, otherwise use IAR, otherwise use GCC with a real processor lik and AVR, MSP, or ARM7
Wouldn't it have been easier to find out how to do it rather than changing compilers? One bank of static storage duration per module is a common limitation on PIC18 compilers.
That is not "ANSI C compliant" code. That is an extension known as an "anonymous structure."
I don't think anyone would consider Hi-Tech to be a "budget" solution.
My experience evaluating IAR for PIC18 vs. Hi-Tech showed that IAR's much higher price gets you much larger code, which wasn't exactly what I was looking for.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.