|
<< Click to Display Table of Contents >> Why Are 24-bit Variables Seen at Funny Odd Addresses (1, 5, 9, etc.) |
  
|
|
<< Click to Display Table of Contents >> Why Are 24-bit Variables Seen at Funny Odd Addresses (1, 5, 9, etc.) |
|
Click here to download the example
The eTPU is a 24-bit machine, but the DATA memory is essentially 32-bits as it is on the shared bus with the host CPU. It is this conundrum of different natural memory widths which causes weaknesses in addressing.
So say you have some memory, and it is laid out in memory like this.
Addr 0: [byte 0]
Addr 1: [byte 1]
Addr 2: [byte 2]
Addr 3: [byte 3]
Addr 4: [byte 4]
Addr 5: [byte 5]
Addr 6: [byte 6]
Addr 7: [byte 7]
For host 32-bit accesses you get these bytes:
@addr 0: bytes 0,1,2,3
@addr 4: bytes 4,5,6,7
For eTPU 24-bit accesses (access by the eTPU's execution unit) you get these bytes @addr 1: bytes 1,2,3
@addr 5: bytes 5,6,7
So from the eTPU's perspective, bytes 0, 4, etc, are skipped on 24-bit accesses. This explains why the 24-bit accesses begin on funny odd addresses such as 1, 5, 9, etc.:
So how do you access bytes 0, 4, 8, etc on the eTPU's side???
Well, there are TWO choices. First, you can simply perform 8-bit (byte) accesses
@addr 0: bytes 0
@addr 4: bytes 4
Or, you can do 32-bit accesses.
@addr 0: bytes 0,1,2,3
@addr 4: bytes 4,5,6,7
So, this begs the question, why not always do 32-bit accesses in your eTPU code??? The answer is SPEED. The eTPU is a 24-bit machine, so your code should be 24-bit centric to make it execute the fastest. AND MORE IMPORTANTLY - only load/store operations are supported on 32-bit operands. The ETEC compiler will issue an error if the user tried to perform any other kind of operation on 32-bit operands.
The best way of accessing variables, is simply to let the compiler handle it!!!!
MyFunc()
{
int8 MyLocalInt8;
int24 MyLocalInt24;
}
Of course, what fun is programming if you can't taste the metal?
Note the following points in the code shown below.
•Pointers to 24-bit data access only 24-bits.
•Double-even addresses are skipped when incrementing/decrementing pointers (addr 0, 4, 8, etc)
•The watch window's first line shows the array's address and size
•The watch window shows the array's members if brackets are used []
Consider the following code.
#include <ETpu_Std.h>
#pragma ETPU_function MyETpuFunc;
int24 MyGlobal24[10];
void MyETpuFunc ( )
{
if ( IsHostServiceRequestEvent(7) )
{
int24 *My24Ptr = &MyGlobal24[0];
*My24Ptr++ = 0x111111;
*My24Ptr++ = 0x222222;
*My24Ptr++ = 0x333333;
*My24Ptr++ = 0x444444;
*My24Ptr++ = 0x555555;
}
else {} // Error recovery code ...
}
The DevTool watch window below shows that the 'MyGlobal24' array elements are located at address 0x0001, 0x0005, 0x0009, etc. Also the distance (in bytes) between each array element is 4 bytes so the nomenclature for this is that the 'Stride Length' is 4 bytes.
