Robert P. Thille wrote:
> On Apr 24, 2008, at 4:27 AM, Olin Lathrop wrote:
> 
>> Robert P. Thille wrote:
>>> So, there's no way to have cycle-accurate delays, via subroutine  
>>> call,
>>> in relocatable code.
>> Of course there is.  I noticed you only got one response so far,  
>> and it
>> included incorrect information too.  There is more I would say  
>> about this if
>> James wasn't playing childish games with my account so that all my  
>> messages
>> have to be "approved" by censors before they make it to the list.
> 
> Ok, further investigation (looking at Olin's PIC setup, reading the  
> gputils source, doing some test builds) the assembler, not the  
> linker, (at least with gputils) inserts the instructions (or rather,  
> the right number of NOPs) to effect the PAGESEL.
> 
> The linker then patches up the NOPs with the correct BSF/BCF combos  
> (at least in the 14-bit PIC case that I'm dealing with).  The  
> assembler seems to determine how many instructions to insert based on  
> how many code pages the processor has.  So, with that information  
> available to the macro (looks like Olin's system has that information  
> laid out for each processor it covers in std_def.ins.aspic) it can  
> 'predict' how many instructions the assembler will generate.  I  
> haven't looked closely at BANKSEL, but I'm guessing it's similar.
> 
> The reason I figured that 'predicting' in a macro how many  
> instructions would be emitted was because I thought the linker would  
> do more to optimize PAGESEL.  As I understood it, given it's  
> knowledge of what page the code invoking PAGESEL was on, I was  
> thinking the linker would turn "PAGESEL <addr on Page3>", invoked  
> from Page3, into no instructions.  _Now_ I realize that since PAGESEL  
> doesn't affect the actual program counter, but only the PCLATH, which  
> may or may not be loaded into program counter by a subsequent  
> instruction before being referenced or modified, that optimization  
> wouldn't be valid.
> 
> I wrote this up in hope that it'll help someone else understand it,  
> so they don't make the same mistake I did. And in hope of making the  
> thread have _some_ useful content :-)  BTW, Olin, you didn't need to  
> trim my 'Right?' from the end of my message to make me look more  
> idiotic, I did a decent job of that myself. :-)
> 
> Robert

As far as I see, your summary is correct.

What Olin's macros does (or tries to do) is to
keep track of how the page/bank bits are set
and then only insert instructions if needed.
MPASM does not do that.

Now, Olin also has some macro to invalidate
this tracking, so it will be reset to the
current settings next time the page/bank
macros are called.

Jan-Erik.


> 
> 
> --
> HELP ME FIGHT CANCER!           DONATE HERE: http://tinyurl.com/ynq7uk
> --
> Robert Thille                7575 Meadowlark Dr.; Sebastopol, CA 95472
> Home: 707.824.9753    Office/VOIP: 707.780.1560     Cell: 707.217.7544
> Robert.Thille@rangat.org   YIM:rthille   http://www.rangat.org/rthille
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist