2013-07-30 Richard Hodges posted the following report:
I am writing new code for the 16F1518, and I believe that gpasm is not handling HIGH correctly for this chip. My datasheet (DS41452C) states on page 19:
"188.8.131.52 Indirect Read with FSR
The program memory can be accessed as data by setting bit 7 of the FSRxH register and reading the matching INDFx register. The MOVIW instruction will place the lower eight bits of the addressed word in the W register. Writes to the program memory cannot be performed via the INDF registers. Instructions that access the program memory via the FSR require one extra instruction cycle to complete. Example 3-2 demonstrates accessing the program memory via an FSR. The HIGH directive will set bit<7> if a label points to a location in program memory."
I think that this access method is only for the "enhanced" 14 bit chips (like the 12f1822 and 12f1501, for example.) But I could be wrong...
This may be the line in question: (line 250 of gpasm/evaluate.c)
case HIGH: return (evaluate(p->value.unop.p0) >> 8) & 0xff;
I looked at disassembled relocatable code from gplink and I do not see the high bits set there either.
Here is code to show what happens:
LIST P=PIC16F1518 include p16f1518.inc testme: movlw HIGH table movwf FSR0H movlw LOW table movwf FSR0L table dt 0x5a end
And here is the disassembly:
> gpdasm -p 16f1518 bad.hex 000000: 3000 movlw 0 000001: 0085 movwf 0x5 000002: 3004 movlw 0x4 000003: 0084 movwf 0x4 000004: 345a retlw 0x5a
I do not know whether the struct pnode has enough information to figure out when to set the high bit (bit 7) of the result, but I can dig into it if it is not an easy fix for the main developers.