Searching \ for '[PIC][AD] PIC18 C compiler comparison' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/languages.htm?key=c
Search entire site for: '[AD] PIC18 C compiler comparison'.

Exact match. Not showing close matches.
PICList Thread
'[PIC][AD] PIC18 C compiler comparison'
2007\10\18@095039 by Walter Banks

picon face

I re-read this it sounds like and ad its not. :)

w..

Xiaofan Chen wrote:

{Quote hidden}

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
.....walterKILLspamspam@spam@bytecraft.com










2007\10\18@101618 by Xiaofan Chen

face picon face
On 10/18/07, Walter Banks <walterspamKILLspambytecraft.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}

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

2007\10\18@121037 by Walter Banks

picon face


Xiaofan Chen wrote:

{Quote hidden}

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}

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}

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..


2007\10\18@124107 by Harold Hallikainen

face
flavicon
face

{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. 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!

2007\10\18@125545 by Timothy J. Weber

face picon face
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

2007\10\18@133052 by Walter Banks

picon face
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}

> -

2007\10\18@140037 by Walter Banks

picon face


Harold Hallikainen wrote:

{Quote hidden}

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..


2007\10\18@145244 by Harold Hallikainen

face
flavicon
face

{Quote hidden}

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!

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...