Re: [avr-gcc-list] Instruction count

[Joerg Wunsch]

Anubhav <address@hidden> wrote:

(Btw., i'd appreciate seeing a real name instead.  That's a bit of
politeness to me.  Maybe i'm biased, German Usenet generally insists
on real names, otherwise you don't get answers at all.  Being in
critizism mode, please don't add a full quote to the bottom of your
mail.)

> Had expected the atmega128 to have the larger binary
> since its a 8 bit CPU and therefore should take more
> than four times as many instructions as on the 32 bit
> intel cpu but the avr executables are approximately 3
> times smaller than intel ...

What makes you think so?  There are several things to notice:

. AVR uses 16-bit "int" datatype by default, IA32 uses 32-bit "int";
  so unless all your data declarations use explicit types from
  <inttypes.h> like uint8_t, int32_t etc., you're comparing apples and
  oranges.  If you'd really use 32-bit integer computation on the AVR
  (blindly, even where not necessary), the AVR program size would
  suddenly explode.  Not only that it has to use more instructions to
  encode this, you'll also blow a good number of registers so stack
  usage will drastically increase, both for saving registers as well
  as for local variables (which will in turn bloat the code again
  since stack memory access requires more effort than register
  access).  OTOH, on IA32 if you declare variables where the size
  doesn't really matter (like a loop index ranging from 0 to 10 or so)
  as an explicit type like int8_t, you'll waste space there by leaving
  the natural size of the target machine, so additional instructions
  might be needed to `pad' the unused 24 bits of a register (or to
  sign-extend the value).

. AVR has a fixed instruction length of 16 bits for most instructions
  (they call it RISC although it's not RISC in the strictest sense),
  except 24 bits on the larger cores (like your ATmega128) for the
  intra-function jumps/calls.  IA32 has a variable instruction length,
  i think the smallest instruction is just only 8 bits, the largest
  one i just don't know.

. Since IA32-machine memory busses are organized 64 bits wide these
  days, compilers usually pad jump targets to 64 bit boundaries since
  this will speed up instruction fetching; after a jump, only a single
  memory word needs to be read then as opposed to reading two words in
  order to assemble the first instruction.  This padding obviously
  wastes space, but memory on IA32 is considerably cheaper than it is
  on the AVR.

. Which sizes are you comparing, anyway?  Just the file size of the
  ELF file?  You could as well compare 42 instead. ;-)  If at all,
  please use avr-objdump -h.  (It'll usually also be able to dump
  the ELF headers of an ELF file on your host, even though it could
  not possible also disassemble that file.)

. Whether shared library usage actually decreases the amount of memory
  used depends on the size of the program.  There's a good bit of
  initial overhead for the shared lib model (the program startup code
  needs to locate and mmap() the shared libs into virtual memory, and
  setup the jump tables accordingly), and there's an additional jump
  table, so small programs might even be larger with shared libs than
  they are with static linkage.  (In any case, shared programs are
  slower.)

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/
avr-gcc-list at http://avr1.org