How would you account for the movement of code near the end of the program
as a result of the insertion or deletion of page directives earlier in the
code? E.g. You process a forward goto that you see does not require a page
setting because it is in the same page but later you have to add page
setting code for another goto between the first one and the first ones
target. Now the first gotos target is pushed out of range and requires
paging code. Going back to insert it might even cause the second goto to
pushed in range of its target and removal of its page setting code may bring
the first goto target back in range.

---
James Newton (PICList Admin #3)
mailto:jamesnewton@piclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

-----Original Message-----
From: pic microcontroller discussion list
[mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Roman Black
Sent: Wednesday, May 02, 2001 08:01
To: PICLIST@MITVMA.MIT.EDU
Subject: Re: [PIC]: Super Assembler (parser)


Scott Dattalo wrote:

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


Yes, I thought of simplifying the entire branching
system in the .asm, by having custom "branch"
commands that the parser recognises and replaces with
asm code. For example, instead of doing:

        pagesel blah    ;
        goto blah       ; (long gotos or calls are a pain)

or even:

        sublw d'99'     ; sub to compare
        skpz            ; skp match
        goto not_match  ;
        goto match      ;   (very messy page select issues here!)

you could just do a:

        sublw d'99'             ;
        X_brz match             ; (special label)
        X_brnz not_match        ;

And all page select issues would be handled
for you. What about this?

        sublw d'99'                     ;
        X_callz match_function          ;
        X_callnz not_match_function     ; (nice twist!)

It's got me thinking, i've written a lot of C code
parsing and text utilities in years gone by, and it
would not be that hard to determine which page code
is on and generate the proper "branch" assembler to
do it. :o)
-Roman

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

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