Strange assembly from array 0-initialization

Question

Inspired by the question Difference in initalizing and zeroing an array in c/c++ ?, I decided to actually examine the assembly of, in my case, an optimized release build for Windows Mobile Professional (ARM processor, from the Microsoft Optimizing Compiler). What I found was somewhat surprising, and I wonder if someone can shed some light on my questions concerning it.

These two examples are examined:

byte a[10] = { 0 };  byte b[10]; memset(b, 0, sizeof(b)); 

They are used in the same function, so the stack looks like this:

[ ] // padding byte to reach DWORD boundary [ ] // padding byte to reach DWORD boundary [ ] // b[9] (last element of b) [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] // b[0] = sp + 12 (stack pointer + 12 bytes) [ ] // padding byte to reach DWORD boundary [ ] // padding byte to reach DWORD boundary [ ] // a[9] (last element of a) [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] // a[0] = sp (stack pointer, at bottom) 

The generated assembly with my comments:

; byte a[10] = { 0 };  01: mov   r3, #0        // r3 = 0 02: mov   r2, #9        // 3rd arg to memset: 9 bytes, note that sizeof(a) = 10 03: mov   r1, #0        // 2nd arg to memset: 0-initializer 04: add   r0, sp, #1    // 1st arg to memset: &a[1] = a + 1, since only 9 bytes will be set 05: strb  r3, [sp]      // a[0] = r3 = 0, sets the first element of a 06: bl    memset        // continue in memset  ; byte b[10]; ; memset(b, 0, sizeof(b));  07: mov   r2, #0xA      // 3rd arg to memset: 10 bytes, sizeof(b) 08: mov   r1, #0        // 2nd arg to memset: 0-initializer 09: add   r0, sp, #0xC  // 1st arg to memset: sp + 12 bytes (the 10 elements                         // of a + 2 padding bytes for alignment) = &b[0] 10: bl    memset        // continue in memset 

Now, there are two things that confuses me:

1. What's the point of lines 02 and 05? Why not just give &a[0] and 10 bytes to memset?
2. Why isn't the padding bytes of a 0-initialized? Is that only for padding in structs?

Edit: I was too curious to not test the struct case:

struct Padded {     DWORD x;     byte y; }; 

The assembler for 0-initializing it:

; Padded p1 = { 0 };  01: mov   r3, #0 02: str   r3, [sp] 03: mov   r3, #0 04: str   r3, [sp, #4]  ; Padded p2; ; memset(&p2, 0, sizeof(p2));  05: mov   r3, #0 06: str   r3, [sp] 07: andcs r4, r0, #0xFF 08: str   r3, [sp, #4] 

Here we see in line 04 that a padding indeed occur, since str (as opposed to strb) is used. Right?

Answer 1

The reason for lines 2 and 5 is because you specified a 0 in the array initializer. The compiler will initialize all constants then pad out the rest using memset. If you were to put two zeros in your initializer, you'd see it strw (word instead of byte) then memset 8 bytes.

As for the padding, it's only used to align memory accesses -- the data shouldn't be used under normal circumstances, so memsetting it is wasteful.

Edit: For the record, I may be wrong about the strw assumption above. 99% of my ARM experience is reversing code generated by GCC/LLVM on the iPhone, so my assumption may not carry over to MSVC.

Answer 2

Both bits of code are bugfree. The two lines mentioned aren't smart, but you're just proving that this compiler is emitting suboptimal code.

Padding bytes are usually only initialized if that simplifies the assembly or speeds up the code. E.g if you have padding between two zero-filled members, it's often easier to zero-fill the padding as well. Also, if you have padding at the end and your memset() is optimized for multi-byte writes, it may be faster to overwrite that padding too.