gnupic: Thread: PIC14e: HIGH directive not setting bit-7

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:

"3.1.1.2 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.

Thanks!
-Richard

Hi Richard,

this really seems to be a gputils bug: I tried your example with MPASMX 
and HIGH sets the 7th bit:

0000                  00003 testme:

0000   3080           00004         movlw   HIGH    table

0001   0085           00005         movwf   FSR0H

0002   3004           00006         movlw   LOW     table

0003   0084           00007         movwf   FSR0L

                       00008

0004   345A           00009 table   dt      0x5a

                       00010         end


Please create a new ticket at https://sourceforge.net/p/gputils/bugs/.

Borut


On 30. 07. 2013 02:58, Richard Hodges wrote:
> 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:
>
> "3.1.1.2 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.
>
> Thanks!
> -Richard

Fixed in svn revision #985.

The gputils snapshot build source package is available at 
http://sourceforge.net/projects/gputils/files/snapshot_builds/src/gputils-src-20130801-985.tar.gz.
Windows 32bit setup package is at 
http://sourceforge.net/projects/gputils/files/snapshot_builds/i686-mingw32msvc/gputils-20130801-985-setup.exe.

Borut

On 30. 07. 2013 08:17, Borut Ražem wrote:
> Hi Richard,
>
> this really seems to be a gputils bug: I tried your example with 
> MPASMX and HIGH sets the 7th bit:
>
> 0000                  00003 testme:
> 0000   3080           00004         movlw   HIGH    table
> 0001   0085           00005         movwf   FSR0H
> 0002   3004           00006         movlw   LOW     table
> 0003   0084           00007         movwf   FSR0L
>                        00008
> 0004   345A           00009 table   dt      0x5a
>                        00010         end
>
> Please create a new ticket at https://sourceforge.net/p/gputils/bugs/.
>
> Borut
>
>
> On 30. 07. 2013 02:58, Richard Hodges wrote:
>> 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:
>>
>> "3.1.1.2 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.
>>
>> Thanks!
>> -Richard