Having the ability to discriminate based on revision would be a *good thing*. I'm not particularly fond of the mix-n-match approach taken for PIII. Although I understand why it's necessary. Is there not some way to implement a more generic solution through the flags field? I.E. Rev E maps to flag bit 6. If that bit is set and you aren't Rev E, return error. That may change some calling semantics, tho... - dan
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:perfmon- > [EMAIL PROTECTED] On Behalf Of Stephane Eranian > Sent: Wednesday, May 09, 2007 4:52 PM > To: Dan Terpstra > Cc: [EMAIL PROTECTED] > Subject: [perfmon] AMD events and revisions > > Dan, > > Here is another thought on the AMD event table. > > It seems that several events are marked with a processor > revision, e.g., rev E. The table does not yet capture this > kind of restrictions. I think it would be worth adding > support for Revision checking to avoid mistakes. > > The libpfm API does not support event tables with holes in > the indexing. As such we would have to provide multiple tables > based on the revision. Note that they could be built from > macros stitched together like what I did for Pentium II vs. Pentium M. > > Then in the detect() routine, we would initialize the current table > pointer just like what we do for PIII. > > Now I don't know the mapping between the Revision letters and the > family/model numbers but I am sure we could find this out. > > What do you think? > > -- > -Stephane > _______________________________________________ > perfmon mailing list > [email protected] > http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/ _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
