3
0

smallint.txt 1.5 KB

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