harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm] IPF functionality
Date Thu, 12 Oct 2006 20:08:44 GMT
I support the first item: to have a separate branch for IPF with periodical
merges to the trunk. Do tests only on merge.
IMO it will simplify the startup for IPF contributors.
Once IPF is ready to run apps as our IA32 version does it will be the time
to move IPF into the trunk.

+ Are there any volunteers to support IPF? Once somebody is interested I
will be glad to help with JIT issues.

On 10/13/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> Hi,
>   There is incomplete support for IPF platforms in the DRLVM codebase, as
> many may have seen. It would be nice to complete it. There are a couple of
> issues on how to start this. IPF specific changes are likely to be quite
> significant, including changes in the JIT, garbage collector(s), exception
> handling model and other core VM areas, as well as IPF functionality and
> performance specific tests. Given the invasive nature of these changes, it
> seems to me that we  could:
> 1. Create a seperate branch in svn and do all IPF work there. JIRA
> submissions could be clearly marked [IPF]. Since most committers may not
> have access to IPF paltforms ( a safe guess :-) ) right now, they could
> help
> by just applying the patches and committing the IPF submissions into the
> branch( without testing, but certainly code review comments and IPF
> verification, if possible are welcome ). It would be  the responsibility
> of
> the few IPF code contributors to keep their branch tested and stable. This
> means some additional work for the committers, but worse..at some point
> when
> the IPF port is completed, if we want to merge the code back into the
> trunk,
> that will not be a small task.
> 2. Not create a seperate branch. Committers ( at least those without
> access
> to IPF ) could verify on their favorite IA32 or EM64T platform before
> committing the IPF related changes also into trunk. This way, we are not
> defering the merge problem, but overall everyone is impacted because there
> will be more commits into the trunk, more conflicts, and things will be
> somewhat slower. This is somewhat the model that we are following with
> EM64T specific submissions now, but IPF specific changes and submissions
> are
> expected to be of higher volume.
> 3. Follow 1, but always keep IPF as a special platform on a seperate
> branch. Never merge back. As IPF functionality is more complete and
> committers get access to IPF machines, we just start testing  more
> rigorously before commiting IPF code and also  start running automated
> tests
> ( whatever we are doing in the main branch ). IPF distributions can be
> rolled out of its own branch.
> However we do it could be a model for porting to other future platforms (
> let's say Mac ) as well. Comments or other ideas?
> Thanks,
> Rana

Mikhail Fursov

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message