Page boundaries

[Desterline]

Hi all,
My project has grown past the 2K point, and of course I'm getting the warning messages "[102] code crosses boundary @ 800h".

I realize this is normal, and only there to warn me about using the branch instruction and such. Thing is, I'm using the branch instruction in one of my routines. Since I'd rather not have the overhead penalty of branchL, and it's a short rouine (>200 words) is there a way to be certain the whole routine is in one page?

Thanks,
-Denny

[Bruce]

Hi Denny,

You have a couple of options.

1. The easiest option is to just place the branch routine & the sub it branches to in the beginning section of your code. Then insert a goto Main to jump over both to your main routine.

2. Examine the .lst file generated after compiling your code to see where your routines are being placed in program memory. They might be within the first 2k depending on how large your program is, and how many library routines your code is using. PBP has to stuff all library routines in the first code page.

3. Force PBP to compile the routine in a certain code page using the @ org statement. I.E. @ org 0x800 would force PBP to place code below the org statement starting in page 1 at 800h.

With option 3 you're going to waste code space between pages, but it does guarantee where the routines are physically placed at compile time. Normally you're better off just using branchl than option 3.

[Desterline]

Thanks Bruce,
Putting it at the beginnning was what I was thinking, but I wasn't sure how to be 'certain'. (examine the output.. duh... :-)

You probably read my other recent post, the branch is part of that interrupt routine and for obvious reasons I was trying to avoid the slower, larger branchL.

Thanks
-Denny

[Melanie]

I don't really want to butt-in on this thread, but it's going to be seriously remote that your code will spill out of the first page if you place it at the start of your program if it's only a few hundred bytes.

The beginning of most programs are taken up with hardware and software defines, aliases, config fuse definitions, EEPROM Data statements etc. None of these use any actual Program Codespace. The first executeable statement in your code will probably be...

Goto Start

You've then got the best part of 2k to play with until your...

Start:

statement. Actually I'm looking at one of my programs which has 794 lines of definitions, aliases, data statements, comments and such before the first byte of actual program gets executed... and yup, it's a "goto Start" statement, since I have a habit of putting all my commonly used subroutines at the beginning to save on codespace.

[Bruce]

Hi Denny,

I saw your other post, and figured these two were related. The problem with using the HIGH & LOW commands is PBP won't allow a number greater than 15.

HIGH / LOW 0-7 works for RB0-RB7, then 8-15 for RC0-RC7.

If you could re-arrange your column drivers on RB & RC it would work by assigning a port pin to a variable like X = 8, then HIGH / LOW X.

Having them spread over RA, RB, RC, RD and RE makes it tough.

[Bruce]

Originally posted by Melanie


since I have a habit of putting all my commonly used subroutines at the beginning to save on codespace.

Hi Melanie,

I've gotten into the same habit. Mostly because of the page boundary issue on the 14-bit core. Just curious. How does it save on codespace when placing commonly used subroutines in the beginning?

[Melanie]

Before I answer that... you've obviously got programs in your collection that are bigger than 2K... take a subroutine, place it at the beginning of your program and compile... then extract that same subroutine and place it at the end of your program and recompile... note the difference...

What doesn't happen in the bottom 2k that happens elsewhere? Think assembler level... OK, I should add a rider to that... it doesn't apply to really simple subroutines... rather the more complex ones... I've got into the habit of putting ALL subroutines at the start...

[Bruce]

I know about additional overhead for PCLATH when crossing the 2K boundary.

Just thought maybe you had tinkered with shifting things around inside the boundary, and noticed a change.

[badrad]

moving subroutines to the beginning saved me 77 bytes!
that is so neat!

my program was in the 7.5 K range, and I had spent the past few days whittling it down to 5094 bytes. after reading this thread - I moved my subroutines to the begiining just after my defines, and placing a goto statement in front of the subroutines - i recompiled and was now down to 5017.

cool!

heres a question - could there be more savings acheived by placing subroutines that are more commonly used even further at the beginning than other less used subroutines? i guess I'll have to give a try...

[Desterline]

Melanie, You're welcome to butt in on any of my posts. I have great respect for both yourself and Bruce and any guidance you would show an undeserving serf such as myself is greatly appreciated.

It was also my understanding that PBP places it's library functions at the begining too. Thus complicating matters a little more.


>Bruce replied<
I saw your other post, and figured these two were related. The problem with using the HIGH & LOW commands is PBP won't allow a number greater than 15.

HIGH / LOW 0-7 works for RB0-RB7, then 8-15 for RC0-RC7.

If you could re-arrange your column drivers on RB & RC it would work by assigning a port pin to a variable like X = 8, then HIGH / LOW X.

Having them spread over RA, RB, RC, RD and RE makes it tough.

Agreed, spreading them accross the ports wasn't my first choice. But as I mentioned (in the other post) these are the column drivers for multiplexed bi-color 5x7 led marix displays with port b[0..6] and port d[0..6] controling the row data. Add a serial port to that (uses port c 6 & 7) and I'm out of options (unless you have a better idea)
I'm not tied to the high and low instructions either, I could write directly to the registers just as easily.

The current interrupt is tolerable at about 50 us @ 4Mhz. But I'd like better (wouldn't we all? :-)

Thanks,
-Denny

[Melanie]

Badrad... go see my posting in the FAQ section... "I’m Running Out of CodeSpace, What Can I Do?"... then come back and tell us what happend to your code...

[badrad]

Originally posted by Melanie
Badrad... go see my posting in the FAQ section... "I’m Running Out of CodeSpace, What Can I Do?"... then come back and tell us what happend to your code...

neat - I assigned as many variables as possible to bank0 (i still have a dozen variables and a couple of arrays that aren't on bank0), but this last compile gave me 3894 bytes, a savings from the previous compile of 5017 - so freed up 1123 bytes!

Thanks again!

[Melanie]

Obviously assign the variables you use most in preference to the ones you use least. Bank0 isn't endless. That's not bad... you freed up 20% of what you had previously used... along with repositioning subroutines, has to be one of the biggest codespace saving moves you can make.

BTW... talking about those subroutines... you CANNOT move any subroutines that are involved with interrupts. Those routines MUST be placed AFTER your first ON INTERRUPT/ENABLE statement. Placing the routine before them doesn't compile-in the nescessary interrupt jump code.

[badrad]

Originally posted by Melanie
Obviously assign the variables you use most in preference to the ones you use least. Bank0 isn't endless.

i noticed that. I still have a couple of large arrays that i could not fit into bank0. would have been nice if i could, but the savings so far have exceeded my expectations.

i had 4 new features (part of feature creep) that i needed to implement, and i was sweating a bit for space.

BTW... talking about those subroutines... you CANNOT move any subroutines that are involved with interrupts. Those routines MUST be placed AFTER your first ON INTERRUPT/ENABLE statement. Placing the routine before them doesn't compile-in the nescessary interrupt jump code.

thanks for the heads up here. not using interrupts in this project, but good info - i likely would have done the same thing with moving up the subroutines.

thanks again!