o something someOtherGlobal = something. Make conditionals as specific as possible. If a variable "x" is an unsigned integer (int32u) and it has to be checked for the value being less than a variable "n", the conditional test could be coded as: "if (x < n)." The conditional does not need to test that (x>=0) since that condition should be met by the definition of the variable. In an example we came across, on examination of the assembly language, it was found that by encoding the conditional as "if (x 0 && x < n)," the optimizer was able generate code that was 4 cycles faster than the "if (x < n)" implementation. Avoid volatile declarations wherever possible. Use the "volatile" construct only on control, I/O and other addresses that change asynchronously by hardware or have side effects when read. A volatile variable or field cannot be promoted to a register, cannot be eliminated, cannot be part of a common subexpression, etc. As a result, every reference to a volatile variable generates a load or a store. If you load a volatile field and know that it cannot change because of some other semaphore (i.e., "avail" bit says you own it) copy the field into a local variable and reference the local copy instead. Avoid function calls where possible. Function calls require cycles to set up the arguments and the stack SO should be avoided when possible. This can be done by putting the code inline, or by using the "inline" directive for functions to have the compiler, insert a copy of the code. Care should be taken with this, however, since it can increase the amount of instruction memory used. Function calls can also cause shared instruction memory stalls, further slowing performance. Avoid function calls with many arguments. Famously, in the MIPS/Arm processor architectures, the first four arguments are passed in registers and can be referenced directly. For x86-64 Linux, the number is six. All arguments after this have to be marshaled into memory and are accessed indirectly through a pointer in the called routine. This ta