gnupic: Thread: Re: gpasm directives vs. MPASM

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

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: ####@####.####
>

On Thu, 3 Dec 2015 11:03:52 -0600
Jerry Zdenek ####@####.#### wrote:

> 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

You are right, because the number of the usable bits is differs and not clearly written that it is a hardware limit. I remembered badly.

Example 4-bit: In the http://ww1.microchip.com/downloads/en/DeviceDoc/41640A.pdf page 3, "2.3.1 USER ID LOCATIONS" section.
Example 4-bit: In the http://ww1.microchip.com/downloads/en/DeviceDoc/41227E.pdf page 2, "2.2 User ID Locations" section.
Example 7-bit: In the http://ww1.microchip.com/downloads/en/DeviceDoc/41244F.pdf page 6, "2.2 User ID Locations" section.
Example 7-bit: In the http://ww1.microchip.com/downloads/en/DeviceDoc/40001713A.pdf page 5, "3.1 User ID Location" section.
Example 7-bit: In the http://ww1.microchip.com/downloads/en/DeviceDoc/40001796A.pdf page 6, "3.1 User ID Location" section.

It seems 4 bits are available upon the 12-bit devices and 7 bits are available upon the 14-bit devices.

Károly

> 
> 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: ####@####.####
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
> 

On 2015-12-03 03:25, Molnár Károly wrote:
> On Mon, 30 Nov 2015 15:22:26 -0500
> "Andrew E. Mileski" ####@####.#### wrote:
>>
>> I would expect IDLOCS to be treated like any other section label when
>> --mpasm-compatible is specified.
>
> The gpasm works a little differently.

That's my point though.  I'd expect it be source compatible with --mpasm-compatible

If that's not a goal, then I'll just quietly disappear.

> 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

Erm... I can find no mention of a 4 bit limitation per location for this processor.

Excerpt from DS41390D
http://ww1.microchip.com/downloads/en/DeviceDoc/41390D.pdf

"3.1 User ID Location

A user may store identification information (user ID) in four designated 
locations. The user ID locations are mapped to 8000h-8003h.  Each location is 14 
bits in length. Code protection has no effect on these memory locations. Each 
location may be read with code protection enabled or disabled."

~~ Andrew E. Mileski

On Thu, 03 Dec 2015 18:50:18 -0500
"Andrew E. Mileski" ####@####.#### wrote:

> On 2015-12-03 03:25, Molnár Károly wrote:
> > On Mon, 30 Nov 2015 15:22:26 -0500
> > "Andrew E. Mileski" ####@####.#### wrote:
> >>
> >> I would expect IDLOCS to be treated like any other section label when
> >> --mpasm-compatible is specified.
> >
> > The gpasm works a little differently.
> 
> That's my point though.  I'd expect it be source compatible with --mpasm-compatible
> 
> If that's not a goal, then I'll just quietly disappear.
> 
> > 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
> 
> Erm... I can find no mention of a 4 bit limitation per location for this processor.
> 
> Excerpt from DS41390D
> http://ww1.microchip.com/downloads/en/DeviceDoc/41390D.pdf
> 
> "3.1 User ID Location
> 
> A user may store identification information (user ID) in four designated 
> locations. The user ID locations are mapped to 8000h-8003h.  Each location is 14 
> bits in length. Code protection has no effect on these memory locations. Each 
> location may be read with code protection enabled or disabled."
> 
> ~~ Andrew E. Mileski
> 

These the new versions, please give it a try:
http://sourceforge.net/projects/gputils/files/snapshot_builds/src/gputils-src-20151206-1161.tar.gz/download
http://sourceforge.net/projects/gputils/files/snapshot_builds/i686-mingw32msvc/gputils-20151206-1161-setup.exe/download

Károly

UnsubscribeSent from RediffmailNG on Android

From: "Molnár ####@####.####
Sent:Mon, 07 Dec 2015 13:22:17 +0530
To: ####@####.####
Subject: Re: gpasm directives vs. MPASM
On Thu, 03 Dec 2015 18:50:18 -0500
> "Andrew E. Mileski" ####@####.#### wrote:
> 
> > On 2015-12-03 03:25, Molnár Károly wrote:
> > > On Mon, 30 Nov 2015 15:22:26 -0500
> > > "Andrew E. Mileski" ####@####.#### wrote:
> > >>
> > >> I would expect IDLOCS to be treated like any other section label when
> > >> --mpasm-compatible is specified.
> > >
> > > The gpasm works a little differently.
> > 
> > That's my point though.  I'd expect it be source compatible with --mpasm-compatible
> > 
> > If that's not a goal, then I'll just quietly disappear.
> > 
> > > 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
> > 
> > Erm... I can find no mention of a 4 bit limitation per location for this processor.
> > 
> > Excerpt from DS41390D
> > http://ww1.microchip.com/downloads/en/DeviceDoc/41390D.pdf
> > 
> > "3.1 User ID Location
> > 
> > A user may store identification information (user ID) in four designated 
> > locations. The user ID locations are mapped to 8000h-8003h.  Each location is 14 
> > bits in length. Code protection has no effect on these memory locations. Each 
> > location may be read with code protection enabled or disabled."
> > 
> > ~~ Andrew E. Mileski
> > 
> 
> These the new versions, please give it a try:
> http://sourceforge.net/projects/gputils/files/snapshot_builds/src/gputils-src-20151206-1161.tar.gz/download
> http://sourceforge.net/projects/gputils/files/snapshot_builds/i686-mingw32msvc/gputils-20151206-1161-setup.exe/download
> 
> Károly
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
> 

On 2015-12-07 02:51, Molnár Károly wrote:
>
> These the new versions, please give it a try:
> http://sourceforge.net/projects/gputils/files/snapshot_builds/src/gputils-src-20151206-1161.tar.gz/download
> http://sourceforge.net/projects/gputils/files/snapshot_builds/i686-mingw32msvc/gputils-20151206-1161-setup.exe/download
>
> Károly

Seems to assemble now.  Thanks!

Haven't tried linking it yet, nor have I looked over the source changes in depth 
yet though (was surprised where the fix was inserted).  [I need a limited-life 
clone.]


~~ Andrew E. Mileski