harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm] IPF functionality
Date Fri, 13 Oct 2006 01:08:51 GMT
I think that over time, we will start seeing  IPF specific code files
appearing ... eg., quite a different jit, IPFhelpers.cpp,
IPFexception_filters.cpp, IPFnativestack.cpp,  IPFprofiledrivers.cpp etc.
That is my impression of how most IPF ports go. Even in the main codebase
they will virtually be a branch. While they are architecturally quite
seperate, they are seperate enough to maybe not cause a lot of conflict.
So the question is really one of how we want to manage this, and if we want
to consider the IPF work as mainline work or secondary. That is my
understanding. I am fine with Geir's choice, and his comment about it being
easier to manage one codeline makes sense. But I would request leaving this
open for some more comments from the jit guys and others before we decide.


> On 10/12/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> >
> > How about trying to do in main line for now, reserving branch until
> > needed?
> >
> > We'd agree that committers put in the patches and test on supported
> > platforms (not IPF) and those doing the IPF work test and adjust as
> > necessary.
> >
> > That way, we at least try to keep one codeline that we know works.  It
> > also would "restrict" the freedom of the IPF contributions to stay
> > within the bounds of the mainline code, and in the event an architecture
> > change is needed to support IPF that would affect other platforms, we
> > can talk together.
> >
> > I volunteer to help with the IPF patches.
> >
> >

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