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.
Hi, Is there a problem using idata for variables used in "heavy"calculations ? ( heavy = 3 products 2 sums in a same instruction) I use microvision 1.30 dll 1.30 C compiler v5.20 In my program some calculations produce good results when used with data and wrong and changeant results when used with idata. Thanks. Gregory.
( heavy = 3 products 2 sums in a same instruction) Have you heard about the competition on how to make the most obfusciated C code? Erik
The only thing I can think of is that this has to do with stack space. In a complex statement, intermediate results are placed on the stack and, if you are using idata, there will be less stack space available. It is sometimes possible to rearrange a statement to minimise stack space and increase speed of execution. For example, you may find that:
a = b + c * d;
a = c * d + b;
"In a complex statement, intermediate results are placed on the stack" Are you sure about this?
Am I sure? Well, it is possible that it only happens to long ints as in:
9: la = (lb * lc) + (lb * ld); 0000A1 AF21 MOV R7,ld+03H 0000A3 AE20 MOV R6,ld+02H 0000A5 AD1F MOV R5,ld+01H 0000A7 AC1E MOV R4,ld 0000A9 AB19 MOV R3,lb+03H 0000AB AA18 MOV R2,lb+02H 0000AD A917 MOV R1,lb+01H 0000AF A816 MOV R0,lb 0000B1 1115 ACALL ?C?LMUL 0000B3 C004 PUSH AR4 0000B5 C005 PUSH AR5 0000B7 C006 PUSH AR6 0000B9 C007 PUSH AR7 0000BB AF1D MOV R7,lc+03H 0000BD AE1C MOV R6,lc+02H 0000BF AD1B MOV R5,lc+01H 0000C1 AC1A MOV R4,lc 0000C3 AB19 MOV R3,lb+03H 0000C5 AA18 MOV R2,lb+02H 0000C7 A917 MOV R1,lb+01H 0000C9 A816 MOV R0,lb 0000CB 1115 ACALL ?C?LMUL 0000CD D003 POP AR3 0000CF D002 POP AR2 0000D1 D001 POP AR1 0000D3 D000 POP AR0 0000D5 EF MOV A,R7 0000D6 2B ADD A,R3 0000D7 F515 MOV la+03H,A 0000D9 EE MOV A,R6 0000DA 3A ADDC A,R2 0000DB F514 MOV la+02H,A 0000DD ED MOV A,R5 0000DE 39 ADDC A,R1 0000DF F513 MOV la+01H,A 0000E1 EC MOV A,R4 0000E2 38 ADDC A,R0 0000E3 F512 MOV la,A
Well, there you go. I'd always believed the manual: http://www.keil.com/support/docs/250.htm
I just updated the knowledgebase article to indicate this. Jon
Jon, Can you give any indication of the maximum stack depth the compiler could use when evaluating an arbitrarily complex expression?
I have a hunch such an upper limit can't possibly exist. As far as I can see, "arbritrarily complex" expressions can, almost by definition, require arbitrarily much stack space to evaluate.
"I have a hunch such an upper limit can't possibly exist. As far as I can see, "arbritrarily complex" expressions can, almost by definition, require arbitrarily much stack space to evaluate." Really? It srikes me as a bit strange that the compiler doesn't use the stack for parameter passing or local variables 'due to limitations of the 8051 architecture', however it appears that it arbitrarily and silently pushes whatever quantity of stuff it likes on the stack during evaluation of a complex expression. This is why I would really like a definitive answer from Keil on this subject.
Can you give any indication of the maximum stack depth the compiler could use when evaluating an arbitrarily complex expression? The compiler only stacks temporary results when absolute required. Typically, this is only required in complex expressions using long or float types which include function calls. For example, consider the following:
long a,b,c,d,e; e = (a*b) + (c*d);
long a,b,c,d,e,f,g; e = (a*b) + (c*d) + (f*g);
Really? It srikes me as a bit strange that the compiler doesn't use the stack for parameter passing or local variables 'due to limitations of the 8051 architecture', however it appears that it arbitrarily and silently pushes whatever quantity of stuff it likes on the stack during evaluation of a complex expression. If the compiler used the stack for local variables and function arguments, it would need a way to reference those objects on the stack. It would need a base pointer. R0 or R1 would be required for that. That would leave only 7 registers to be used in the function. Operations with floats or with longs could no longer be performed entirely in registers (like they are now). ALL local variables and function arguments would take longer to access (because indirect accesses are slower on the 8051 then direct accesses). This would slow down ALL programs and would ultimately require more stack space than is used by the current scheme. As it is, you are only penalized (more stack space required) for complex expressions. Jon
Jon, Thank you for your answer.