Add spec to FP Computational and Conversion Instructions

[sudo-abdullah]

This PR adds missing long_name and description to some FP Computational and remaining FP Conversion Instructions.

[AFOliveira]

Great work!

Just a couple things to go:
Saying instruction in the instruction name seems clearly a no-go. Please remove from all the instructions long-names.

About the 64-bit vs Long, I think it's better to define long, but other reviewers may differ opinion.

[AFOliveira]

I don't think this is a requirement to enter, but since you specified, I believe all of this is normative text.

BTW, Normative text specifies the binding rules and requirements that implementations must follow (using terms like “MUST,” “SHALL,” or “SHOULD”), whereas non-normative text is purely informational—providing background, examples, rationale, or guidance without imposing any mandatory obligations on implementers. Normative clauses form the “contract” of a specification, and violating them means non-compliance, while non-normative sections merely aid understanding and carry no compliance weight.

[sudo-abdullah]

Let’s see what @ThinkOpenly suggests too

[ThinkOpenly]

To my understanding, you have a lot of the "from" and "to" types reversed. I've suggested new text that reads better left-to-right with the mnemonic string and reverses those types.

[AFOliveira]

Aren't all the descriptions normative?

[sudo-abdullah]

Aren't all the descriptions normative?

As per @ThinkOpenly's guidance :
Only descriptions that are exact matches to normative spec text should be marked as normative: true.
Paraphrased or simplified descriptions, even if accurate, should not be marked normative.

[ThinkOpenly]

Only descriptions that are exact matches to normative spec text should be marked as normative: true. Paraphrased or simplified descriptions, even if accurate, should not be marked normative.

That was my understanding at the time. I've since heard that what is actually ratified is not the text per-se, but the meaning of the text, so there is some flexibility with actual wording.

That being said, I don't think we want to spend a lot of effort at this point fussing over wording and whether text is normative or not. Some meaningful text is helpful. Trying to be consistent is a good goal. Correctness is paramount.

I expect there will be a future (substantial) effort to rectify text.

[ThinkOpenly]

Suggested change

	encodes the datatype of the source, and the _fmt field encodes the datatype of the destination.
	encodes the datatype of the source, and the `fmt` field encodes the datatype of the destination.

[ThinkOpenly]

There's a typo here "unsignedn", but this sentence can be removed entirely, as it doesn't really apply to this particular instruction.

[ThinkOpenly]

For consistency, we need to either use "Long" or "Long integer". Let's use just "Long" everywhere.

[ThinkOpenly]

Suggested change

	long_name: Floating-point Convert short to Half-precision
	long_name: Floating-point Convert Word to Half-precision

[ThinkOpenly]

Suggested change

	long_name: Floating-point Convert unsigned short to Half-precision
	long_name: Floating-point Convert Unsigned Word to Half-precision

[AFOliveira]

Only descriptions that are exact matches to normative spec text should be marked as normative: true. Paraphrased or simplified descriptions, even if accurate, should not be marked normative.

That was my understanding at the time. I've since heard that what is actually ratified is not the text per-se, but the meaning of the text, so there is some flexibility with actual wording.

That being said, I don't think we want to spend a lot of effort at this point fussing over wording and whether text is normative or not. Some meaningful text is helpful. Trying to be consistent is a good goal. Correctness is paramount.

I expect there will be a future (substantial) effort to rectify text.

Just to clarify—“normative” and “ratified” are completely unrelated terms, right? In my understanding, ratified should simply indicate whether something has gone through the ratification process, not describe the nature of its content.

[ThinkOpenly]

“normative” and “ratified” are completely unrelated terms, right? In my understanding, ratified should simply indicate whether something has gone through the ratification process, not describe the nature of its content.

IMHO, I see a "ratified" specification as describing compliant behavior/implementation, and the "normative" text therein as that which must be followed to be compliant. So, to me, they are related.

(I'm content at this point to let correct text get merged, absent glaring omissions. Verbatim spec content is nice, but not required, and also difficult to contextualize when extracted. My criteria is "good enough". The text battles come later.)

[dhower-qc]

(I'm content at this point to let correct text get merged, absent glaring omissions. Verbatim spec content is nice, but not required, and also difficult to contextualize when extracted. My criteria is "good enough". The text battles come later.)

Agreed; I'm assuming there will be a deep pass of all text down the road, so it's not critical at this point.