We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello,
1.when i use printf with no var_args then the compiler should call puts instead of printf.
ex1:
#include <REGX51.H> #include <stdio.h> void main(void) { printf("This must call puts instead of printf"); }
Program Size: data=30.1 xdata=0 code=1103
ex2:
#include <REGX51.H> #include <stdio.h> void main(void) { puts("This must call puts instead of printf"); }
Program Size: data=9.0 xdata=0 code=168
The above code links the printf function from the library which is huge(produces 1103 bytes).But the compiler can use puts when there is no var_args given which is much smaller than printf(produces 168 bytes).
2.The Compiler must find and remove the duplicate constant strings
ex3:
#include <REGX51.H> #include <stdio.h> void main(void) { puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); puts("This string gets duplicated as many time as i use it"); }
Program Size: data=9.0 xdata=0 code=334
ex4:
#include <REGX51.H> #include <stdio.h> void main(void) { puts("This string gets duplicated as many time as i use it"); }
Program Size: data=9.0 xdata=0 code=183
3.Bit Test instructions are not used when i actually test for the bit
ex5:
#include <REGX51.H> #include <stdio.h> void main(void) { if(P0^1) { P1 = 10; } } ASSEMBLY LISTING OF GENERATED OBJECT CODE ; FUNCTION main (BEGIN) ; SOURCE LINE # 6 ; SOURCE LINE # 7 ; SOURCE LINE # 8 0000 E580 MOV A,P0 0002 6401 XRL A,#01H 0004 6003 JZ ?C0002 ; SOURCE LINE # 9 ; SOURCE LINE # 10 0006 75900A MOV P1,#0AH ; SOURCE LINE # 11 ; SOURCE LINE # 13 0009 ?C0002: 0009 22 RET ; FUNCTION main (END)
In the above assembly output it should have used a single instruction JNB instead of three MOV,XRL and JZ.This is very basic anybody would object the assembly code produced.
I have not used the compiler much.But the compiler needs a look by the programmers at keil.
The above programs were all compiled with compiler optimisation level set to 9 & favour speed.
About 5 years back i compiled a c51 source code using keil. Now i recompiled the same source code with the latest compiler from keil and compared the two output .hex files. Unfortunately it produced exactly the same output.Here i was expecting some code and data size reduction as the compiler must be capable of optimising more.
It seems there was no improvement on the compiler side.
It is not a complaint but in the interest of improving the compiler.
regards,
S.Sheik mohamed
But P0 is a volatile 8-bit variable. And the language standard requiers that the compiler does perform the volatile access. So the compiler can't do a single-bit access to a bit variable that just _happens_ to be aliased to one bit of the 8-bit P0 special function register. The compiler _must_ do the full 8-bit read of P0. Then it can use its optimization abilities to convert (x & 1) into a bit operation instead of a full byte-wise and followed by a check of the zero flag.
I'd say that the volatile argument is a poor excuse for avoiding optimization here. One could argue that an SFR is not covered by the language standard: even the declaration of an SFR has a special non-standard syntax. Besides, it is known that the CPU will perform a byte read when you read a single bit.
It is irrelevant what a classic 8051 does. The classic 8051 implements the instructions based on a requirement to minimize the number of transistors. But a modern one-clocker or a soft core may introduce a lot of changes since they have a completely different transistor budget available. I'm not convinced that the read-modify-write argument is true for every 8051 implementation in existence now or next year.
There shouldn't be anything stopping a manfacturer from introducing pin-change interrupts, where a read of a single port bit acknowledges interrupts for that pin while a read of the port acknowledges/clears potential interrupts for all eight pins.
I'm not convinced that ...
You dare to doubt the so-called "bible"? shame on you.
I don't doubt the bible, where it is applicable.
But I doubt that 25 year old documentation of the original 8051 is true for all 8051 variants in existence or in planning. It is enough that a single 8051 manufacturer (or programmer, if we think about soft cores) decides that bit operations can be done without a read/modify/write.
We are not debating any natural laws here. And even many of our natural laws are only applicable in their "normal" form for non-relativistic speeds.
But I doubt that 25 year old documentation of the original 8051 is true for all 8051 variants in existence or in planning.
But that shouldn't prevent the compiler writers from implementing optimizations for cases where they are applicable. That would be most if not all existing 8051 cores. A simple command line switch will take care of new/non-compliant cores. My understanding is that the OP is expressing frustration by the lack of progress on the optimization front. And I agree with that. It appears that C51 has been in bug-fix-only mode for many years.
And with a switch for selecting bit optimization of SFR on/off, a number of customers will explicitly claim the Keil compiler is buggy.
It isn't even likely that the chip manufacturers would document if they do a byte-wide read/modify/write or a hardware bit access so how would Keil know if such a flag would be needed or not?
It isn't even likely that the chip manufacturers would document ...
That is pure conjecture.
... would document if they do a byte-wide read/modify/write or a hardware bit access ...
If this unknown manufacturer were to deviate from something that people rely upon (and have done for the past 25 years) then they would have to make damn sure that it was documented as not being compatible.
Not at all.
Who are relying on a bit test operation being implemented as a byte read or just a single bit read?
Who are relying on a bit set being implemented as a byte read followed by a byte write?
The Keil code is most definitely not relying on that. It is doing what you ask it - a byte access when the source specifies a byte access, and a bit access when the code specifies a bit access. It leaves it up to you to decide if you want a bit instruction or a byte instruction.
In the case I mentioned earlier - some chip manufacturer implementing a pin change interrupt, with acknowledge of the pin interrupts by reading specific bits, such a feature would obviously have to be documented.
But a chip manufacturer who "just" implements a 8051 core functionality would not have any real reason to document how the bit operations are implemented.
It's just when you combine two things - a peripherial device that behaves differently for a bit read or a byte read, with a core that does not implement the bit read as a byte read - that things gets interesting.
Without a peripherial that behaves differently, the bit operations are opaque black boxes. You can't know if they do bit or byte accesses and there is no reason to document what they do. But having a soft core and combining it with own SFR devices have the potential for surprises if the compiler manufacturer decides to be "clever".
Well Keil support multiple data pointers so that processors that have them can have compiled code that uses them.
The programmer can choose to use (or ignore) the possible optimisation opportunity.
So theoretically, the same thing could be done with bit access.
It's a simple matter-of-fact.
Keil already have (by necessity) a number of extensions for the '51, so adding another wouldn't really be so naughty.
As to whether it would really be worth it is another matter.
But there is no doubt that it could be done.