This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

What optimizations should be expected from a C compiler for small uPs?

My knowledge of current compiler optimization technology is very limited (or ancient).
Am familiar with VHDL and Verilog for FPGA chips where extreme optimization is typical (dead code removal, code duplication to meet performance constraints, morphing from the language constructs into available hardware constructs).

In the context of the large variety of small microprocessors (of 8, 16 or 32 bits), each with unique peripheral collections; what would raise the coding to higher levels of abstraction, given one is still dealing with IO ports and peripherals?

Parents Reply Children
  • What is a rapple?

    incomplete erasute of RE: fololowed by 'apple'

  • It would be unlikely for a compiler to recognize particular idioms for the bitwise operators and turn those into bit instructions. In theory, the compiler could see

    P1 = P1 | 0x01;

    and notice that P1 was bit addressable, the net effect is just to set one bit, and generate the appropriate SETB instruction. In practice, I wouldn't expect it. If I write |= 0x3, |= 0x7, |= 0x55, etc, when does the compiler switch to a byte write instead of a series of SETB's?

    I can imagine it's even a good idea not to use the bit operations, just to leave the programmer the flexibility to code either the byte-wide operation or the bit-wise one as he chooses. There's no guarantees there, of course. That leads us to the realm of a #pragma so that the programmer can choose the implementation of the C statement.

    There might be a better argument for bitfields that are one bit wide. Generated code for bitfields is usually bad (in my past experience) which leads to a vicious cycle of the language construct being ignores, which leads to it not being particular well supported and optimized.

  • Generated code for bitfields is usually bad (in my past experience) which leads to a vicious cycle of the language construct being ignores, which leads to it not being particular well supported and optimized.
    I wholehardedly agree re the bitfields discussed in a C book; however I totally disagree re SFR bits. There is no way to make that "implemntation dependent" and thus what you say above do not apply.

    Erik

  • "It would be unlikely for a compiler to recognize particular idioms for the bitwise operators and turn those into bit instructions ... when does the compiler switch to a byte write instead of a series of SETB's?"

    See: http://www.keil.com/forum/docs/thread11894.asp

  • I wouldn't be surprised to find that it involves at least some relation to the price of the compiler...