[Top] [All Lists]

Re: Performance counters and profiling on MIPS

To: "Jonathan Day" <>
Subject: Re: Performance counters and profiling on MIPS
From: "Prasad Boddupalli" <>
Date: Tue, 13 Jun 2006 14:44:28 -0700
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta;; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=uT/8hinHjL++OaDcBc7vASg320Vte8RbAJ1+UNZ7y+FZZdnFLg2A1kE8RAY9fGs+88y1vTIaKhqh08EGqMgPxv/cS4QiD8/IpwDET5Cd4gXZwzsHk8x5Q26NuJhlWCyyXmJBHAnCGwXM1zU4MgBF0NBmAUeKbZzKijj6gwFPmNc=
In-reply-to: <>
Original-recipient: rfc822;
References: <> <>
Perfctr ( and PAPI
( are precisely such attempts. Except that
MIPS ports of them do not seem to be available.


On 6/13/06, Jonathan Day <> wrote:
Thank you for the valuable information.

One thing I'd like to throw open to the list: there's
one way to access the counters on the R4000-type
processors, another on the version 2 MIPS64, yet
another on the ix86, and so on.

Would it make sense to place some standardised
interface in, say, the assembly header files and hide
the implementation-specific details? In the case of
the R4000-type cores, this would need to involve some
sort of counter device in the kernel which the macro
would call to perform the priviledged instruction. (It
feels a little bit of a hack, but it's the simplest
way to provide access to resources that aren't made

What I'm thinking is that this generic interface would
then be used on all other architectures, where such
counters exist. That way, implementation-specific
stuff can be abstracted out and programs that need
access to performance counters can all be coded to a
generic interface, rather than one interface for each
version of every CPU API, which is inevitably going to
be far more prone to error.


<Prev in Thread] Current Thread [Next in Thread>