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 ?
because of insistence from so called professionals
Really? How do you know that?
There are, in Keil, many things, the use of which, is extremely deterimental to code running under this architecture and the only reason to include them must be demand from so called professionals that refuse to "work with the architecture". A true professional would make him/herself totally familiar with (the limitations created by) the architecture before touching the keyboard.
In much the same way a true professional would make himself totally familiar with the programming language before touching the keyboard, no?
I could make a list of such features, but do not want to start a mile long thread about very unique cases where it might be justified to work against the architecture;
Oh, but please do.
such decisions should, of course, only be made by a true professional totally familiar with the architecture.
I won't bother to reiterate.
Hi Jack,
Nice to see you back :)
OK, I have decided: I'm going to study C51 architecture so I can figure out myself who the villain here actually is :-). You see, I'm a sinner living in the 32 bit world (but you can do so many wonderful things in my realm- LCD control + networking + USB + room to spare, try the wonderful machine called LPC2478, and no, I don't work for NXP...). I guess only then I will understand what "wrestling something in the architecture" really means!
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.
Hans-Bernhard,
This is a most shocking revelation. I never thought an entire module would be affected by this.
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
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)
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
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
Well, that's a breakthrough. I'd have thought you'd aspire to be one of them, but there you go.