On Tue, Mar 24, 2026 at 1:30 PM Matheus Bernardino <
matheus.bernardino@oss.qualcomm.com> wrote:

> On Mon, Mar 23, 2026 at 5:29 PM Taylor Simpson <ltaylorsimpson@gmail.com>
> wrote:
> >> +/*
> >> + * IEEE - FP Reduce instructions
> >> + */
> >> +uint32_t fp_vdmpy(uint16_t a1, uint16_t a2, uint16_t a3, uint16_t a4,
> >> +                  float_status *fp_status);
> >> +uint32_t fp_vdmpy_acc(uint32_t acc, uint16_t a1, uint16_t a2, uint16_t
> a3,
> >> +                      uint16_t a4, float_status *fp_status);
> >> +
> >
> >
> > Consider using macros similar to the ones in the .c file to create these
> protos.
>
> Hmm, I think in this case, the boilerplate size will outweight the
> benefit of the macros.
>

OK


> >
> > Do these instructions interact with the FP bits in USR (e.g., rounding
> mode, FP exceptions)?
>
> They do not. I'll add a new env->hvx_fp_status and use that for the
> default nan. This way we can avoid messing up with the scalar
> fp_status.
>

That will work for the nan.  Is there any programmer-visible state for
rounding mode or FP exceptions?

Thanks,
Taylor