Post by thread:[PIC]: Call calc

Hi all, After writing about 7K of assembler for the PicPocket, I started to wonder about the best placement of subroutines to avoid changing the PCLATH. Looking back through the code, I realised it would be no easy task to sort them out. I had some free time over the weekend and wrote this little Windoze utillity that scans through the code and lists all the subroutines and what pages they are called from. It helped me to place the subroutines in the most appropriate ROM page to minimize changing the PCLATH. Here is a short output listing... Label Address Page Times called from each ROM page Optimal ------------------------------------------------------------------ Page 0 Page 1 Page 2 Page 3 ------------------------------------------------------------------ AnyKey 031E 0 6 13 8 8 N AreFiles 01C4 0 5 1 0 1 Y BCstartR 0DDF 1 2 6 4 10 N I have no idea if this is of any use to anyone else or not, but here it is :-) http://www.picnpoke.com/demo/CallCalc.zip -- Best regards Tony mICro's http://www.picnpoke.com spam_OUTsalesTakeThisOuTpicnpoke.com -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestKILLspam@spam@mitvma.mit.edu

Tony: Sounds real useful. I will give it a try at my next opportunity. A related calculator that I have desired for some time is one that shows the depth of subroutine calls. The 8 level stack is a real pain for anything larger than a few hundred instructions. Right now I use a combination of editor macros and a lot of manual counting. Arrrgh. This is just something to think about. No requests or offers involved. ;-) -- Rich Tony Nixon wrote: {Quote hidden}> > Hi all, > > After writing about 7K of assembler for the PicPocket, I started to > wonder about the best placement of subroutines to avoid changing the > PCLATH. Looking back through the code, I realised it would be no easy > task to sort them out. > > I had some free time over the weekend and wrote this little Windoze > utillity that scans through the code and lists all the subroutines and > what pages they are called from. It helped me to place the subroutines > in the most appropriate ROM page to minimize changing the PCLATH. > > Here is a short output listing... > > Label Address Page Times called from each ROM page Optimal > ------------------------------------------------------------------ > Page 0 Page 1 Page 2 Page 3 > ------------------------------------------------------------------ > > AnyKey 031E 0 6 13 8 8 N > AreFiles 01C4 0 5 1 0 1 Y > BCstartR 0DDF 1 2 6 4 10 N > > I have no idea if this is of any use to anyone else or not, but here it > is :-) > > http://www.picnpoke.com/demo/CallCalc.zip > > -- > Best regards > > Tony > > mICro's > http://www.picnpoke.com > salesKILLspampicnpoke.com > > -- > http://www.piclist.com hint: To leave the PICList > .....piclist-unsubscribe-requestKILLspam.....mitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestspam_OUTTakeThisOuTmitvma.mit.edu

Interesting. Didn't moving the subroutines into different pages cause the calls to be shifted into new pages? My approach to this problem has been to build a "jump table" to every subroutine entry point which is not in a low half page, in the first half page of program memory (which I reserve part of for just that purpose) and then just make every call or jump a long one; fully setting the page bits before every one. I've found in increases the reliability and maintainability of my code more than the wasted space costs. When I run out of room, I first start trying to shrink my code by reviewing the code (finding shorter algorithms) then, as a last resort, looking for page and bank commands that can be removed. For example, I use a series of macros to build the most program memory efficient register comparisons, lookups, and delay loops possible and hope for memory savings from that. I seem to do ok. Errr, the SX's have a one command page instruction. And the compiler automatically adds them when you use an at sign before the label. call @sub1 rather than call sub1. So it doesn't hurt me as much I guess. Do you think it would be possible to extend your program into one that try's to find the best arrangement of subroutines by actually moving them, changing the page set/clear instructions and re-analyzing the result until it finds the "best fit"? James Newton, PICList Admin #3 jamesnewtonspam_OUTpiclist.com 1-619-652-0593 phone http://www.piclist.com {Original Message removed}

On Mon, 18 Dec 2000, Tony Nixon wrote: > I had some free time over the weekend and wrote this little Windoze > utillity that scans through the code and lists all the subroutines and > what pages they are called from. It helped me to place the subroutines > in the most appropriate ROM page to minimize changing the PCLATH. For the last two weeks I've been computerless while at home. Moving does that to you. I've been thinking about something similar - or I should say a part of what I've been considering falls into the scope of this software you're describing. As part of a final optimization step in the SDCC port to the pic (http://www.dattalo.com/gnupic/sdcc.html), I've been considering an assembler optimizer. In theory it will be capable of taking a .asm file as imput, dissecting it into convenient pieces, and spitting out an optimized version. In practice, it probably will not be capable of working with a hand written .asm file (unless it conforms to a few rules). One of the steps of the optimization would to form the "call tree" and inline functions whenever possible. There are several instances in which a "library" is created and it's functions are only called once from the main application. (I use the term library loosely because pic libraries are just .asm files that have been included into/from another .asm file). For these functions, it be easy to just move them inline. Then the issue of banking could be avoided. Scott -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

j newton wrote: > Do you think it would be possible to extend your program into one that try's > to find the best arrangement of subroutines by actually moving them, > changing the page set/clear instructions and re-analyzing the result until > it finds the "best fit"? Code like this is the bummer if it is called from, say, ROM Page 3. It is the most optimised as is. clrf PCLATH movlw 3Dh call MessProc1 movlw 12h call MessProc2 call AnyKey movlw Cr_Home call LCDins movlw High($) movwf PCLATH Plus it is very hard to determine the end of the subroutine, unless as Scott pointed out in another post, about having rules imposed. Example Sub_X movlw 'X' xorwf RAMx,W btfsc STATUS,Z goto GetY retlw 'X' ; possible subroutine end GetY movf RAMy,W return ; true subroutine end I'd hate to contemplate discecting "spagetti code". -- Best regards Tony mICro's http://www.picnpoke.com @spam@salesKILLspampicnpoke.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics