Fetch packet alignment: 32 or 256 bits?

Archaeologist,

I would like to ask about the following scenario:

Byte address: 0, 4, 8, 12, 16, 20, 24, 28, 32...

According to {(1) Branching instruction's addressing by word (2) you answer}, the target of branching can be any of the above addresses.

Then, if the target of branching is 4, is FP fetched between [4..35]? If this is the case, it is clearly not "256-bit / 8 words aligned" as Slide 4/54 TMS320C64x+ Workshop described, but only its LENGTH is 256 bit, its starting address can be any byte address that is DIVISIBLE BY 4, i.e., any word address.

So is the slide wrong?

Zheng

The documentation is correct; fetch packets are always 256-bit aligned.  When branching to the middle of a fetch packet, the whole aligned 8-word fetch packet containing the branch target is fetched, even the words that come before the branch target.

So when the target is in the middle of a 256-bit aligned FP:

1. CPU still fetches the whole FP including the words preceding the target.
2. In the DP (instruction dispatch) phase, the preceding instruction words are simply ignored?

Is this the case?

This reminds me of another question: is it possible for branching target to be in the middle of an EP? It seems to me that:

1. If the user writes C code and the compiler generates the assembly code, it is very unlikely that a branching target could be at the middle of an EP. The compiler should have made each branching target the starting word of the EP it belongs to. Is this true?
2. If the user writes assembly code, anything could happen:
   1. In this case, the branching target might well be in the middle of an EP, not just of a FP. In the case, what does the CPU do? I tend to believe the ambiguity here is inherent: EP(A  || B || C) only contain the information that A, B, C are parallel, it can in fact be written in 6 different orders (the permutation factorial(3) ). If the CPU is designed to ignore the instruction before (in the storage order; there is no execution order here) the branching target, then although all permutations in storage order executes the same in normal situation, in this branching case they are executed differently. Therefore, it should be the programmer's responsibility to choose the right permutation.
   2. I don't know how rare it is to both (1) using assembly code (2) branching into the middle of an EP. But for logical completeness this scenario cannot be ignored.

So what does the CPU really do, if the programmer writes assembly code and a branching target is in the middle of an EP?

Zheng

Yes, it is legal (but generally unwise) to branch into the middle of an execute packet.  The compiler never does it. 

Yes, the preceding instructions are ignored, even if they appear (from the disassembler view) to be in parallel.  The assembler normally encodes the instructions in exactly the order they appear in the assembly code.   When generating compact (16-bit) instructions, the assembler may rearrange the order of an execute packet for better compaction, but will not do so if there is a label on any instruction in the execute packet but the first.

Archaeologist said:

When generating compact (16-bit) instructions, the assembler may rearrange the order of an execute packet for better compaction

You mean this? In this case, not only the B is moved to in front of A, but the branching target should also change, isn't it?

Archaeologist said:

but will not do so if there is a label on any instruction in the execute packet but the first.

Proof:

First, differentiate between two paths leads to the EP's execution:

1. linear execution
2. branching

For 1, the whole EP is always fully executed, therefore imposes no restriction on rearrangement here.

For 2, if a label is at an instruction other than the first, then re-ordering will cause unintended execution order. It is for this reason the compiler should not do rearrangement when label is in the middle of EP.

Is this correct?

Zheng

Archaeologist said:

but cannot move instructions that were lexically before the label to be after the label

For branching target in middle of EP:

• Not allowed: before→ after
• Allowed: after→ before

Right?

Not urgent, but I wish to know.

Zheng

Archaeologist,

As a follow-up which doesn’t require an answer, I found the case of branching into the middle of an EP is described 5.1.2 Interrupt Service Table (IST), page 537-538 of spru732j, TMS320C64x-C64x+ DSP CPU and Instruction Set Reference Guide :

Another question is about the relabeling when assembler re-arranges the order of compact instructions (the 3^rd post above). Does the assembler do that?

Zheng