gnupic: Re: [gnupic] Linker Optimizations
Subject:
Re: [gnupic] Linker Optimizations
From:
"David Barnett" ####@####.####
Date:
5 Mar 2007 18:59:21 +0000
Message-Id: <0bee01c75f57$ee967620$2001a8c0@barnett2>
----- Original Message -----
From: "David Barnett" ####@####.####
To: ####@####.####
Sent: Friday, March 02, 2007 3:48 PM
Subject: Re: [gnupic] Linker Optimizations
...
> I ask because I wasn't aware you could extract pCode from pure assembly
> code. As I mentioned in the last email, there's some flow information
> that you could extract from C, but I don't think from asm, that would be
> necessary for a lot of the optimizations.
...
> David
I think these concerns of mine might be significant, so I'll elaborate a
bit.
For one thing, it's not always a straight-forward task to determine where a
function begins or ends. Often the programmer manually optimizes a tail
call to a goto, and there may be several exit points including computed
gotos. That means that the exit points may be determined by the flow of
execution, but there are all sorts of runtime complications to consider.
The selected bank will not be known at the entry point(s), nor will any
other registers (except possibly PCLATH). The bank selection bits or PC
registers (or even FSR) might be modified through INDF, and all that could
lead to computed gotos with targets either internal or external to a
function.
On the other hand, I guess things could probably just as complicated with C
source code because, as a trivial example, it could include inline assembly
code with the same issues. If we can solve those problems from the
assembler/linker end, that will cut out all of the concerns I had with
getting the information from the compiler to the linker. Still, it seems
like quite a challenge to me. Do you think it's manageable?
David
