* David Miller <da...@davemloft.net> wrote:
> From: stephane eranian <eran...@googlemail.com>
> Date: Wed, 7 Oct 2009 14:31:58 +0200
>
> > What PPC does is probably the only way to do this given the interface
> > between
> > generic and machine-specific code. The one advantage I see is that it works
> > inside an event group but also across event groups because that code does
> > not
> > look at group boundary, it only looks at the events and the number of
> > available
> > registers. The downside is that you duplicate state.
> >
> > Did I get this right, Paul?
>
> That's basically how his code works, yes. I intend on duplicating it
> to some extent on sparc64 since I'm operating in a similar problem
> space.
>
> So if at least some of this engine went to a generic place, there'd be
> at least a 3rd user :-)
Yeah, i'd definitely suggest to generalize this. We've missed updating
PowerPC lowlevel details a couple of times in perf core updates, just
because it's in a non-obvious place. Even if it's used by just a single
arch, generic code is much more visible.
PowerPC really has this somewhat somewhat weird track record of
privatizing generic facilities and smugly keeping it to themselves as a
competitive advantage ;-) Reminds me of the old semaphore code which was
the best on PowerPC, for years. Lets not go there again :)
Ingo
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
