Extension A doesn't define any instructions (anymore)

[ThinkOpenly]

Some instructions claim to be defined by the "A" extension or another extension. Extension A was split into two "sub-extensions", "Zaamo" and "Zalrsc", then defined to simply encompass both sub-extensions.

Since these instructions are actually now defined by the sub-extensions, the instructions should only claim to be defined by them.

Also, move the instruction YAML files from arch/inst/A to their new respective directories arch/inst/{Zaamo,Zalrsc}.

[ThinkOpenly]

If this patch seems OK, I'll stack more similar commits on top. There are quite extensions like this: B, Zce, Zkn, Zks, Zk, Zvkn, Zvknc, Zvkng, Zvks, Zvksc, Zvksg.

[dhower-qc]

I'm OK with this. We'll need to update some of the generation, since this will currently cause us to lose documentation that, e.g., sc is defined by either Zalrsc or A. The information (and logic) is all there, it's just a template change.

[ThinkOpenly]

I'm OK with this. We'll need to update some of the generation, since this will currently cause us to lose documentation that, e.g., sc is defined by either Zalrsc or A. The information (and logic) is all there, it's just a template change.

Anything you want/need me to do? (Probably a bit outside my area of expertise, but I can learn.)

[AFOliveira]

Question on this, will this still be compiled on 20240411 manual? Since ratification of those extensions is actually after that.

Moreover, wouldn't this change be a great point towards introducing versions in this schema? I think it would be a great selling point to once again beat riscv-opcodes. This change will make riscv-opcodes remove any connection of this instructions with extension A but perhaps we can still describe A extension like this:

definedBy:
  anyOf: [A1p0, Zaamo]

[dhower-qc]

@AFOliveira, great point. I'm not sure how to accurately represent this one, though. The A extension didn't appear to increment when Zaamo and Zalrsc were ratified. That seems like a bug in the ISA manual.

Assuming we get that fixed (file a riscv-isa-manual issue?), then UDB is already set up to track such things. It looks like this:

definedBy:
  anyOf:
    - Zaamo
    - { name: A, version: "<= 2.1" } # assuming 2.1 is the version before the bump

[AFOliveira]

Great, I didn't know that versioning there was already possible!

On the A extension, I was back to reading the ISA and I'm not sure that A extension does not add anything.

The A extension comprises instructions provided by the Zaamo and Zalrsc
extensions.

Doesn't this mean that A actually still adds all instructions from both extensions? Can't we just say that a certain processor implements A, without specifying that A is equal to Zaamo and Zalrsc? If not, I think we have exactly the same problem in B extension

[dhower-qc]

I'm OK with this. We'll need to update some of the generation, since this will currently cause us to lose documentation that, e.g., sc is defined by either Zalrsc or A. The information (and logic) is all there, it's just a template change.

Anything you want/need me to do? (Probably a bit outside my area of expertise, but I can learn.)

It's probably best to wait on #403, since that has a lot of changes to the Ruby interface that will be needed.

TLDR; Roughly, each Instruction has a ExpressionRequirementCondition that represents the logic of definedBy: in the YAML. The logic to evaluate (true/false) an ExpressionRequirementCondition given a configuration will already account for extension implications (e.g., A implies Zaamo), but not the code that tries to represent the ExpressionRequirementCondition in asciidoc. That happens in ExtensionRequirementCondition#to_asciidoc:

riscv-unified-db/lib/arch_obj_models/obj.rb

Lines 393 to 412 in 95b376f

	def to_asciidoc(cond = @hsh, indent = 0)
	case cond
	when String
	"#{'*' * indent}* #{cond}, version >= #{@cfg_arch.extension(cond).min_version}"
	when Hash
	if cond.key?("name")
	if cond.key?("version")
	"#{'*' * indent}* #{cond['name']}, version #{cond['version']}\n"
	else
	"#{'*' * indent}* #{cond['name']}, version >= #{@cfg_arch.extension(cond['name']).min_version}\n"
	end
	else
	"#{'*' * indent}* #{cond.keys[0]}:\n" + to_asciidoc(cond[cond.keys[0]], indent + 2)
	end
	when Array
	cond.map { |e| to_asciidoc(e, indent) }.join("\n")
	else
	raise "Unknown condition type: #{cond}"
	end
	end

