Hi Stephane,
Good point, that's another option. I've been trying to avoid that all along,
but it's definitely a cleaner alternative.
I can modify the script so that if any of the maximums are violated, it will
flag an error and not let the code be auto-generated.
If you are ok with wasting some space, I will go ahead and try that out.
Here's
a guess at the amount of unused space:
For the 970*,power4 machines, they have about 3 unused vectors * 8 bytes * 64
events = 1.5kB per arch = 4.5kB total.
For Power5* machines, the have (2 unused counters * 4 bytes + 1 unused vector *
8 bytes) * 500 events + 2 unused counters * 4 bytes * 180 groups = 9.4kB per
arch = 18.8kB total
For Power 6, 7, they have about 2 unused counters * 4 bytes * 550 events + 2
unused counters * 4 bytes * 248 groups = 10.8kB per arch = 21.6kB total
So, in all, it would be about 45kB. Let me know if you are ok with that.
- Corey
stephane eranian wrote:
> Corey,
>
> Looking at the *_entry_t and *_group_t, I am wondering if it would
> be possible to just use the biggest-sized structure for all models.
> It would be oversized for the earlier models, but then it would improve
> readability, and I understand unfortunately, the size of the event tables.
>
>
> On Wed, Jul 15, 2009 at 11:32 PM, Corey
> Ashford<cjash...@linux.vnet.ibm.com> wrote:
>> (forgot to attach the patch, so here it is)
>>
>> Hi,
>>
>> I've made a stab at consolidating the event and group types for the Power
>> chips (ppc970 through Power7).
>>
>> I'm not real happy with the result. It is a little more compact in the
>> coding of the case statements, but in gaining some compaction, we've lost
>> some clarity.
>>
>> I made an attempt to be able to use one pair of types for all processors,
>> but the C99 language doesn't appear to like things like this:
>>
>> int *foo = { 1, 2, 3 };
>>
>> but has no problem with:
>>
>> char *foo = "some string";
>>
>> This seems like an inconsistent compiler design to me, but without that
>> support, I cannot easily use a pointer in replacement for fixed-length
>> arrays. So the choice then becomes:
>>
>> 1) Create separately-declared and named fixed-length arrays which are then
>> pointed to by the event and group arrays.
>>
>> 2) Consolidate the structures containing fixed-length arrays that are really
>> the same, but keep separate those that aren't. This means we still need
>> switch statements based on the PMU type, but the number of truly separate
>> cases is reduced.
>>
>> I chose 2 because it creates a much smaller patch, and I'm not sure I like
>> the idea of creating a bunch of separate declarations, and would take extra
>> room over all (adds pointers). On the other hand, the structures have ugly
>> names like pme_power_c6_v4_event_t (c6 = 6 counters, v4 = 4 group vectors).
>>
>> Anyway, please have a look, and let me know if you see another way to do it,
>> or or if you'd have solution 1.
>>
>> P.S. As I was working on this, I ran across a few problems with the PCL
>> codes on Power5+ and Power6, and I will need to patch that at some point. I
>> would like to get this "consolidate or not" decision made first, though.
>>
>> Signed off by: Corey Ashford <cjash...@us.ibm.com>
>>
>> --
>> Regards,
>>
>> - Corey
>>
>> Corey Ashford
>> Software Engineer
>> IBM Linux Technology Center, Linux Toolchain
>> cjash...@us.ibm.com
>>
>> IBM Linux Technology Center, Linux Toolchain
>> Beaverton, OR
>> 503-578-3507
>> cjash...@us.ibm.com
>>
--
Regards,
- Corey
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjash...@us.ibm.com
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
