24-Bit Addressing Issues

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 weirdnesses in addressing.

So say you have some memory, and it is layed 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 acceses. 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 acccesses.

@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 Byte Craft compiler will silently generate buggy code.

Usage: Compiler, Ideal.

The best way of accessing variables, is simply to let the compiler handle it!!!!

MyFunc()
{
   int8 MyLocalInt8;
   int24 MyLocalInt24;
}

Usage: Compiler, Pointers.

Of course, what fun is programming if you can't taste the metal?

Note the following points in the code shown below.