o a given resource within the chip-such as an IO device or an accelerator. Review the code generated by the compiler. As a final step in your optimization process, you could have the compiler output a listing of the assembly code it generated. There are some infrequent sets of circumstances that can prevent the optimizer from generating the most efficient code possible. Examine the assembly listing for extra moves and branches that could have been eliminated by the compiler but were not. In these rare cases, you may want to manually inline or try other implementations that might be more easily optimized. For example, it was found that by simply changing the return type of foo() from unsigned char to int reduced the number of instructions from 19 to 14 (see code example next). Different sized operands appear to have prevented the optimizer from producing more efficient code. int ext; void halt(); void printf (char *format static_inline_ signed char foo() if ( ext > 0) return 1; return 0; void start( if (foo() { printf ("pass"); else{ printf ("fail"); halt(); Reference [1] Intel Data Plane Development Kit (DPDK), https://www.intel.com/content/www/us/en/communications/ data-plane-development-kit.html This page intentionally left blank Interoperability and test This chapter gives an overview of steps involved in test (first) and interoperability (secondary) efforts for telecommunications equipment in general and Open Radio Access Network (O- RAN) products specifically. We focus on testing of central unit (CU), distributed unit (DU), and radio unit (RU), assuming split options 2 and 7.2. We cannot dictate an overall test strategy rather than to first provide a broad overview of common-sense testing strategies and then highlight key components in the area of testing that need to be covered for wireless telecommunications and/or O-RAN products. Testing is broadly separated between development testing which mostly owned by the development team and implemented during the software implementation phase to ensure that (small