Tools in your eTPU toolchain may support you by disassembling eTPU_C-generated code. If they report instructions different than eTPU_C's listing file shows, you may be inclined to verify eTPU_C's output by hand.

eTPU machine code is very complex compared to traditional machine language. As a result, we receive support questions from people who have encountered subinstructions they didn't expect.

Here's a good example:

0200 3BF14FB4   alu diob = c ,ccs.          if (x < y)
0204 3874FFF4   alu nil = d - diob ,ccs.           {
                                        
0208 F080109F   if c==0 jump 0210,flush.         

The instruction at location 0x204 is an alu operation, supposedly a subtract, intended to change the carry flag and nothing more. This performs the less-than compare operation. Let's see if that's how the eTPU interprets it.

Using the constant bits, we learn that instruction word 0x3874fff4 is a B6/1G format instruction, commonly used in ALU operations. The last 5 bits are the ALUOP subinstruction field, and a quick check in the Block Guide shows that pattern 10100 is an addition subinstruction. Not quite what the disassembly says.

The secret is in two other fields.

• BINV is set to 0, causing the ALU's B source (DIOB) to be bitwise inverted.
• CIN is set to 0, causing a carry-in of 1 to the addition.

Performing A + /B + 1 (carry-in) gives the result of A - B source. This is the intended subtraction.

Congratulations if you had the Block Guide close at hand to verify this. We build eTPU_C straight from the specifications, in close consultation with the eTPU designers. We're still sure that a C compiler is the best way to create programs for the eTPU.

These are all the fields in a B6/1G instruction:

(reserved)

Note: remember that a 1 (or all ones) is often a "nop" value in eTPU subinstructions.

Bookmark/Search this post with:

delicious | digg | reddit | magnoliacom | technorati