gnupic: Re: [gnupic] Object File Bit Relocation
Subject:
Re: [gnupic] Object File Bit Relocation
From:
"David Barnett" ####@####.####
Date:
1 Feb 2007 14:56:51 +0000
Message-Id: <05ab01c74611$469114d0$2001a8c0@barnett2>
----- Original Message -----
From: "Robert Pearce" ####@####.####
To: ####@####.####
Sent: Wednesday, January 31, 2007 4:45 PM
Subject: Re: [gnupic] Object File Bit Relocation
> On Mon, 29 Jan 2007, David Barnett ####@####.#### wrote :
>>> 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?
>
> Yes. The application has quite a few boolean values flying around, so I
> wanted a way to automatically pack them.
Actually, that sounds like it partially solves another issue that's been
bugging me. I've read that most C compilers allocate an entire byte to each
boolean variable. I completely understand how that would simplify the
memory accesses when memory is cheap, but I would think packing the bits
would be wiser in an embedded environment. I know runtime bit-array
accesses would be slightly more complicated, and boolean
params/returns/struct members would take some finagling...are there any
severe complications I'm missing?
The Sourceboost compiler partially implements bit packing, but it completely
disables boolean functions, boolean arrays, and boolean struct fields (gives
a compiler error). It uses a custom object-file format, so it probably
skirts any relocation issues. SDCC allows bit fields but allocates a byte
to each bool. (BTW, I'm using Sourceboost until SDCC gets function inlining
because BoostC has inline function support and a very unrestrictive demo
version).
Back to the point, I've been wondering how feasible it would be to add a
bool-packing option to SDCC. The lack of bit relocation would really
complicate that implementation, wouldn't it? I was contemplating adding a
corresponding bit-relocation option to gpasm/gplink, but I don't know if
that's a good idea compatibility-wise. Still, it seems like there are some
pretty massive gains to be made. Ideas?
David
