gnupic: Re: [gnupic] Object File Bit Relocation
Subject:
Re: [gnupic] Object File Bit Relocation
From:
"David Barnett" ####@####.####
Date:
29 Jan 2007 17:30:39 +0000
Message-Id: <050001c743cb$4d392040$2001a8c0@barnett2>
----- Original Message -----
From: "Robert Pearce" ####@####.####
To: ####@####.####
Sent: Sunday, January 28, 2007 1:04 PM
Subject: Re: [gnupic] Object File Bit Relocation
> 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.
Sounds like a reasonable guess. Any idea whether that would be a limitation
with the object format or the linker?
> 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.
The primary use I see would be selecting I/O pins for bit-banged libraries.
Currently I have to recompile for each device to change pins, and I have
that sort of thing come up a lot.
> 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.
Interesting. Is that to solve the problem of packing arbitrary bits into
bytes? I don't think it would do much for my current projects, but I'd like
to see that sometime, if you don't mind.
David
