gnupic: Re: gpasm directives vs. MPASM
Subject:
Re: gpasm directives vs. MPASM
From:
Jerry Zdenek ####@####.####
Date:
3 Dec 2015 17:04:02 -0000
Message-Id: <566075F8.4010809@sarpeidon.net>
Where does it say that it is a hardware limitation?
It's just convention to store a 16bit value as 4 4bit values. You could
equally store it as 2 8bit values.
Jerry
On 12/3/2015 2:25 AM, Molnár Károly wrote:
> On Mon, 30 Nov 2015 15:22:26 -0500
> "Andrew E. Mileski" ####@####.#### wrote:
>
>>
>> First, thanks to all those involved for the marvelous gputils suite!
>>
>> I admit to being a PIC rookie, but it seems that gpasm is parsing the IDLOCS
>> symbol as a directive, even when the --mpasm-compatible option is used, despite
>> IDLOCS not being a MPASM directive (as far as I can tell).
>>
>> Is this a potential bug / "feature"? Or is there a command-line option or
>> something else that I'm overlooking which avoids this behaviour?
>>
>> I don't rule out that I could be doing something really stupid.
>>
>> IDLOCS appears to be a standard section name; grep the linker files. An example
>> of the following can be found in the current MPASM manual (DS33014L), page 28.
>> I've just condensed the code, and set the processor type for this example.
>>
>> LIST p=16f1829
>>
>> IDLOCS CODE
>>
>> dw H'048C'
>> dw H'159D'
>> dw H'26AE'
>> dw H'37BF'
>>
>> END
>>
>> $ ./gpasm --mpasm-compatible -c bug.asm
>> bug.asm:4:Warning[205] Found directive in column 1: "IDLOCS"
>> bug.asm:4:Error[181] Directive Error: The IDLOCS directive is invalid in MPASM
>> mode.
>>
>> I would expect IDLOCS to be treated like any other section label when
>> --mpasm-compatible is specified.
>>
>> I was considering patching the ^{IDENT}:? pattern in scan.l to return LABEL
>> instead of IDENTIFIER for gpasm-specific directives in the ID_DIRECTIVES case
>> when --mpasm-compatible is specified... unless there is a better route?
>>
>> ~~
>> Andrew E. Mileski
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ####@####.####
>> For additional commands, e-mail: ####@####.####
>>
>>
>
>
> The gpasm works a little differently. Citations from the gputils handbook:
>
>
> CHAPTER 2. GPASM 18
>
> __IDLOCS __IDLOCS <expression> or __IDLOCS <expression1>,<expression2>
>
> Sets the PIC processor’s identification locations. For 12 and 14 bit processors, the four id locations
> are set to the hexadecimal value of expression. For 18cxx devices idlocation expression1 is set to
> the hexadecimal value of expression2.
>
> .
> .
> .
> .
> .
>
> CHAPTER 2. GPASM 22
>
> IDLOCS <expression> or IDLOCS <expression1>,<expression2>
>
> In “gpasm” mode (if the command line is not included the "--mpasm-compatible" option), in the case
> of PIC18FXXX processors it is possible to use this directive.
>
> The expressions may be are as follows: string (“abcdef”), character (’a’), constant (0x37), symbol (NUM1)
> These may be used simultaneously: IDLOCS “abcd”, 0x76, ’D’, NUM1
> The length of IDLOCS can be at most 8 bytes.
>
> --------------------------------------------------------------------------
>
> So in your case so that should be used:
>
> LIST p=16f1829
>
> __IDLOCS H'048C'
>
> END
>
> The compiler will do this:
>
> 0x8000: 0x0C
> 0x8001: 0x08
> 0x8002: 0x04
> 0x8003: 0x00
>
> That is, a single 16-bit value stored in four 4-bit part. This is a hardware limitation.
> Therefore the __IDLOCS directive can be used only once in the 12-bit and 14-bit devices.
>
> See: http://ww1.microchip.com/downloads/en/DeviceDoc/40001440E.pdf, page 51
>
> Molnár Károly
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
