[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: gpasm directives vs. MPASM
From: Molnár ####@####.#### Date: 3 Dec 2015 08:25:22 -0000 Message-Id: <20151203092520.4ee93d397c634674b9080960@freemail.hu> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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: ####@####.#### > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: gpasm directives vs. MPASM
From: Molnár ####@####.#### Date: 3 Dec 2015 19:08:52 -0000 Message-Id: <20151203200849.59baedebec67bf40599f7c6b@freemail.hu> 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: ####@####.#### > > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: gpasm directives vs. MPASM
From: "Andrew E. Mileski" ####@####.#### Date: 3 Dec 2015 23:50:46 -0000 Message-Id: <5660D53A.60008@isoar.ca> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: gpasm directives vs. MPASM
From: Molnár ####@####.#### Date: 7 Dec 2015 07:51:55 -0000 Message-Id: <20151207085152.e377f75867f53fa63c67d750@freemail.hu> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: gpasm directives vs. MPASM
From: "Vinod Kanna R" ####@####.#### Date: 7 Dec 2015 08:10:44 -0000 Message-Id: <1449474737.S.4256.23453.f4-235-231.1449475839.31455@webmail.rediffmail.com> 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: ####@####.#### > > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: gpasm directives vs. MPASM
From: "Andrew E. Mileski" ####@####.#### Date: 8 Dec 2015 23:09:37 -0000 Message-Id: <5667632E.3080705@isoar.ca> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |