On Wed, 2 May 2001, Kari Lehikko wrote:

> > Any thoughts on this?? :o)
> > -Roman
>
> Sounds like a C-compiler to me :P

Sure does!

http://www.dattalo.com/gnupic/sdcc.html

What Roman describes is being implemented in SDCC's PIC Port. Specifically,
there's a post code compile stage called "pCode" that takes SDCC's PIC generated
code and optimizes it. Currently it performs two type optimizations. One is a
conditional "peep hole" optimizer, the other is a register allocation optimizer.
Banking is not currently handled and the optimization is confined to just single
files.

The good news is that this code is written in such a way as to not require a C
compiler. For example, it'd be possible to convert say a .hex file into the
pCode format, perform the optimizations, and write the results back into a new
.hex file. However, to be honest I think that would be a very difficult thing to
do. All of the boundary conditions could prove insurmountable. Also, simple
things like delay loops or isochronous code would be "optimized" away.

A better approach is to integrate the optimization into the assembler (as Roman
suggests). Directives could be created to control the manner in which a program
may be simplified. For example, the BANK macro could be turned into a directive
that generates the optimum banking instructions based on where the code is
located. Or another nice feature would be to provide automatic variable scoping
and allocation.

To get the most functionality, one would need to exceed the bounds of the
assembler and encroach upon the linker. Well, the good news is that the gnupic
project (Craig Franklin) is working on a linker.

These are interesting issues that are being actively persued.

Scott

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads