gnupic: Re: [gnupic] Object File Bit Relocation


Previous by date: 28 Jan 2007 19:37:11 +0000 Object File Bit Relocation, David Barnett
Next by date: 28 Jan 2007 19:37:11 +0000 Re: [gnupic] Object File Bit Relocation, David Barnett
Previous in thread:
Next in thread: 28 Jan 2007 19:37:11 +0000 Re: [gnupic] Object File Bit Relocation, David Barnett

Subject: Re: [gnupic] Object File Bit Relocation
From: Robert Pearce ####@####.####
Date: 28 Jan 2007 19:37:11 +0000
Message-Id: <wVkyrwdlOPvFFwgm@daniel.huneausware.local>

On Fri, 26 Jan 2007, David Barnett ####@####.#### wrote :
>I'm also wondering if there is some real limitation in the object file 
>format that would actually prevent bit offsets from being relocated, or 
>if it is just not supported in MPASM or gpasm.  I can imagine several 
>uses for bit relocations.  Any idea why Microchip doesn't support them?

These are only guesses, but...

The relocation mechanism in the linker is designed around addresses - 
whether register or code. The instruction set coding is such that both 
of these always occupy a consistent part of the instruction word. And 
furthermore, only one such address appears in any given word (this is 
true even of the 16-bit MOVFF instruction since that's a two word 
instruction). This is not true of the bit index.

Furthermore, other (8-bit) processors that support bit test instructions 
commonly code the bit number into the instruction, while the linker only 
ever has to apply relocation to whole bytes or words. So there isn't 
really an established expectation of being able to have bit numbers 
assigned at link time.

It's also far less obvious that the bit number would ever need to be 
changed that way. Variables are commonly made global, and function entry 
points are very often global, but bit numbers are most often used only 
to refer to fixed items like peripheral control flags.

Some years back I worked on a system based around the Intel 80196 CPU, 
which supports bit operations on registers. For this application we 
wanted to be able to declare a large and variable number of "flags" to 
be made global. The linker could not do this, and the assembler threw an 
error on any attempt to do so. What we ended up with was that _every_ 
flag test was coded for bit 0 (rather as gpasm does!) and a custom 
application running after the linker searched for all bit operations and 
over-wrote them with the correct version.

For my current PIC application I knocked up a Python script that runs 
before the assembler and generates a header file for all the flags. It's 
a tiny bit kludgy, but it works.
-- 
Rob Pearce                       http://www.bdt-home.demon.co.uk

The contents of this | Windows NT crashed.
message are purely   | I am the Blue Screen of Death.
my opinion. Don't    | No one hears your screams.
believe a word.      |

Previous by date: 28 Jan 2007 19:37:11 +0000 Object File Bit Relocation, David Barnett
Next by date: 28 Jan 2007 19:37:11 +0000 Re: [gnupic] Object File Bit Relocation, David Barnett
Previous in thread:
Next in thread: 28 Jan 2007 19:37:11 +0000 Re: [gnupic] Object File Bit Relocation, David Barnett


Powered by ezmlm-browse 0.20.