Post by thread:[PIC][AD] PIC18 C compiler comparison

I re-read this it sounds like and ad its not. :) w.. Xiaofan Chen wrote: {Quote hidden}> On 10/17/07, Walter Banks <spam_OUTwalterTakeThisOuTbytecraft.com> wrote: > > > > How do they handle different bugs between different chip revisions...? > > > Do you tell it what chip revision you use? > > > > Essentially that is what is done in the better compilers. > > > > "It is the compilers job to make code that will run on the silicon" > > The compiler will help but it is the user's job to make the > code working. ;-) > > By the way, why no MPC for PIC18? Is the market too small > for another compiler? Or did C18 spoil the market? A timely question.. We have PIC18 code generator that will be released shortly after the next MPC release. (Which is running test suites as I type this) Much of the development here for the last couple years is evaluating and adding features that would make development on embedded processors more effective. I have spent quite a bit of time talking to application developers, consumer product manufactures, chip companies and standards organization.. Several things have come out of this work that should make our customers lives easier. 1) I have spent quite a bit of time advocating standards for the unique properties of embedded systems (ISO and Misra). Standards are important for portability, and understandable algorithm development. IEC/ISO 18037 does three things for embedded systems - Adds named address space to the C language recognizing that most embedded systems have multiple memory address spaces. It adds user defined address space to the compiler symbol table handling can be used to manage user variables in I2C devices or allocate space in unused RAM in LCD controllers for variables. - Adds fixed point data types fract and accum to C which combined with named address space makes it possible to describe DSP algorithms directly in C in a portable way without resorting to asm. The potential of fract and accums as an alternative to float is realized when implemented with compiler support. This and a fixed point transcendental library is now part of all our new releases. - Bring C back to its roots to have the ability to do low level implementations. The goals on this one is all asm should be able to be eliminated without penalty. This means processor register access including condition codes should be accessed directly in C. As a proof write a test program describing every instruction in C that assure the each compiles to a single instruction. (Proof incidentally that C can generate code as tight as any assembler program) There is a white paper on Byte Craft's web site on this. http://www.bytecraft.com/C_versus_Assembly 2) We have been working on multiprocessor technologies that start with a single C program that execute on 2 or more processors. This is now being used in automotive engine controllers and is in the next MPC release. This does some interesting things for multiple PIC 18's 3) We created execution threads. Execution threads implemented with pragma's are similar to the ON operator in some basics. In our case execution threads can be triggered by interrupts conditioned with a logical expression. Timer and softcount = n for example. Threads run to completion always. Threads statistically use less RAM and stack than conventional implementations. Threads may be software logical expressions only, or a mix of interrupts and expressions. Very effective on small processors like the 12bit Microchip PIC core. Language supported execution threads eliminates the need for RTOS's in many applications. 4) Microchip PIC's and other processors that have managed memory spaces tend to get less execution efficiency as the ROM space fills up. (Probability of needing memory management on any specific branch is higher) We have always had alternative code generation strategies these now include the implementation of many branchless sequences to reduce this overhead. One last rant on optimization. I got a call from a distributor a couple days ago with a very interesting story. One of his customers just by recompiling with a more effective compiler (ours) added a half hour battery life to a hand held product (8%). The savings doesn't end there, clock speeds may now be reduced for more battery life, EMI is down. Regards -- Walter Banks Byte Craft Limited Tel. (519) 888-6911 Fax (519) 746 6751 http://www.bytecraft.com .....walterKILLspam@spam@bytecraft.com

