From: Scott D. <sc...@da...> - 2001-01-10 07:19:20
|
Another decent sized commit has just been placed into CVS. Outside of the PIC port, nothing else should have been affected. The major thing in this one is that I'm diving into pic/ralloc.c and trying to figure out how to adapt all of the iCode to the PIC architecture. The biggest thing I'm wrestling at the moment is pointers. The PIC is totally different than the 8051 in this regard... ----- Has anyone thought of writing a post-compiled optimizer? I'm discovering more and more that my peep hole optimizations will remove the need for chunks of code. Here's a simple example: void inc(unsigned char k) { uchar0 = uchar0 + k; } generates: ; b.c 19 ; ----------------------------------------- ; function inc ; ----------------------------------------- _inc: ; b.c 21 ; peep 9 - Removed redundant move movwf r0x0C addwf _uchar0,f _00161_DS_: ; C$b.c$22$1$1 ==. ; XG$inc$0$0 ==. return Peep 9 looks like: replace restart { movwf %1 movf %1,w } by { ; peep 9 - Removed redundant move movwf %1 } So before the peep: movwf r0x0C movf r0x0C,w addwf _uchar0,f return After: movwf r0x0C addwf _uchar0,f return And what would be desirable: addwf _uchar0,f return Of course, you can't just get rid of the "movwf r0x0C" - at least not easily. I wrote a routine that would check to see if the input parameter (passed in W) could be used as is in the function. Unfortunately, there are boundary conditions that complicated the code quite rapidly. So I gave up on it. Besides that would only save one instruction... Now a post-compiler optimizer could parse the generated assembly and apply rules that are based on the assembly instructions that have been generated. Now this could be done in one of two ways. For example, you could brute force parse the ascii strings generated by the emitcode()'s and extract the mnemonics, decode them, and figure out the state of the program. Yuck. A better approach IMO would be to modify the emitcode() function so that instead of emit'ing ASCII strings, emit objects (I'm sorry, I meant structures) that are analogous to iCode linked list. Then the post-compiler optimizer could easily (ha) step through and apply rules much like ralloc.c does now to the iCode. One benefit is that the post-compiler optimizer could be constructed in such a way that if you wanted, you could apply it to hand written assembly. The hand written assembly would have to conform to a few rules (to clarify assumptions). Anyway... there's no way I'll have time to work on this anytime soon. Scott |
From: Scott D. <sc...@da...> - 2002-05-17 04:59:56
|
Linas Vepstas submitted a ton of bug reports for the PIC port. All but two have been fixed. There have been numerous changes to the PIC port, but they shouldn't have affected the reset of CVS. A special thanks goes out to Linas... Scott |