I'm not sure what you're referring to Line 244 list Zihintpause Lines 180-188 list Zvlsseg, Zvamo, Zvediv, Zvqmac, Zve32x, Zve32f, Zve64x, Zve64f, Zve64d Lines 138-147 list Zba, Zbb, Zbc, Zbe, Zbf,

Duplicating the information (i.e. having the individual extensions marked and the profile itself indicated) seems like an error-prone proposal, unless we mandate/enforce consistency checking. Given

Greg and I did discuss having Unified Discovery (UD) description macros for profiles, e.g. an RV22A bit that indicates support for all of the individual extensions (and option value ranges) required

Allen, There is no 'RVB'... and even the basic options on Zb[abcs] open up 16 possibilities. Similarly 'V' is a not a single option, but multiple Zv* options. Finally, Zihintpause is

FYI: here is a rough initial draft of the architectural options that I've been able to dig up. I know that this is very, very likely to be incomplete. This is written from the perspective of how to

We would then have 2 different namespaces representing many similar constructs. Doesn't that make things more complicated? e.g. If everything that is a non-traditional extension in the Profile has a

What I'm saying (or at least my leaning) is that discovery methods should use K-V pairs as they do today (with standardized K names desired). Whereas Profiles have a more limited goal of having

It's very much the same exercise where the Profile specific options are more narrowly scoped. However, I would imagine the ones created for the Profiles to be a subset of the larger KV space as you

Unfortunately, I don't a have single term that would adequately convey the idea. Greg and I were batting around some invented words (e.g. "poption" as a portmanteau of profile-option was my first

Slimming down the CC list a bit, as this is off topic for some lists. I'm in the process of getting status from the new Unified Discovery

Identifier in the sense of a short name/phrase that refers to these ideas. Consumers of that would be both software and day-to-day discussion as it's a succinct identifier that refers to an idea in

Correct. Do you have a better term that captures such notions? I fully agree that the previous definition of an extension is not the same in this case. FWIW, the profile spec uses both 'extensions'

Hi Aaron, Since the ECRs need to be submitted as word doc, the plan was to archive the notes/comments and ECR versions in the gdrive itself. Please

To add on to Alan's point. These "extension" names were created simply to represent individual line items in the Profiles. In many cases these represent a one or two sentence statement in a Profile

I'm also unclear of the "identifier" you mention for other unmentioned option value (e.g. your 64b cache block size example). Who is the consumer of that identifier? Is this a value you would expect

If you're looking at the same thing I was looking at: the "extension names" are not extensions, in the usual sense. They are names for the values of architectural options of extensions that already

Got it. I understand what you are saying now and agree. regards ved

Hi Aaron, Few comments below ... Rather than gating these ACPI ECR efforts on AIA spec being frozen. We should start sending out incremental ECRs for the things that are already ratified. Each ECR

Does the Unified DIscovery Specification exit yet? Where can I find it? Best regards Heinrich

Just that UD is the source for filling in everything. In my words foundational and not just orthogonal. I didn't see it below in, for example, discussions about ISA strings. I wanted to make sure that