Denys Vlasenko | 8f8ee53 | 2010-10-24 03:07:18 +0200 | [diff] [blame^] | 1 | smalluint i = index_in_str_array(params, name) + 1; |
| 2 | if (i == 0) |
| 3 | return 0; |
| 4 | if (!(i == 4 || i == 5)) |
| 5 | i |= 0x80; |
| 6 | |
| 7 | return i; |
| 8 | |
| 9 | I think that this optimization is wrong. |
| 10 | index_in_str_array returns int. At best, compiler will use it as-is. |
| 11 | At worst, compiler will try to make sure that it is properly casted |
| 12 | into a byte, which probably results in "n = n & 0xff" on many architectures. |
| 13 | |
| 14 | You save nothing on space here because i is not stored on-stack, |
| 15 | gcc will keep it in register. And even it is *is* stored, |
| 16 | it is *stack* storage, which is cheap (unlike data/bss). |
| 17 | |
| 18 | small[u]ints are useful _mostly_ for: |
| 19 | (a) flag variables |
| 20 | (a1) global flag variables - make data/bss smaller |
| 21 | (a2) local flag variables - "a = 5", "a |= 0x40" are smaller |
| 22 | for bytes than for full integers. |
| 23 | Example: |
| 24 | on i386, there is no widening constant store instruction |
| 25 | for some types of address modes, thus |
| 26 | movl $0x0,(%eax) is "c7 00 00 00 00 00" |
| 27 | movb $0x0,(%eax) is "c6 00 00" |
| 28 | (b) small integer structure members, when you have many such |
| 29 | structures allocated, |
| 30 | or when these are global objects of this structure type |
| 31 | |
| 32 | small[u]ints are *NOT* useful for: |
| 33 | (a) function parameters and return values - |
| 34 | they are pushed on-stack or stored in registers, bytes here are *harder* |
| 35 | to deal with than ints |
| 36 | (b) "computational" variables - "a++", "a = b*3 + 7" may take more code to do |
| 37 | on bytes than on ints on some architectires. |