[ThinkOpenly]

Question on this, will this still be compiled on 20240411 manual? Since ratification of those extensions is actually after that.

I see the dates are offset (ISA = 20240411; Zaamo/Zalrsc = 20240425), but there is no context presented in the ISA that those extensions are unratified. They are certainly presented as ratified extensions.

@AFOliveira, great point. I'm not sure how to accurately represent this one, though. The A extension didn't appear to increment when Zaamo and Zalrsc were ratified. That seems like a bug in the ISA manual.

Would the version of extension "A" need to be incremented in this case? From a support standpoint, the content of the extension didn't change.

On the A extension, I was back to reading the ISA and I'm not sure that A extension does not add anything.

The A extension comprises instructions provided by the Zaamo and Zalrsc
extensions.

Doesn't this mean that A actually still adds all instructions from both extensions? Can't we just say that a certain processor implements A, without specifying that A is equal to Zaamo and Zalrsc? If not, I think we have exactly the same problem in B extension

I read "comprises" as "is fully defined by". If anything other than that, I'd expect to see "includes" or "comprises ... Zaamo and Zalrsc AND [the following instructions]". In other words extension "A" is exactly the combination of "Zaamo" and "Zalrsc".

Moreover, wouldn't this change be a great point towards introducing versions in this schema? I think it would be a great selling point to once again beat riscv-opcodes. This change will make riscv-opcodes remove any connection of this instructions with extension A but perhaps we can still describe A extension like this:

definedBy:
  anyOf: [A1p0, Zaamo]

This is a neat idea, and we'll probably find uses for it, but I don't think it applies here. There is only one extension "A".

Before roughly April 2024, extension "A" defined a set of instructions. Afterwards, "A" comprised extensions "Zaamo" and "Zalrsc", together comprising the exact same set of instructions. If we need a way to support the state over all time, we probably need to keep the original list "definedBy: anyOf: [A, Zaamo]".

[AFOliveira]

Question on this, will this still be compiled on 20240411 manual? Since ratification of those extensions is actually after that.

I see the dates are offset (ISA = 20240411; Zaamo/Zalrsc = 20240425), but there is no context presented in the ISA that those extensions are unratified. They are certainly presented as ratified extensions.

I understand the individual changes are ratified and should be in UDB. My question was more towards Derek and about UDB "infrastructure": When we generate the 20240411 manual, will these changes be included? And how can we ensure that does not happen?

I read "comprises" as "is fully defined by". If anything other than that, I'd expect to see "includes" or "comprises ... Zaamo and Zalrsc AND [the following instructions]". In other words extension "A" is exactly the combination of "Zaamo" and "Zalrsc".

Agree. Again, I think I misexplained my point. Since A = Zaamo + Zalrsc, should we not let the UDB know this? Because even though the smaller extensions are the ones that define the instructions, A extension still includes them all (even if only by including the other sub-extensions). I don't think the UDB has any way to specify relations between extensions, and therefore, if that description is removed, how will we be able to generate "A" extension documents? It will be only text without proper connection to "Zaamo" and "Zalrsc".

definedBy:
anyOf: [A1p0, Zaamo]
This is a neat idea, and we'll probably find uses for it, but I don't think it applies here. There is only one extension "A".

There are however two ratified versions of A. And if version 2.1 is what removes the instructions from being described by A, we should state that, although I'm not sure this is the case due to the previous content of my answer/

[ThinkOpenly]

I understand the individual changes are ratified and should be in UDB. My question was more towards Derek and about UDB "infrastructure": When we generate the 20240411 manual, will these changes be included? And how can we ensure that does not happen?

