Great!
On Mon, Dec 14, 2009 at 12:23 PM, Michael Trimarchi
<
mic...@panicking.kicks-ass.org> wrote:
> Ok, I have started from the eclair branch and change agaist this branch,
> so all the patches are agaist this branch. We need the same manifest but
> related to the eclair branch.
I'll take a look at it at some point soon.
I believe one major obstacle (that has been present for a while) is
the issue of dynamic code generation. This is obviously independent of
the build system, but it's very problematic because, for example,
libpixelflinger/codeflinger generates ARMv5TE instructions !
Perhaps someone on the list already has a good strategy for getting
around this, but it is still something I have not addressed.
Anyone?
Is there an existing solution that is already present in the build
system? If so, does it have anything to do with QemuTracing?
If there is no existing solution, these are the only other options
that I can come think of:
1) Attempt to emulate the existing, ARMv5TE, ARMAssemblerInterface
using only ARMv4T instructions
* will probaby prove to be very difficult
* will require extreme expertise in ARM assembly language
* any ARMv5TE conditional bits / flags / branching would need to be 'emulated'
* if implemented, could be very rewarding (no code that uses
libpixelflinger will have to change)
* will be dramatically slower than ARMv5TE, so every clock cycle counts
2) Create a separate ARMAssemblerInterface that only works with ARMv4T
* would be relatively easier to implement
* will also require a lot of expertise in ARM assembly language
* not as rewarding (it will require a rewrite of code that uses libpixelflinger)
* will probably be faster than emulating ARMv5TE instructions, but
still slow, so every clock cycle is still important
3) Use both methods 1 & 2, and decide at compile-time or run-time
which would be better
4) Specifically for the FR, it might be possible to do some of this
with the Glamo... (any volounteers?)
Thoughts?
I think option 3 is probably the safest bet, for now.
Chris