On 2/4/26 15:17, Max Chou wrote:
This commit provides the implementation defined behavior flags and the basic
operation support for the OCP float8 data types(E4M3 & E5M2).
I'd really like to see this split into parts. Beginning with
@@ -542,11 +549,39 @@ typedef struct {
int exp_max;
int frac_size;
int frac_shift;
- bool arm_althp;
bool has_explicit_bit;
uint64_t round_mask;
+ /*
+ * Format capability flags:
+ * no_infinity: Format has no infinity encoding. When true, exp=exp_max
+ * with frac=0 is NOT infinity - it's either NaN or max normal.
+ *
+ * limited_nan: Format has limited or no NaN patterns. When combined
+ * with normal_frac_max, determines NaN encoding capability:
+ * - limited_nan=false: Standard IEEE NaN (exp=exp_max, frac!=0)
+ * - limited_nan=true && normal_frac_max!=0: Limited NaN (E4M3)
+ * - limited_nan=true && normal_frac_max==0: No NaN encoding (AHP, E2M1)
+ *
+ * overflow_raises_invalid: Raise Invalid (not Overflow) exception.
+ * ARM Alt HP uses this to signal overflow as an invalid operation.
+ *
+ * normal_frac_max: For formats with limited_nan, the maximum fraction
+ * value (after normalization shift, including implicit bit) that is
+ * still considered normal at exp=exp_max.
+ * Use NORMAL_FRAC_MAX_ALL (0) to indicate all frac values at exp_max
+ * are normal (E2M1, ARM Alt HP), which also implies no NaN encoding.
+ */
+ bool no_infinity;
+ bool limited_nan;
+ bool overflow_raises_invalid;
+ uint64_t normal_frac_max;
} FloatFmt;
... this. I wanted to say something about this vs previous revisions, but I hadn't had
anything coherent to say besides "meh".
In particular, I think separating "no_infinity" and "limited_nan" leads to confusing
checks, such as the one in parts_canonicalize where you test "limited_nan" in a context
that is really testing for overflow to infinity.
Further, normal_frac_max is defined oddly, such that you have to test it twice, once vs
frac_hi and once vs NORMAL_FRAC_MAX_ALL. Since this is used for exactly one format, this
is perhaps trying to be overly general.
I think better might be:
typedef enum {
/* exp==max, frac==0 ? infinity : nan; this is ieee standard. */
float_maxexp_ieee,
/* exp==max is a normal number; no infinity or nan representation. */
float_maxexp_normal,
/* exp==max, frac==max ? nan : normal; no infinity. */
float_maxexp_e4m3,
} FloatFmtMaxExp;
We can stage in this behaviour without also including either FP8 format.
Just changing Arm althp in a separate patch is large enough.
r~
