Open sdoehla-iis opened 1 year ago
Signalogic has published a BASOP upgrade proposal. As a non-member we can't upload the doc to the ITU site so we have posted it on our STL Github fork:
https://github.com/signalogic/STL/blob/dev/doc/Signalogic_ITU_Non-Member_SG12_BASOPS_Upgrade.pdf
@signalogic @sdoehla-iis @ErikNorvell-Ericsson, would you be able to give us an update on how things are going on this issue?
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 https://github.com/openitu/STL/pull/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 https://github.com/openitu/STL/pull/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.