Remove global flags under BASOP_NOGLOB #173
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
ITU-T’s basic operators inside the STL (G.191) are the basis of speech coding standards, offering a complete set of operators of relevance for embedded fixed-point implementations. A deficit however is the use of global variables that leads to diverging implementations to satisfy current best practices in software development for thread-safe and portable implementations. This contribution addresses this aspect, triggered by 3GPP’s needs for a set of operators without this deficit and a recent pull request for STL in the Open ITU Github project. This is also described in ITU-T contribution SG12-C-0170.
This pull request implements the removal of global flags, similarly to #171 , but based on the code that has been developed as part of the IVAS development work (see https://forge.3gpp.org/rep/ivas-codec-pc/ivas-codec for details on IVAS).
A prior version of this been integrated into the IVAS floating-point code (now standardized as 3GPP TS 26.258, available here: https://www.3gpp.org/dynareport/26258.htm ). This version has been a rewrite that is fully compatible to the code already in IVAS, but covering all operators that are available in STL2023. This version is an in-place modification (differing from #171 that adds extra files), which could break software that relies on those operators if they would now use the here proposed version. This is for the reason that:
Software that does not trigger the Overflow or Carry flags would not be affected, other software would need some adaptations, as an example, the add operator would be complemented with a new variant allowing overflow to be signalled explicitly via a supplied variable. Here the name is amended with a suffix “_o” for “overflow”.
The original operator
Word16 add (Word16 var1, Word16 var2);
is complemented with an assert, such that execution halts in debugging variants when an overflow is triggered.The benefit is that developers would be made fully aware of when an overflow occurs, instead of going undetected as in the existing STL BASOP. If an overflow is foreseen, the variant which allows overflows shall be used instead. The behavior of the original operator would otherwise remain identical in release builds, just without setting of the Overflow flag or Carry flag.
it should be noted that G.722 as part of STL was also adapted. It uses the BASOPs and also triggered Overflows at four places in the code. Further verification on a large data set would be desirable.
The pull request also tackles the
exit()
calls to some extent, but it is at this stage undecided what a reasonable approach to tackle those is. In case of undefined behaviour (division by zero) currentlyabort()
is used. This may still be changed further to e.g. callexit(136)
to indicate SIGFPE (which despite the name is also raised for divisions) or some other indication that there is undefined behaviour and the application is thus in an undefined state that normally requires abort.