-
Notifications
You must be signed in to change notification settings - Fork 13
Description
I've encountered several places where I'd like to use a function, for example vect_s32_dot(), where an int64_t is returned, but where I'd really like to have an int32_t. vect_s32_dot_prepare() determines the necessary shifts and output exponent assuming a 64-bit output (really ~40 bits because of the VPU accumulators), and so it isn't safe to simply dump the output into an int32_t.
However, vect_s32_dot_prepare() could take a bit-depth parameter that tells it what the maximum scale for the output is. And then, even though it still returns int64_t, you could immediately dump that into an int32_t and not worry about overflows.
This mostly applies to the vector functions which return a scalar, like dot product, energy calculation, sums, etc.
I'm not sure there's a good way to allow the BFP API to take advantage of this unless e.g. bfp_s32_dot() also takes a bit-depth parameter.
I could backwards compatibility issues (and thus avoid a major version bump) creating a new prepare function and use a macro to map the old one with a default parameter.