On 10/18/07, Walter Banks <walterKILLspambytecraft.com> wrote: > 2) We have been working on multiprocessor technologies that > start with a single C program that execute on 2 or more > processors. This is now being used in automotive engine > controllers and is in the next MPC release. This does some > interesting things for multiple PIC 18's Interesting! How do you manage the communication between two PIC18s? But the communication is pretty application specific (say SPI/I2C/UART/CAN/etc). {Quote hidden}> > 3) We created execution threads. Execution threads implemented > with pragma's are similar to the ON operator in some basics. In > our case execution threads can be triggered by interrupts > conditioned with a logical expression. Timer and softcount = n > for example. Threads run to completion always. Threads > statistically use less RAM and stack than conventional > implementations. Threads may be software logical expressions > only, or a mix of interrupts and expressions. Very effective on > small processors like the 12bit Microchip PIC core. Language > supported execution threads eliminates the need for RTOS's in > many applications. Interesting even though I have some problems understanding really a thread means. Is it a subroutine? But you mentioned that threads run to completion always, so you disable the interrupt, right? > 4) Microchip PIC's and other processors that have managed > memory spaces tend to get less execution efficiency as the > ROM space fills up. (Probability of needing memory management > on any specific branch is higher) We have always had alternative > code generation strategies these now include the implementation > of many branchless sequences to reduce this overhead. > Sorry I do not quite get you here. Could you explain a bit more on what do you mean by managed memory spaces and its impact on execution efficiency when the ROM spaces fill up? Thanks. Xiaofan

Xiaofan Chen wrote: {Quote hidden}> On 10/18/07, Walter Banks <.....walterKILLspam.....bytecraft.com> wrote: > > > 2) We have been working on multiprocessor technologies that > > start with a single C program that execute on 2 or more > > processors. This is now being used in automotive engine > > controllers and is in the next MPC release. This does some > > interesting things for multiple PIC 18's > > Interesting! How do you manage the communication between > two PIC18s? But the communication is pretty application > specific (say SPI/I2C/UART/CAN/etc). Communication is application dependent. Properly organized the communication bandwidth can be quite low. Microwave oven with three processors, display, keypad and oven. Three processors communication over i2c. Think bunch of sensors each with a micro to control them sending qualified information to a central PID controller. The automotive engine controller has a power PC and two eTPU processors in it communicating through dual port memory. Processors export their interface information to each other. {Quote hidden}> > > > > > 3) We created execution threads. Execution threads implemented > > with pragma's are similar to the ON operator in some basics. In > > our case execution threads can be triggered by interrupts > > conditioned with a logical expression. Timer and softcount = n > > for example. Threads run to completion always. Threads > > statistically use less RAM and stack than conventional > > implementations. Threads may be software logical expressions > > only, or a mix of interrupts and expressions. Very effective on > > small processors like the 12bit Microchip PIC core. Language > > supported execution threads eliminates the need for RTOS's in > > many applications. > > Interesting even though I have some problems understanding > really a thread means. Is it a subroutine? But you mentioned that > threads run to completion always, so you disable the interrupt, > right? A thread is a piece of straight line code which could be a subroutine call that is called from a small compiler generated executive that evaluates logical expressions and dispatches the thread when the execution conditions are met. Run to completion un-interrupted as an assumption makes thread code simple to write and easy to debug. A lot of information on assumptions is coded into the execution criterion. Threads doesn't have to be a subroutine. Nice for execution stacks with 2 or 4 levels of subroutines. {Quote hidden}> > 4) Microchip PIC's and other processors that have managed > > memory spaces tend to get less execution efficiency as the > > ROM space fills up. (Probability of needing memory management > > on any specific branch is higher) We have always had alternative > > code generation strategies these now include the implementation > > of many branchless sequences to reduce this overhead. > > > > Sorry I do not quite get you here. Could you explain a bit more > on what do you mean by managed memory spaces and its > impact on execution efficiency when the ROM spaces fill up? > The probability of an off page reference rises as the ROM fills up with code. Code that is less than page size doesn't need any ROM memory management, as the application gets bigger subroutines can be "checker boarded" into pages. As either subroutines or applications continue to grow the number of off page references rapidly increases. Most of the PIC page management schemes are designed to keep branch references on page where possible. We have started to aggressively reduce branches to reduce this overhead and reduce execution cycles with both lower overhead code and replacing branches with conventional 1 cycle per instruction code. w..

{Quote hidden}>> > 3) We created execution threads. Execution threads implemented >> > with pragma's are similar to the ON operator in some basics. In >> > our case execution threads can be triggered by interrupts >> > conditioned with a logical expression. Timer and softcount = n >> > for example. Threads run to completion always. Threads >> > statistically use less RAM and stack than conventional >> > implementations. Threads may be software logical expressions >> > only, or a mix of interrupts and expressions. Very effective on >> > small processors like the 12bit Microchip PIC core. Language >> > supported execution threads eliminates the need for RTOS's in >> > many applications. >> >> Interesting even though I have some problems understanding >> really a thread means. Is it a subroutine? But you mentioned that >> threads run to completion always, so you disable the interrupt, >> right? > > A thread is a piece of straight line code which could be a > subroutine call that is called from a small compiler generated > executive that evaluates logical expressions and dispatches > the thread when the execution conditions are met. Run to > completion un-interrupted as an assumption makes thread > code simple to write and easy to debug. A lot of information > on assumptions is coded into the execution criterion. Threads > doesn't have to be a subroutine. Nice for execution stacks > with 2 or 4 levels of subroutines. > I often end up writing menu systems using state machines where, depending on a user action, a state is set. We then return to mainline code. The next time the menu system is called, it checks for a key. If one was pressed, it evaluates it based on the current state. This gets rather messy because I have to define all these different states. I like being able to have a wait loop in my code where it's just waiting for the next user input, but, while waiting, it goes off and does other stuff. I've written stuff where there's a NextTask() function that saves away the current stack, reloads the stack with the contents for the next task, then runs it until a NextTask() is hit. All functions run until they hit the NextTask(), which is generally until we get to a point where we are waiting for user input. I did this years ago on an 80286 with a separate stack for each task. I then just saved the stack pointer for each task, then restored it. I've also done it on the PIC18, but have only tested it, not used it in a real application. For the PIC18, I copy the stack to a RAM array, then copy it back when I resume the task. The code and test code is at http://www.piclist.org/techref/microchip/language/c/MultiTask.c.htm . Harold -- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising opportunities available!

Harold Hallikainen wrote: > I often end up writing menu systems using state machines where, depending > on a user action, a state is set. We then return to mainline code. The > next time the menu system is called, it checks for a key. If one was > pressed, it evaluates it based on the current state. This gets rather > messy because I have to define all these different states. I like being > able to have a wait loop in my code where it's just waiting for the next > user input, but, while waiting, it goes off and does other stuff. I've > written stuff where there's a NextTask() function that saves away the > current stack, reloads the stack with the contents for the next task, then > runs it until a NextTask() is hit. All functions run until they hit the > NextTask(), which is generally until we get to a point where we are > waiting for user input. I did this years ago on an 80286 with a separate > stack for each task. I then just saved the stack pointer for each task, > then restored it. I've also done it on the PIC18, but have only tested it, > not used it in a real application. For the PIC18, I copy the stack to a > RAM array, then copy it back when I resume the task. The code and test > code is at > http://www.piclist.org/techref/microchip/language/c/MultiTask.c.htm . This is a very useful technique, normally called "co-routines." The main difference between threads and coroutines is that coroutines swap contexts at a predefined point, while threads either run in true parallel (e.g., on a multi-processor machine) or are swapped at essentially random times (e.g., every N instructions). -- Timothy J. Weber http://timothyweber.org

The threads we implemented have been done so with the compilers direct knowledge. There are class of applications that they are very useful and also make better use of resources on very small processors. w.. Harold Hallikainen wrote: {Quote hidden}> >> > 3) We created execution threads. Execution threads implemented > >> > with pragma's are similar to the ON operator in some basics. In > >> > our case execution threads can be triggered by interrupts > >> > conditioned with a logical expression. Timer and softcount = n > >> > for example. Threads run to completion always. Threads > >> > statistically use less RAM and stack than conventional > >> > implementations. Threads may be software logical expressions > >> > only, or a mix of interrupts and expressions. Very effective on > >> > small processors like the 12bit Microchip PIC core. Language > >> > supported execution threads eliminates the need for RTOS's in > >> > many applications. > >> > >> Interesting even though I have some problems understanding > >> really a thread means. Is it a subroutine? But you mentioned that > >> threads run to completion always, so you disable the interrupt, > >> right? > > > > A thread is a piece of straight line code which could be a > > subroutine call that is called from a small compiler generated > > executive that evaluates logical expressions and dispatches > > the thread when the execution conditions are met. Run to > > completion un-interrupted as an assumption makes thread > > code simple to write and easy to debug. A lot of information > > on assumptions is coded into the execution criterion. Threads > > doesn't have to be a subroutine. Nice for execution stacks > > with 2 or 4 levels of subroutines. > > > > I often end up writing menu systems using state machines where, depending > on a user action, a state is set. We then return to mainline code. The > next time the menu system is called, it checks for a key. If one was > pressed, it evaluates it based on the current state. This gets rather > messy because I have to define all these different states. I like being > able to have a wait loop in my code where it's just waiting for the next > user input, but, while waiting, it goes off and does other stuff. I've > written stuff where there's a NextTask() function that saves away the > current stack, reloads the stack with the contents for the next task, then > runs it until a NextTask() is hit. All functions run until they hit the > NextTask(), which is generally until we get to a point where we are > waiting for user input. I did this years ago on an 80286 with a separate > stack for each task. I then just saved the stack pointer for each task, > then restored it. I've also done it on the PIC18, but have only tested it, > not used it in a real application. For the PIC18, I copy the stack to a > RAM array, then copy it back when I resume the task. The code and test > code is at > http://www.piclist.org/techref/microchip/language/c/MultiTask.c.htm . > > Harold > > -- > FCC Rules Updated Daily at http://www.hallikainen.com - Advertising > opportunities available! > -

Harold Hallikainen wrote: {Quote hidden}> I often end up writing menu systems using state machines where, depending > on a user action, a state is set. We then return to mainline code. The > next time the menu system is called, it checks for a key. If one was > pressed, it evaluates it based on the current state. This gets rather > messy because I have to define all these different states. I like being > able to have a wait loop in my code where it's just waiting for the next > user input, but, while waiting, it goes off and does other stuff. I've > written stuff where there's a NextTask() function that saves away the > current stack, reloads the stack with the contents for the next task, then > runs it until a NextTask() is hit. All functions run until they hit the > NextTask(), which is generally until we get to a point where we are > waiting for user input. To accomplish the same thing with threads replace the NextTask() with a boolean flag or status word and create a thread out of the following code conditioned on flags and wait for key. For processors that don't have stack access this may be one of the few solution. Harold, I am not arguing against what you did or its implementation just presenting a very small processor low overhead alternative. It is possible that a NextTask() macro could be written to create threads directly out of co_routines. BTW Nice piece of code w..

{Quote hidden}> > > Harold Hallikainen wrote: > >> I often end up writing menu systems using state machines where, >> depending >> on a user action, a state is set. We then return to mainline code. The >> next time the menu system is called, it checks for a key. If one was >> pressed, it evaluates it based on the current state. This gets rather >> messy because I have to define all these different states. I like being >> able to have a wait loop in my code where it's just waiting for the next >> user input, but, while waiting, it goes off and does other stuff. I've >> written stuff where there's a NextTask() function that saves away the >> current stack, reloads the stack with the contents for the next task, >> then >> runs it until a NextTask() is hit. All functions run until they hit the >> NextTask(), which is generally until we get to a point where we are >> waiting for user input. > > To accomplish the same thing with threads replace the NextTask() > with a boolean flag or status word and create a thread out of the > following > code conditioned on flags and wait for key. For processors that > don't have stack access this may be one of the few solution. > I think that pretty much gets back to the state machine approach. I've done that in C and assembly, and it can get pretty messy. I did this long ago in MC6800 assembly where at the top of a subroutine I'd load the program counter with my "continue address". Prior to exiting a routine, I'd set the continue address to the address after the return. Now that I think about it a bit more, I wonder if this could be done with a macro. We'd have an array of "ContinueAddresses," one for each task, thread, co-process, or whatever we call it. Our NextTask macro would save the address after the return, then return. On calling our routine again, this ContinueAddress would be loaded in the program counter and the routine would continue from there. I could see doing this in assembly, but it seems like it'd make a mess out of C. > Harold, I am not arguing against what you did or its implementation > just presenting a very small processor low overhead alternative. > I don't oppose differing views! I've been wrong before, and will be again. > It is possible that a NextTask() macro could be written to create threads > directly out of co_routines. > > BTW Nice piece of code > Thanks! Some day I'll test it in a real application. Harold -- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising opportunities available!