• State Not Answered
  • Locked Locked
  • Replies 23 replies
  • Subscribers 22 subscribers
  • Views 5198 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

C51 v8.17 saving/restoring all registers in interrupt function with assembly src

Eckhard Tikwinski

C51 will generate different code for the following function:

void timer1 (void) interrupt 3 {
    second;
#pragma asm
    clr    TF1
#pragma endasm
}


Compiler v8.08 code (edited)

    USING    0
timer1:
; #pragma asm
    clr    TF1
; #pragma endasm
    RETI


Compiler v8.17 code (edited)

    USING    0
timer1:
    PUSH     ACC
    PUSH     B
    PUSH     DPH
    PUSH     DPL
    PUSH     PSW
    MOV      PSW,#00H
    PUSH     AR0
    ...
    PUSH     AR7
    USING    0
; #pragma asm
      clr    TF1
; #pragma endasm
    POP      AR7
    ...
    POP      AR0
    POP      PSW
    POP      DPL
    POP      DPH
    POP      B
    POP      ACC
    RETI


C51 v8.17 generates code to save and restore all registers, as soon as the (very simplified, nonsense) C function contains any assembly source, whereas C51 v8.08 does not. For a function containing equivalent C code only (TF=0), nothing would be saved with either version.

Is there a reason for the different code generated by v8.17 ? How could saving/restoring of the registes be avoided ?

Parents
  • 0 in reply to Tamir Michael

    OK, I have decided: I'm going to study C51 architecture so I can figure out myself who the villain here actually is :-).

    Well, let me put it like this: Keil's implementation of inline assembly (last I looked) is sufficiently half-baked to suggest that they didn't really bother to design it carefully. To mention just one major show-stopper: a single inline assembly fragment in a source file kills debug information for that entire module. And it disables a considerable subset of available optimizations --- again, for the entire module. Judging by what throwing one into the compiler's works causes, it should not be called "#pragma asm" but rather "#pragma monkey_wrench".

    Which begs the question: if they didn't plan on doing it properly, why do it at all? There had to be some reason to spend money on the existing implementation, and among the more plausible ones that come to mind is that some customers out there (or their beancounting departments) may be shopping for tools strictly by bullet point list, without a care in the world whether those features can actually be used productively. I.e. maybe Keil thought they could not afford not having that "inline assembly support: [X]" point checked on their fact sheet.

Reply
  • 0 in reply to Tamir Michael

    OK, I have decided: I'm going to study C51 architecture so I can figure out myself who the villain here actually is :-).

    Well, let me put it like this: Keil's implementation of inline assembly (last I looked) is sufficiently half-baked to suggest that they didn't really bother to design it carefully. To mention just one major show-stopper: a single inline assembly fragment in a source file kills debug information for that entire module. And it disables a considerable subset of available optimizations --- again, for the entire module. Judging by what throwing one into the compiler's works causes, it should not be called "#pragma asm" but rather "#pragma monkey_wrench".

    Which begs the question: if they didn't plan on doing it properly, why do it at all? There had to be some reason to spend money on the existing implementation, and among the more plausible ones that come to mind is that some customers out there (or their beancounting departments) may be shopping for tools strictly by bullet point list, without a care in the world whether those features can actually be used productively. I.e. maybe Keil thought they could not afford not having that "inline assembly support: [X]" point checked on their fact sheet.

Children