unprivileged/integrated-matrix: Decouple psm=1 from RVBNA; require algorithm disclosure

[ptomsich]

The Zvvfmm arithmetic considerations previously defined psm=1 in terms of the RISC-V Bulk Normalization Algorithm (RVBNA), via a normative external link plus several paragraphs of RVBNA-parameter prose. This created a documentation dependency on a separate (still-being-finalised) spec and foreclosed any non-RVBNA-equivalent reduction.

Make psm=1 declaratory instead:

• psm=0 (unchanged): exact computation; bit-exact reproducible.
• psm=1 (rewritten): an implementation-defined non-exact reduction of the group's products. The IME spec does not prescribe any specific reduction algorithm. An implementation that supports psm=1 for a given (SEW, W, lambda) shall publish, alongside its (G, psm, rnd) disclosure, the specific reduction algorithm and the values of any parameters it takes. Two implementations are bit-exactly compatible at psm=1 only if both disclose the same algorithm with the same parameters.

The disclosure obligation is extended in line: each psm=1 entry must identify both the algorithm and its parameters. The reproducibility statement at the end of the section is tightened correspondingly -- 'same (G, psm, rnd) mapping AND, at any psm=1 entry, the same disclosed reduction algorithm and parameters.'

The previous RVBNA parameter prose (lines describing p, e, q, f, n and how Zvvfmm binds them) is collapsed into a single non-normative NOTE that:

• identifies RVBNA as a common psm=1 choice,
• sketches the standard parameter binding for implementors who choose RVBNA (n = G x W, q/f from output, p/e from input),
• explains the interaction between RVBNA's terminal round-to-odd and the IME rnd parameter, and
• confirms that other reductions (Kulisch-style accumulators, other bulk-normalised schemes with different parameter choices) are equally valid provided they are disclosed.

Drop the obsolete NOTE about 'RVBNA being augmented to handle asymmetric (mixed) data types; the Zvvfmm extensions will adopt that augmented definition' -- the IME spec no longer requires any specific RVBNA flavour, so this forward dependency is no longer needed.

Update the Zvtm-compatibility hint NOTE to specify 'psm=1 with RVBNA at the standard parameters described above', since psm=1 alone no longer implies RVBNA.

Update the SAIL helper fp_bna_add: keep the function name but rewrite its leading comment to reflect the new declaratory model -- the pseudocode leaves the operation abstract, and two implementations producing different numerical results may both be conforming provided each discloses its algorithm.

Net effect:

• The IME spec stands alone (no normative dependency on RVBNA or Zvdota).
• All previously conforming implementations remain conforming (they declare RVBNA with its standard parameters).
• Implementations using non-RVBNA reductions become legal.
• RVBNA's role as the recommended reference choice is preserved via the non-normative NOTE.

[efocht]

This is close to what I proposed at the beginning: having to disclose the method of summation without prescribing it. The psm=0 brings in an "exact" option, the psm=1 is the case offering freedom to implement. Text is clear now.

[joseemoreira]

This is clear, but I want to hold off a bit. The problem with "disclose an algorithm and parameters" is that it does not allow for automating a compliance test. RVBNA does (because it is spercific). Let us give the RVBNA team a chance.

[ptomsich]

This is clear, but I want to hold off a bit. The problem with "disclose an algorithm and parameters" is that it does not allow for automating a compliance test. RVBNA does (because it is spercific). Let us give the RVBNA team a chance.

In fact you can still automate the compliance test, as long as people either disclose only well-known algorithms or provide machine-readable/executable algorithm disclosures.

This is a downstream-problem from the Zvvm-specification and could (for example) be resolved by algorithms being disclosed as SAIL-code implementing the fp_bna_add function. Thinking about it a second time: it should be resolved by disclosing the implementation of fp_bna_add as SAIL-code.

[ptomsich]

Updated the PR to add non-normative language that recommends releasing a SAIL fragment for fp_bna_add to allow direct use of the disclosure in a certification program.

[joseemoreira]

It feels like "self-certification" to me. Let us wait a bit, please. I want to give the RVBNA team a chance to fix their problems.

[ptomsich]

It feels like "self-certification" to me. Let us wait a bit, please. I want to give the RVBNA team a chance to fix their problems.

It's machine-readable/executable disclosure. The certification is still done by a third party, but they reduction algorithm directly feeds into the certification process. It's no different to Common Criteria and the Security Target: the implementor states, within the constraints of the specification (or Protection Profile), what and how they implemented it — the lab still needs to certify.

[efocht]

This is an elegant solution. If we return to "psm=1 is RVBNA" then we just have one alternative. And we might wait for months to get SAIL code for that to make progress. The whole point of the PR is to break a dependency which we didn't need anyway. Let's accept this PR and, if some time later, during the process, RVBNA turns up with SAIL code (which would be unexpected), we do another PR mentioning it as one possible psm=1 option.

[joseemoreira]

We need to work this through. "Anything goes" for "psm=1" is too permissive, even more so that the current vector unordered sum. There are many people (and companies) with a vested interested in getting this RVBNA issue resolved. We can let them work on that. I am happy to hear alternatives between "psm=1 is RVBNA" and "psm=1 is anything goes".

[ptomsich]

You readlly want to block IME on RVBNA and whatever timeline it will have to complete?
Given that they will have to start adding the microscaling support and that there are no dedicated SAIL and ACT resources to back its completion, it simply isn't ready today and unlikely to complete in the near term.

Two observations:

• psm=1 already is close to an 'anything goes', as the parameters (together with G and the rounding-mode) leave many degrees of freedom
• allowing a permissive model for declaring the reduction algorithm is very much manageable, as downstream specifications (profiles?) can further constrain (including mandating RVBNA)

[efocht]

We looked at this a bit and my personal opinion is that it is far less probable to see implementions or RVBNA in IME than binary adder trees. I might, of course, overlook something. But there are reasons for this. IME is simpler for higher rank updates, if you do multiprecision MACs, you will have to deal with a variable number of summands per data path. In order to fit those into an efficient RVBNA with 4 elements (2 are uninteresting, that's just a normal adder) you will need 4 full adders in front of the RVBNA and a comparator which detects the largest exponent among 4 elements. That's only efficient if you have exactly 4 summands, with any precision. That is the choice for VME, but not for IME. For IME your number of elements will vary with the widening, and then you pay for the full adders and the large comparator.