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

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
  • OK, I have decided: I'm going to study C51 architecture so I can figure out myself who the villain here actually is :-).

    there is no villain but the user (or chooser)
    if the user do not know the implications of using a 'feature' (s)he is at fault for using it
    if the chooser (of microcontroller type) does not make sure that the required features are available in the choice (s)he is at fault for choosing it

    NOW, ever so often, the fault is at the user because the required functiobality could easily be implemented in the choice withou any deterimental effects, just not by the "first thought" but by a different technique beneficial to the architecture/compiler.

    NOW, of course there is the "I am important, the product is not" group (e.g. "Jack Sprat") that will insist "if it is defined in C I do not care if the processor is inefficient doing it".

    Erik

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

    there is no villain but the user (or chooser)
    if the user do not know the implications of using a 'feature' (s)he is at fault for using it
    if the chooser (of microcontroller type) does not make sure that the required features are available in the choice (s)he is at fault for choosing it

    NOW, ever so often, the fault is at the user because the required functiobality could easily be implemented in the choice withou any deterimental effects, just not by the "first thought" but by a different technique beneficial to the architecture/compiler.

    NOW, of course there is the "I am important, the product is not" group (e.g. "Jack Sprat") that will insist "if it is defined in C I do not care if the processor is inefficient doing it".

    Erik

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

    there is no villain but the user (or chooser)

    <another episode of 'Completely Missing The Point' snipped>

    Another day aboard the starship 'Confusing Exercise':

    Crank the debugger up to warp 9, Scotty, we're about to start coding.

    Och, but Captain, she cannae tak it! Can we nae use the Standard instead?

    Afraid not, Scotty, we've always flown by the seat of our pants in this ship and we're not about to change now.

    <sighs> Aye aye, Captain.

  •  * 5A3266E3-82B2-4DCB-8A0C-23BE1236021C throws a handful of sawdust on the combatants in hope thatthey will quickly forget the imminent fight and instead start cleaning their pelts.

  • self proclaimed villain,

    I'm sure most of the sensible comments on this forum escape your wit. but don't worry, it will come, in time.

    p.s.

    are you a trekkie?

  • that the '51 architecture is not fully capable of peocessing all C constructs in an effective manner evidently, in the opinion of a certain sardine, makes the processor the villian.

    Erik (NOT hiding behind a monmniker)

  • that the '51 architecture is not fully capable of peocessing all C constructs in an effective manner evidently, in the opinion of a certain sardine, makes the processor the villian.

    Again you completely, and probably deliberately, miss the point.

    The point is that a professional engineer should read the manual - a point you yourself make with tiresome regularity. Reading the manual in the context of the programming language that you (yes, *you*) use means reading the 'C' standard or some alternative reference that describes the 'C' language as defined by the 'C' standard, such as H&S (Harbison and Steele).

    Now, you'll argue that you don't use standard 'C' but in fact use Keil 'C' therefore the 'C' standard is irrelevant to you and your reference is the Keil documentation. This argument is false - Keil's job is to document what their implementation adds to standard 'C', not to document the standard 'C' part of their implementation which forms the majority of the source code you type into your text editor.

    The sooner you manage to understand this the sooner you will hopefully do something about it. Once you've done something about it you'll find that you spend far less time debugging and far more time producing working code.

    Your repeated implication that learning the 'C' programming language properly somehow makes one unable to write code that is suitable for use on an 8051 derivative is frankly laughable, the reality is that *not* learning the language renders one unfit to write code for *any* architecture.

  • Now, you'll argue that you don't use standard 'C' but in fact use Keil 'C'
    IN CONTEXT:
    1) NOT Keil C" but "'51 C"
    2) 'standard C has many 'features' that the '51 is inacabable of processing efficiently and such constructs should thus be avoided.

    Your repeated implication that learning the 'C' programming language properly somehow makes one unable to write code that is suitable for use on an 8051 derivative is frankly laughable
    If you did not know C you would be at a loss using Keil C. I do not discuss 'learning' or 'knowing' but 'applying'
    I have never stated "that learning the 'C' programming language properly somehow makes one unable to write code", what I have stated and will restate is that "if you approach '51 programming with the attitude "I am using C so I do not need to be concerned with the archiotecture" your ability to make efficient code is not even that of a sardine

    Erik

  • IN CONTEXT:
    1) NOT Keil C" but "'51 C"

    There is standard 'C' of which there are implementations, many of which include extensions to the standard. '51 C' is merely a figment of your imagination.

    2) 'standard C has many 'features' that the '51 is inacabable of processing efficiently and such constructs should thus be avoided.

    In your opinion, perhaps. Efficiency (by which I assume you mean speed and/or code size) is only relevant if it matters, otherwise clarity and maintainability should take precedence.

    As you're so very fond of them, here's a car analogy:

    You need to drive somewhere 100 miles away. You need to be there in 6 hours. Do you:

    1) Drive at a sensible speed and get there in plenty of time.
    2) Drive flat out and get there way too early.

    If you did not know C you would be at a loss using Keil C. I do not discuss 'learning' or 'knowing' but 'applying'

    You cannot 'apply' without first 'learning' and hopefully 'knowing'. I can only judge your state of knowledge by what you post on this forum, and I'm afraid your code snippets and queries along with your comments on the 'C' language betray a worrying lack of it.

    I have never stated "that learning the 'C' programming language properly somehow makes one unable to write code",

    Ah yes, the old 'Malund trick', snipping the important bit of the quote:

    Your repeated implication that learning the 'C' programming language properly somehow makes one unable to write code that is suitable for use on an 8051 derivative

    Which is, in fact, what you repeatedly imply. Don't you even have your own little nickname for people who know 'C' well?

    what I have stated and will restate is that "if you approach '51 programming with the attitude "I am using C so I do not need to be concerned with the archiotecture" your ability to make efficient code is not even that of a sardine

    Er, fascinating, but not what is being discussed. That's 'Malund trick 2', number three, if I recall, will be answering the question you would prefer to have been asked rather than the one you have been asked.

  • Woohoo.

    Go Jack, go Jack, gooooooooooooo Jack!

  • Which is, in fact, what you repeatedly imply. Don't you even have your own little nickname for people who know 'C' well?
    Not that I know of, I would call them knowledgeable.

    HOWEVER "if you approach '51 programming with the attitude "I am using C so I do not need to be concerned with the archiotecture" I call you a Cidiot

    Erik

  • Which is, in fact, what you repeatedly imply. Don't you even have your own little nickname for people who know 'C' well?
    Not that I know of, I would call them knowledgeable.

    Well, that's a breakthrough. I'd have thought you'd aspire to be one of them, but there you go.