CRDs list things like instructions, CSRs, and traps that aren't in the configuration

[james-ball-qualcomm]

[james-ball-qualcomm]

There is only one I extension, not an RV32I and a RV64I. Therefore, when I ask the I extension for all its instructions, I get 32 and 64 versions. I see there is an optional base field in the instruction schema. I assume I should filter out instructions based on the portfolio's base value. Is this correct?

[dhower-qc]

Correct. You can do something like ext.instructions.select { |i| i.base != 64 }

[james-ball-qualcomm]

Seems like I should be asking the Extension object for a list of instructions and pass it enough information for it to figure out what is present or not. I don't know if an Extension has things like base or maybe even parameters that control what instructions are actually present. BTW, are there any cases yet like that where a parameter controls what instructions are present? If not, is that something we should plan for? Same goes for CSRs. Since everything in UDB is built around extensions, seems like I should be asking the extension for its instructions and CSRs.

BTW, I see this function below in the Extension class that calls arch_def.implemented_instructions. Seems like we should relax this to accept a partially defined arch_def too. Why don't we?

# @return [Array<Csr>] the list of CSRs implemented by this extension version (may be empty)
  def implemented_instructions(archdef)
    raise "should only be called with a fully configured arch def" unless archdef.fully_configured?

    return @implemented_instructions unless @implemented_instructions.nil?

    @implemented_instructions = archdef.implemented_instructions.select do |inst|
      inst.defined_by?(self)
    end
  end
end

[james-ball-qualcomm]

Waiting for Derek to refactor arch_def to have one Ruby object for everything possible in the RISC-V architecture standards and another Ruby object to have just what is in a particular configuration (whether configured, partially configured, or fully configured).