PIC16C - Language spec considers certain RAM to be shared between banks, but this isn't true of all processors

[dcollinsn]

Describe the bug
The PIC16 language specification includes the following comment and code:

https://github.com/NationalSecurityAgency/ghidra/blob/master/Ghidra/Processors/PIC/data/languages/pic16_instructions.sinc#L166-L170

# Top 16 bytes are shared RAM on PIC16 and PIC16F
srcREG: fv		is uf7=0x7 & lf7  [fv = 0x70 + lf7; ]								{ 
	 addr:2 = fv;
	 export *[DATA]:1 addr;
}

These processors have multiple RAM banks, selected by bits in the status register. On some processors, the top 16 bits are shared (that is, 0x70 in bank 0 and 0xf0 in bank 1 point to the same register). However, this isn't true for all processors in this series. Page 22 of the manual available at https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/30390e.pdf shows that this is true only for the PIC16C76/77. For the PIC16C73/73A/74/74A, 0x70 and 0xf0 are separate registers, and for the PIC16C72 it is irrelevant because the last implemented memory address is 0xBF.

To Reproduce
Steps to reproduce the behavior:

1. Analyze a PIC16C74A binary with the instructions BSF STATUS, RP0, CLRF 0x70

Expected behavior
The instruction is interpreted to affect memory location 0xF0

Environment (please complete the following information):

• OS: Windows 10
• Java Version: 17.0.7
• Ghidra Version: 11.3.2
• Ghidra Origin: official GitHub distro

Additional context
I commented out the snippet of code mentioned above and restarted Ghidra. The decompilation view now shows that the correct memory variables are being affected. The listing view shows that the instruction is still affecting the incorrect label:

After selecting "Patch Instruction", pressing "Enter" twice without making any changes, and re-running Analysis, the listing view and instruction info are correct (TP3 is the label for data location 0xF4, and note that the "Address" in the right pane of the instruction info screen is also now correct.) Re-running analysis without first patching the instruction did not fix the address.

[GhidorahRex]

It sounds like we need a separate variant for PIC16C76/77 versus the other PIC16 variants to handle this edge case.