hi: I want to use recursion function to transform a integer from binary form to ascii form. But the result is wrong.I don't why ,please help to analyse.
soure code:
void binary_to_ascii(unsigned int value) { unsigned int quotient; quotient = value/10; if(quotient !=0 ) binary_to_ascii(quotient); putchar(value%10+'0'); } int main() { while(1){ binary_to_ascii(4267); } }
I want to produce characters '4','2','6','7' in sequence. but the result is '4','4','4'. I don't know what is wrong with my code.
Keil C51 toolset does work well when you stay within it's limitations. and accept its achitecturally mandated inefficiencies.
Keil has, I am sure due to pressure fron the "C is C" types, implemented many functions that the architecture of the '51 makes extremely inefficient and likely to eat resources beyond what is available.
Sure, with a PC attitude, you can just implement all the inefficient code you want and then say "We need a faster peocessor"
Has anyone ever thought about the fact that while the greenies are constantly on the back of e.g. Dell, nobody complains when the next Microsoft wonder requires a much faster (and thus power hungry) computer.
Erik
But recursion is a valid programming paradigm.
And a 8051 can support recursion.
No reason to not use recursion for cases where it gives an advantage. Finding examples of how a tool can be abused doesn't mean that a tool should never be used.
no argument.
The point is that if you do "C is C" and do not know the implications with the architecture, you have not taken the time to get to know the '51 aka "architectural ignorance".
There are, indeed cases where a careful use of one of the features that have been wrested into C51 can be justified, but doing so just because "C is C" is plain foolish.
I kind of expect an embedded developer to be competent enough to: 1) Have a rough idea about mapping from C to assembler. 2) Be able to look at disassembly if expectations doesn't match reality.
This case is not one of them - especially on an 8051!
Sorry - that post should have been titled, "use recursion for cases where it gives an advantage"
In other words: I agree that recursion may, in general, be used where it gives an advantage (within the limitations of the implementation) - but the example at hand is not one of them!
Yes, this is a case of a linear problem that is trivial to rewrite as a loop. And as i noted earlier, the only state info the loop will need is one character/iteration since the loop produces the characters in the reverse order.
Another alternative so instead produce the output in correct order is to have a sequence of operations handling 10^4, 10^3, 10^2, ...
The recursive solution requires the return address for n iterations, and an unknown number of state bytes/iteration that will depend completely on compiler and optimization level. And how will the compiler know the maximum recursion depth?