I and a co-worker are programming an 8051 uController in C. Last week we were struggling with a poor perfomance time of our program. So I talked to the assembly guy and we figured that our way of software timer handling was too slow. We were using 16 bit variables. Now I tweaked the timer software a bit and it runs about 4x faster, which is fast enough.
Digging a little deeper in the produced assembly code we found a 'persistent nuisance'. As a test I wrote these lines in code:
uint8 j; for(j=10;j--;){ rightTorqueArray[j] = j; }
The array is an unsigned char array but when we observe the assembly
MOV R7,#0AH ?C0001: MOV R6,AR7 DEC R7 MOV A,R6 JZ ?C0002 ; rightTorqueArray[j] = j; } ; SOURCE LINE # 52 MOV A,#LOW (rightTorqueArray) ADD A,R7 MOV DPL,A CLR A ADDC A,#HIGH (rightTorqueArray) MOV DPH,A MOV A,R7 MOVX @DPTR,A SJMP ?C0001 ?C0002:
We noticed that the array is adressed with LOW and HIGH so apparantly it is treated as a 16 bit variable. But my assembly-nese is not so well, so please correct me if I am wrong.
I set the Code Optimalization at level 8: reuse Common entry code and the emphasis at Favor speed.
The assembly was produced as a .SRC file using #pragma SRC on top of the C-file.
But, surely, he can explain the assembler to you? And explain why this is inherent in the 8051 architecture?
"Well a funny thing. If I remove xdata there is no difference in the ammount of assembly lines"
That's not funny at all - it is to be expected if you are using a Memory Model which defaults to XDATA.
As already noted, XDATA memory access is inherently slow & "inefficient".
"Co-worker already tried using pointers but his attempt produced the same problem"
So show what, exactly, he tried - and what, exactly, was the result.
As the "inefficiency" is inherent in the underlying hardware architecture, it is bound to happen!
"Accessing xdata via for-loop supposed to be faster than using pointers"
Says who?
"Does it benefit if I were to remove the structs and use separate arrays instead?"
Most likely not. More detail needed to answer specifically.
void test(void) { uint8 rightTorqueArray[10], j; for(j = 10;j > 0; --j) { rightTorqueArray[j] = j; } } ///////////////////////////////////////////// 88: void test(void) 89: { 90: uint8 rightTorqueArray[10], j; 91: for(j = 10; j > 0; --j) C:0x199C 7F0A MOV R7,#0x0A 92: { 93: rightTorqueArray[j] = j; C:0x199E 7453 MOV A,#0x53 C:0x19A0 2F ADD A,R7 C:0x19A1 F8 MOV R0,A C:0x19A2 A607 MOV @R0,0x07 93: } C:0x19A4 DFF8 DJNZ R7,C:199E C:0x19A6 22 RET
But that example is not using XDATA - is it?
Yes, it is in data memory. It was done intentionally, to demonstrate different memory and access type in x51. It was not any restriction for it in the beginning of the topic.
OK - That's true.
A fundamental problem seems to be that the OP hasn't understood (or didn't originally understand) the implications of using XDATA - hence my early question about the significance of the xdata keyword.