[sdiy] DSPIC computed branch and include help

[rsdio at audiobanshee.com]

On Feb 22, 2016, at 1:39 PM, Richie Burnett <rburnett at richieburnett.co.uk> wrote:
> That's it! Thanks Scott. The GOTO instruction takes up two instruction locations in program memory! I knew it took 2 instruction cycles of time to execute a GOTO operation because of the instruction pipeline, but I had always thought all Dspic instructions were the same size in program memory. It's right there in the programmers reference manual though that it takes up 2 words.
> 
> The BRA Wx instruction works correctly when it's followed by single word branch instructions instead of dual-word GOTOs.  I'm just surprised it didn't generate an exception or something branching into the middle of a two-word instruction! At least then I would have realised what was wrong.

Microchip has a habit of encoding opcode extension operands as NOP to prevent exceptions.

For example, the PIC18 family has a basic 16-bit opcode, but any opcode that matches 0xFnnn executes as a NOP. Any of the opcodes that have additional 16-bit operands only use 12 bits of that operand, setting the upper 4 bits to all 1's. GOTO is one of the PIC18 instructions that has an operand, but jumping to the middle of that instruction just executes a NOP. GOTO has 20 bits of address, even without using the upper 4 bits of the operand, but that is enough since the PIC18 only has 1 MW (megaword) of program memory address space (2 MB) - a typically far less Flash memory than the address space can span. This technique sacrifices 1/16 of the possible opcode values by creating 4,097 different NOP instructions. Apparently the sacrifice was not too great.

The dsPIC uses a similar technique. Opcodes are 24-bit at the basic level. Operands set the upper 8 bits to all 0's, e.g., 0x00nnnn. This means there are at least 65,537 different NOP instructions. Jumping to the second word of an instruction that has an operand will simply execute NOP and then go on to the next instruction.

Of course, how that can guarantee the correct operation, considering that the firmware has just jumped to the wrong location, is an entirely different question. Well, it's not really much of a question, since you can't really guarantee correct operation if your code is jumping to a non-instruction address. Perhaps there are reasonable ways to take advantage of this.

Brian