Embedded C compile size is bigger with int16's than with int32's. Why?

Question

I am working on embedded C firmware for Freescale Coldfire processors. After writing some code, I began to look at ways to reduce the size of the build. We are limited on space, so this is important for me to consider.

I realized I had several int32's in my code, but I only need int16's for them. To save space I tried replacing the relevant variables with int16's. When I built it, the size of the build went up by about 60 bytes.

I thought it might be how my structs were packed, so I defined how I wanted it packed, but it made no change.

#pragma pack(push, 1)
// Struct here
#pragma pack(pop)

I could kind of see it staying the same, but I can't figure what would cause it to go up. Any thoughts here? What might be causing this?

Edit:

Yes, looks like it was simply generating extra instructions to account for 32-bit being the optimized size for the processor. I should have checked the datasheet first.

This was the extra assembly being generated:

0x00000028  0x3210                   move.w   (a0),d1
0x0000002A  0x48C1                   ext.l    d1
; Other instructions between
0x0000002E  0x3028000E               move.w   14(a0),d0
0x00000032  0x48C0                   ext.l    d0**

Answer 1

Your compiler probably emits code for int32's just fine; it's probably the natural int size for your architectiure (is this true? Is sizeof(int)==4?). I am guessing that the size increase is from three places:

1. Making alignment work

   32-bit ints probably align naturally on the stack and other places, so typically code would not have to be emitted to make sure "the stack is 4 byte aligned". If you sprinkle a bunch of 16 bit ints in your code, it may have to add padding (extra adds to frame pointer as a fix-up?) Usually one add instruction covers the frame/stack maintenance, but maybe extra instructions are emitted to guarantee alignment.

2. Translating between 16-bit and 32-bit ints

   With 32-bit ints, most instructions naturally work. With smaller ints, sometimes the compiler has to emit code that chops/slices up bits so that it preserves the semantics of the smaller. (Maybe doing an extra AND instruction to mask off some high-order bits or an OR instruction to set some bits).

3. Going back and forth to memory

   Standard LOADS and STORES are for 32-bit ints (which is probably natural size of your machine). It's possible, that when it has to store only 2 bytes instead of 4, that the architecture has to emit extra instructions to store a non-standard int (either by chopping up the int, using a strange instruction that has a longer encoding, or using bit instructions to chop up the instruction).

These are all guesses. The best way to see is to look at the assembly code and see what's going on!

Answer 2

To save space I tried replacing the relevant variables with int16's. When I built it, the size of the build went up by about 60 bytes.

This doesn't make much sense to me. Using a smaller data type doesn't necessary translate to fewer instructions. It could reduce memory use when running the software but not necessarily build size.

So, for example, the reason using smaller data types here could be increasing the size of your binaries could be due to the fact that using smaller types requires more instructions or longer instructions. For example, for non-word/dword aligned memory, the compiler may have to use more instructions for unaligned moves. It may have to use special instructions to extract lower/upper words if all the general-purpose registers are larger. In that case, you might also get a slight performance hit in addition to the increased binary size using those smaller types (but less memory use when the code is running).

There may be a number of scenarios and it's specific to both the exact compiler you are using and architecture (the assembly code will reveal the exact cause), but in short, using smaller types for variables does not necessarily mean smaller-sized builds/fewer instructions, and could easily mean the opposite.