I confess I don't understand this concern as expressed. What should not appear in the 20240411 manual?

I read "comprises" as "is fully defined by". If anything other than that, I'd expect to see "includes" or "comprises ... Zaamo and Zalrsc AND [the following instructions]". In other words extension "A" is exactly the combination of "Zaamo" and "Zalrsc".

Agree. Again, I think I misexplained my point. Since A = Zaamo + Zalrsc, should we not let the UDB know this? Because even though the smaller extensions are the ones that define the instructions, A extension still includes them all (even if only by including the other sub-extensions). I don't think the UDB has any way to specify relations between extensions, and therefore, if that description is removed, how will we be able to generate "A" extension documents? It will be only text without proper connection to "Zaamo" and "Zalrsc".

Is implies insufficient?

name: A
[...]
versions:
  - version: "2.1.0"
    state: ratified
    ratification_date: 2019-12
    [...]
    implies:
      - [Zaamo, "1.0.0"]
      - [Zalrsc, "1.0.0"]

There are however two ratified versions of A. And if version 2.1 is what removes the instructions from being described by A, we should state that, although I'm not sure this is the case due to the previous content of my answer/

Are there two versions? It's certainly challenging to figure historical things out, but I see the the "A" extension moving from unratified in ISA 20190608 to ratified at version 2.1 in ISA 20191213, but there is no Zaamo/Zalrsc, of course, until April 2024. Has the version of "A" been bumped past 2.1?

[AFOliveira]

I confess I don't understand this concern as expressed. What should not appear in the 20240411 manual?

Ratification of "Zaamo" and Zalrsc happened after that date, so they should not be in that version of rafied manual, or am I wrong? I'm not sure this is how it happens, but seems most logical.

Is implies insufficient?

name: A
[...]
versions:

• version: "2.1.0"
  state: ratified
  ratification_date: 2019-12
  [...]
  implies:
  • [Zaamo, "1.0.0"]
  • [Zalrsc, "1.0.0"]

Sure, can the UDB handle this? If so, forget what I was saying, I just thought it was not possible.

Are there two versions? It's certainly challenging to figure historical things out, but I see the the "A" extension moving from unratified in ISA 20190608 to ratified at version 2.1 in ISA 20191213, but there is no Zaamo/Zalrsc, of course, until April 2024. Has the version of "A" been bumped past 2.1?

I made an assumption that 2.1 implied 1.x ratification. Also, since Zaamo and Zalrsc made changes to A extension I made another assumption that A had to have changes. Turns out I may be completely wrong. I'll try to figure this out better, sorry for the confusion. It's clear I'm missing some things with the naming schema.

[ThinkOpenly]

I confess I don't understand this concern as expressed. What should not appear in the 20240411 manual?

Ratification of "Zaamo" and Zalrsc happened after that date, so they should not be in that version of rafied manual, or am I wrong? I'm not sure this is how it happens, but seems most logical.

You're not wrong on the dates, for sure. I can't explain the existence of the date lag and the appearance of full ratification in the ISA 2 weeks earlier. Maybe "the paperwork" took a few extra weeks? It's a little odd.

Is implies insufficient?

name: A
[...]
versions:

• version: "2.1.0"
  state: ratified
  ratification_date: 2019-12
  [...]
  implies:

  • [Zaamo, "1.0.0"]
  • [Zalrsc, "1.0.0"]

Sure, can the UDB handle this? If so, forget what I was saying, I just thought it was not possible.

Thinking more about this, I think "implies" is insufficient, because it is used to say "this extension depends on these other extensions" as well as "this extension comprises/includes these other extensions".

We probably need a "comprises" field.

I made an assumption that 2.1 implied 1.x ratification. Also, since Zaamo and Zalrsc made changes to A extension I made another assumption that A had to have changes. Turns out I may be completely wrong. I'll try to figure this out better, sorry for the confusion. It's clear I'm missing some things with the naming schema.

Good luck. ;-)