Hey! That sounds like it might work... especially the "or it reaches a limiting number of passes" part. Seems like MASM did something like that as well... related to macro expansion... Could also track the size of each attempt and then take the smallest, not necessarily the last, version. --- 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 Bob Ammerman Sent: Wednesday, May 02, 2001 10:06 To: PICLIST@MITVMA.MIT.EDU Subject: Re: [PIC]: Super Assembler (parser) Importance: Low Borland does this using an N pass algorithm to optimize jumps in their x86 assembler. It just keeps redoing the assembly until nothing changes, or it reaches a limiting number of passes defined on the command line. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) ----- Original Message ----- From: "Douglas Wood" To: Sent: Wednesday, May 02, 2001 12:53 PM Subject: Re: [PIC]: Super Assembler (parser) > It would have to be at least a three pass assembler. > > Douglas Wood > Software Engineer > dbwood@kc.rr.com > > Home of the EPICIS Development System for the PIC and SX > http://epicis.piclist.com > > ----- Original Message ----- > From: "James Newton" > To: > Sent: Wednesday, May 02, 2001 11:42 AM > Subject: Re: [PIC]: Super Assembler (parser) > > > > 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 > > > > > > -- > 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 -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads