Writing compilers is a large exercise in attention to detail. It is also
deceptive,
a working compiler can be achieved with very little effort perhaps as little as
three
or four man days. A good effective embedded systems compiler will take
man years.

Our recent compilers have been consistently winning benchmarks against well
written hand coded assembler. Compilers in embedded sytstems have three
advantages over hand coded assembly implimentation:
  1) Allocation of resources. Computers are good at managing a processors
      resources according to some well defined allocation scheme.
  2) Compilers can use instruction set sequences that if used in assembly
language
      would be very difficult to maintain.
  3) Compilers get to create code anew every time they are used and they
      don't have to incorporate changes into previously implimented code.
      The compare sequence that Scott posted yesterday is an good example of
this.
      If the 7 or 31 constant in the compares changed then the whole code
      sequence would need to be changed. In a compiler generated code his
      code is perfectly reasonable and would change without implimentor
inervention
      if the constants changed.


> Any time I have tried to write a compiler (and from what I've seen in
> commercial products), the need to save and restore context resources (FSR,
> STATUS, PCLATH, etc.) in the language adds a significant amount of overhead
> to the compiler.

Context saving in a compiler is just as important as in assembly code and
needs the same care. There is no need for the compiler implimentation to
generate
more overhead than the assembly equivalent.

>
> Not only that, there can be significant issues with accessing declared
> language variables from assembler - especially if the variables are locally
> declared ....  "Housekeeping" variables needed by the language
> for execution may have to be place "outside" of where the user is likely to
> access them, which means the execution of the language statements is less
> efficient to allow for easier assembler coding.
>
>  I'd love to see how the authors
> prevented assembler statements from being a significant problem.
>

Variable access including locals is essentially a scoping problem. In MPC
assembly code accesses C variables by name and the access is controlled by
haveing the same scoping rules as C.

Walter Banks

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu