5.5.6 What are the Speed vs. Size Tradeoffs?

Microchip's dsPIC architecture is primarily a 16-bit architecture. It is often less run-time efficient to use 8-bit values as the compiler may have to extend the value to use it. There are times when this will save data space, but not always. See the items below to help you make your code faster, smaller, or both.

• Array index variables and pointer offsets should always be defined as an integer sized type; size_t is often a good choice. A different sized integer type will require the compiler to do a conversion at run-time.
• Automatic variables (function local variables) will often be allocated into a register at compile time. A register is a minimum of 16 bits wide, so using a smaller type can require the compiler to generate extra code. Therefore, unless 8-bit overflow rules are required, use 16-bit types instead. Also, the stack has alignment restrictions, making stack accesses for smaller type objects possibly less efficient.
• Argument transmission (parameter passing) either happens in registers or on the stack. Reduce the chance of generating conversions by avoiding the use of smaller than 16-bit objects.
• Objects that are defined at File scope, or function static scope, will consume less space if defined as 8-bit typed objects. Be aware that data sections are aligned to 16 bits, so using named sections, or one of the other attributes that might require a new section, may not provide the data size savings that are desired.
• MPLAB XC16 is free to reorder objects in File scope or automatic scope, but it is not allowed to re-order structure members. Unless a pre-defined interface is being conformed to, try to allocate structure members to group similarly-sized objects together, with bit-fields especially being grouped together. This will reduce the number padding-bytes that may be inserted to maintain alignment requirements.