eclair branch

[Michael Trimarchi]

Hi all,

can anyone has time to prepare an eclair branch. For the freerunner part just do a copy of the cupcake one
and I will push patches agaist all the git repository

Michael

[Jim Ancona]

Hi Michael,

I don't understand what you need. If you need help pushing your
changes, let me know what you would like me to do. If you'll send me a
patch against the the Google repository, I can push it to our repo.

Jim

[Marco Trevisan (Treviño)]

Jim Ancona ha scritto:

I figure you should create/import the new google eclair branch to the
android-on-freerunner gitorious server to allow Micheal to merge his
patches against it.

[Jim Ancona]

I'm pretty sure that he can just push his eclair branch to the
repository--nothing needs to be created in advance.

Jim

[Michael Trimarchi]

Jim Ancona wrote:
> On Mon, Dec 7, 2009 at 10:11 PM, Marco Trevisan (Trevi�o)

Sorry, but I don't want to do some mistake, it's better that you create the eclair
branch so I can push against it

Thanks for the support

[Harry Mutch]

2009/12/9 Michael Trimarchi <mic...@panicking.kicks-ass.org>:

> Sorry, but I don't want to do some mistake, it's better that you create the
> eclair
> branch so I can push against it

If you have created an "eclair" branch in your local repository you
should just need to run

$ git push eclair

I believe you have commit rights and changes can always be rolled back
so give it a go ;)

[Michael Trimarchi]

The branch must be created for each subproject from manifest to xxxx,
but I don't know if it is possible todo with repo command

Michael

[Jim Ancona]

repo start --all eclair

creates an eclair branch in all the projects listed in the manifest.

I'll see if I can figure out how to create an empty eclair branch at
Gitorious. Please send me your manifest.xml, so that I know what new
repositories I need to create.

Jim
>
> Michael
>
>

[Michael Trimarchi]

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.

>
> Jim
>> Michael
>>
>>
>

[Christopher Friedt]

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

[Christopher Friedt]

Also, are there any other modules that perform similar dynamic code generation?

[Christopher Friedt]

One more option

5) Define out all routines that would require runtime code generation
* would probably be the fastest option of all (in terms of user
experience on ARMv4T)
* would eliminate a lot of 'pretty' visual effects
* requires little to no knowledge of assembly language
* could potentially require a lot of code auditing, all over the place