gnupic: Thread: gpasm-0.9.0

Again, thanks to Craig Franklin, gpasm has taken another quantum leap forward:

http://www.dattalo.com/gnupic/gpasm-0.9.0.tar.gz

There haven't been too many changes since 0.8.16. However, Craig is about to
embark on the next stage of gpasm development. His last few patches have been
fairly significant and warrant a jump in the upgrade number.

The next task Craig is currently hacking away on is linker support for
gpasm. Yippie! Now this isn't going to be any ol' linker support. Craig is
striving to maintain mplink compatibility. This will require some reverse
engineering of the (mostly COFF) mplink object files. 

Craig has also written a hex disassebler whose output can be fed back into gpasm
to generate the same .hex code. It should keep those recursive programmers busy
:). This utility will eventually be integrated into the gpasm source tree.

The vc (.cod file viewer) utility is going to get integrated into the tree as
well.

Scott

PS. I'm slowly plugging away on the SDCC PIC port. The pcode design and
implementation is proving challenging (for every three lines of code I write, it
seems like I delete two!).

Hello,

I have downloaded and installed gpasm-0.9.0.  I though that I would have
a play with it to have a look at the error messages that it generates. 
When it came across a line that had a goto statement with a label
argument that had not been defined, it produced an error message like
this.

Error hextest.asm 13 : 157 maybe_evaluateCan't evaluate expression

Anyone have any ideas where the 'maybe_evaluate' sneaks in??


Cheers,

JD

On Tue, 30 Jan 2001, John Duncan wrote:

> Hello,
> 
> I have downloaded and installed gpasm-0.9.0.  I though that I would have
> a play with it to have a look at the error messages that it generates. 
> When it came across a line that had a goto statement with a label
> argument that had not been defined, it produced an error message like
> this.
> 
> Error hextest.asm 13 : 157 maybe_evaluateCan't evaluate expression
> 
> Anyone have any ideas where the 'maybe_evaluate' sneaks in??


Yes.
Line 362 of opcode.c is responsible for printing the message:

    gperror(GPE_UNKNOWN, __FUNCTION__"Can't evaluate expression");

The __FUNCTION__ evaluates to a string containing the function name. In this
case, the function name is maybe_evaluate. If you remove '__FUNCTION__' then
the maybe_evaluate string will go away. This is an artifact of some debugging
code one of us left in.

BTW, in gcc (and maybe other compilers) the two macros: __LINE__ and
__FUNCTION__ are extremely useful for diagnosing program flow. I more often
than not use these during debugging instead of gdb (or in my case ddd or the
emacs debugger).

Scott

Scott

Before all..congratulations for hacking over gpasm and gpsim
the question is....the correct syntax of ERRORLEVEL
I'am assembling a code with gpasm 0.9.0 and obtain the warning number 226
I see that the gpasm.pdf documentation is very old and not include this
warning
Where can I find new documentations to gpasm and gpsim.
I have gpasm.pdf  007 2 1998      and     gpsim.pdf   Dec 24 1999

               00060   RADIX                 HEX
Warning receptor.asm 61 : 226 All codes must be proceeded by '.'
Example: -.203
               00061   ERRORLEVEL            0, -.302, -.306
               00062   PROCESSOR             16F84
;16F84A-04/P
gretings :)
Néstor.

----- Original Message -----
From: Scott Dattalo ####@####.####
To: ####@####.####
Sent: Monday, January 29, 2001 1:32 AM
Subject: gpasm-0.9.0


>
> Again, thanks to Craig Franklin, gpasm has taken another quantum leap
forward:
>
> http://www.dattalo.com/gnupic/gpasm-0.9.0.tar.gz
>
> There haven't been too many changes since 0.8.16. However, Craig is about
to
> embark on the next stage of gpasm development. His last few patches have
been
> fairly significant and warrant a jump in the upgrade number.
>
> The next task Craig is currently hacking away on is linker support for
> gpasm. Yippie! Now this isn't going to be any ol' linker support. Craig is
> striving to maintain mplink compatibility. This will require some reverse
> engineering of the (mostly COFF) mplink object files.
>
> Craig has also written a hex disassebler whose output can be fed back into
gpasm
> to generate the same .hex code. It should keep those recursive programmers
busy
> :). This utility will eventually be integrated into the gpasm source tree.
>
> The vc (.cod file viewer) utility is going to get integrated into the tree
as
> well.
>
> Scott
>
> PS. I'm slowly plugging away on the SDCC PIC port. The pcode design and
> implementation is proving challenging (for every three lines of code I
write, it
> seems like I delete two!).

On Wed, 07 Feb 2001, you wrote:
> Scott
> 
> Before all..congratulations for hacking over gpasm and gpsim
> the question is....the correct syntax of ERRORLEVEL
> I'am assembling a code with gpasm 0.9.0 and obtain the warning number 226
> I see that the gpasm.pdf documentation is very old and not include this
> warning
> Where can I find new documentations to gpasm and gpsim.
> I have gpasm.pdf  007 2 1998      and     gpsim.pdf   Dec 24 1999

The documentation has been updated.  The new version will be released with
gpasm 0.9.1, hopefully soon.

> 
>                00060   RADIX                 HEX
> Warning receptor.asm 61 : 226 All codes must be proceeded by '.'
> Example: -.203
>                00061   ERRORLEVEL            0, -.302, -.306
>                00062   PROCESSOR             16F84
> ;16F84A-04/P

The new documentation wouldn't help you much.  The code for this one, 226, is
an UNKNOWN warning message.  Anything which hasn't been migrated from the old
error system to the new one or any error which is related to a known gpasm bug
are assigned UNKNOWN codes.  Sometime in the future all of these will be gone.

This particular error has to do with the way gpasm parses the constants
in the errorlevel directive.  Currently, it assumes all numbers should be
interpreted based on the radix setting.  It shouldn't.  It should always
interpret the numbers in the ERRORLEVEL directive as decimal.  

The warning was a cheesey way for me to tell the users about the problem.  A
comment to this effect is in the code.  

    if (state.radix != 10){
      gpwarning(GPW_UNKNOWN,"All codes must be proceeded by '.' Example: -.203");
      // BUG: Fix this and remove the warning!!  GPASM should always assume
      //      the arguments are decimal regardless of the current settings.
    }

You can ignore the message.  It will still work properly because the "." forces
decimal.

If you don't like seeing the message do the following:

  RADIX            DEC
  ERRORLEVEL 0, -302, -306
  PROCESSOR  16F84
  RADIX            HEX

This will be fixed in a future gpasm release.   

> gretings :)
> Néstor.
> 
> ----- Original Message -----
> From: Scott Dattalo ####@####.####
> To: ####@####.####
> Sent: Monday, January 29, 2001 1:32 AM
> Subject: gpasm-0.9.0
> 
> 
> >
> > Again, thanks to Craig Franklin, gpasm has taken another quantum leap
> forward:
> >
> > http://www.dattalo.com/gnupic/gpasm-0.9.0.tar.gz
> >
> > There haven't been too many changes since 0.8.16. However, Craig is about
> to
> > embark on the next stage of gpasm development. His last few patches have
> been
> > fairly significant and warrant a jump in the upgrade number.
> >
> > The next task Craig is currently hacking away on is linker support for
> > gpasm. Yippie! Now this isn't going to be any ol' linker support. Craig is
> > striving to maintain mplink compatibility. This will require some reverse
> > engineering of the (mostly COFF) mplink object files.
> >
> > Craig has also written a hex disassebler whose output can be fed back into
> gpasm
> > to generate the same .hex code. It should keep those recursive programmers
> busy
> > :). This utility will eventually be integrated into the gpasm source tree.
> >
> > The vc (.cod file viewer) utility is going to get integrated into the tree
> as
> > well.
> >
> > Scott
> >
> > PS. I'm slowly plugging away on the SDCC PIC port. The pcode design and
> > implementation is proving challenging (for every three lines of code I
> write, it
> > seems like I delete two!).
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
-------------------------------------------------------

Another method to make the message go away is to suppress 226.

  RADIX            HEX
  ERRORLEVEL 0, -.302, -.306,  -.226
  PROCESSOR  16F84

----------  Forwarded Message  ----------
Subject: Fwd: RE: gpasm-0.9.0
Date: Wed, 7 Feb 2001 16:10:34 -0600
From: Craig Franklin ####@####.####


On Wed, 07 Feb 2001, you wrote:
> Scott
> 
> Before all..congratulations for hacking over gpasm and gpsim
> the question is....the correct syntax of ERRORLEVEL
> I'am assembling a code with gpasm 0.9.0 and obtain the warning number 226
> I see that the gpasm.pdf documentation is very old and not include this
> warning
> Where can I find new documentations to gpasm and gpsim.
> I have gpasm.pdf  007 2 1998      and     gpsim.pdf   Dec 24 1999

The documentation has been updated.  The new version will be released with
gpasm 0.9.1, hopefully soon.

> 
>                00060   RADIX                 HEX
> Warning receptor.asm 61 : 226 All codes must be proceeded by '.'
> Example: -.203
>                00061   ERRORLEVEL            0, -.302, -.306
>                00062   PROCESSOR             16F84
> ;16F84A-04/P

The new documentation wouldn't help you much.  The code for this one, 226, is
an UNKNOWN warning message.  Anything which hasn't been migrated from the old
error system to the new one or any error which is related to a known gpasm bug
are assigned UNKNOWN codes.  Sometime in the future all of these will be gone.

This particular error has to do with the way gpasm parses the constants
in the errorlevel directive.  Currently, it assumes all numbers should be
interpreted based on the radix setting.  It shouldn't.  It should always
interpret the numbers in the ERRORLEVEL directive as decimal.  

The warning was a cheesey way for me to tell the users about the problem.  A
comment to this effect is in the code.  

    if (state.radix != 10){
      gpwarning(GPW_UNKNOWN,"All codes must be proceeded by '.' Example: -.203");
      // BUG: Fix this and remove the warning!!  GPASM should always assume
      //      the arguments are decimal regardless of the current settings.
    }

You can ignore the message.  It will still work properly because the "." forces
decimal.

If you don't like seeing the message do the following:

  RADIX            DEC
  ERRORLEVEL 0, -302, -306
  PROCESSOR  16F84
  RADIX            HEX

This will be fixed in a future gpasm release.   

> gretings :)
> Néstor.
> 
> ----- Original Message -----
> From: Scott Dattalo ####@####.####
> To: ####@####.####
> Sent: Monday, January 29, 2001 1:32 AM
> Subject: gpasm-0.9.0
> 
> 
> >
> > Again, thanks to Craig Franklin, gpasm has taken another quantum leap
> forward:
> >
> > http://www.dattalo.com/gnupic/gpasm-0.9.0.tar.gz
> >
> > There haven't been too many changes since 0.8.16. However, Craig is about
> to
> > embark on the next stage of gpasm development. His last few patches have
> been
> > fairly significant and warrant a jump in the upgrade number.
> >
> > The next task Craig is currently hacking away on is linker support for
> > gpasm. Yippie! Now this isn't going to be any ol' linker support. Craig is
> > striving to maintain mplink compatibility. This will require some reverse
> > engineering of the (mostly COFF) mplink object files.
> >
> > Craig has also written a hex disassebler whose output can be fed back into
> gpasm
> > to generate the same .hex code. It should keep those recursive programmers
> busy
> > :). This utility will eventually be integrated into the gpasm source tree.
> >
> > The vc (.cod file viewer) utility is going to get integrated into the tree
> as
> > well.
> >
> > Scott
> >
> > PS. I'm slowly plugging away on the SDCC PIC port. The pcode design and
> > implementation is proving challenging (for every three lines of code I
> write, it
> > seems like I delete two!).
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
-------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####
-------------------------------------------------------

Hello Craig

Excuse me for delay to respond,  now.... understanding because of the
things...
both methods to perform perfect, I utilize ERRORLEVEL
, -.302, -.306,  -.226
of lenguaje C,  I to stay learning with a book ttituled

Theacher Yourself C++ for Linux in 21 days
ISBN 0-672-31895-4
Sams Publishing

this is a "small book" of  1110 pages, the same to come a friend from Miami

well, step by step, gpasm will be better.
Craig...thanks a millon !!!

greetings

Nestor A. Marchesini
Chajari-Entre Rios-Argentina
ICQ # 50983752 nick colo
####@####.####

> Another method to make the message go away is to suppress 226.
>
>   RADIX            HEX
>   ERRORLEVEL 0, -.302, -.306,  -.226
>   PROCESSOR  16F84
>
> The documentation has been updated.  The new version will be released with
> gpasm 0.9.1, hopefully soon.
> The new documentation wouldn't help you much.  The code for this one, 226,
is
> an UNKNOWN warning message.  Anything which hasn't been migrated from the
old
> error system to the new one or any error which is related to a known gpasm
bug
> are assigned UNKNOWN codes.  Sometime in the future all of these will be
gone.
>
> This particular error has to do with the way gpasm parses the constants
> in the errorlevel directive.  Currently, it assumes all numbers should be
> interpreted based on the radix setting.  It shouldn't.  It should always
> interpret the numbers in the ERRORLEVEL directive as decimal.
>
> The warning was a cheesey way for me to tell the users about the problem.
A
> comment to this effect is in the code.
>
>     if (state.radix != 10){
>       gpwarning(GPW_UNKNOWN,"All codes must be proceeded by '.'
Example: -.203");
>       // BUG: Fix this and remove the warning!!  GPASM should always
assume
>       //      the arguments are decimal regardless of the current
settings.
>     }
>
> You can ignore the message.  It will still work properly because the "."
forces
> decimal.
>
> If you don't like seeing the message do the following:
>
>   RADIX            DEC
>   ERRORLEVEL 0, -302, -306
>   PROCESSOR  16F84
>   RADIX            HEX
>
> This will be fixed in a future gpasm release.

I have fixed the problem in gpasm.  

It hasn't been throughly tested yet, but assuming it passes the tests, it will
be part of gpasm 0.9.1. 

On Fri, 09 Feb 2001, you wrote:
> Hello Craig
> 
> Excuse me for delay to respond,  now.... understanding because of the
> things...
> both methods to perform perfect, I utilize ERRORLEVEL
> , -.302, -.306,  -.226
> of lenguaje C,  I to stay learning with a book ttituled
> 
> Theacher Yourself C++ for Linux in 21 days
> ISBN 0-672-31895-4
> Sams Publishing
> 
> this is a "small book" of  1110 pages, the same to come a friend from Miami
> 
> well, step by step, gpasm will be better.
> Craig...thanks a millon !!!
> 
> greetings
> 
> Nestor A. Marchesini
> Chajari-Entre Rios-Argentina
> ICQ # 50983752 nick colo
> ####@####.####
> 
> > Another method to make the message go away is to suppress 226.
> >
> >   RADIX            HEX
> >   ERRORLEVEL 0, -.302, -.306,  -.226
> >   PROCESSOR  16F84
> >
> > The documentation has been updated.  The new version will be released with
> > gpasm 0.9.1, hopefully soon.
> > The new documentation wouldn't help you much.  The code for this one, 226,
> is
> > an UNKNOWN warning message.  Anything which hasn't been migrated from the
> old
> > error system to the new one or any error which is related to a known gpasm
> bug
> > are assigned UNKNOWN codes.  Sometime in the future all of these will be
> gone.
> >
> > This particular error has to do with the way gpasm parses the constants
> > in the errorlevel directive.  Currently, it assumes all numbers should be
> > interpreted based on the radix setting.  It shouldn't.  It should always
> > interpret the numbers in the ERRORLEVEL directive as decimal.
> >
> > The warning was a cheesey way for me to tell the users about the problem.
> A
> > comment to this effect is in the code.
> >
> >     if (state.radix != 10){
> >       gpwarning(GPW_UNKNOWN,"All codes must be proceeded by '.'
> Example: -.203");
> >       // BUG: Fix this and remove the warning!!  GPASM should always
> assume
> >       //      the arguments are decimal regardless of the current
> settings.
> >     }
> >
> > You can ignore the message.  It will still work properly because the "."
> forces
> > decimal.
> >
> > If you don't like seeing the message do the following:
> >
> >   RADIX            DEC
> >   ERRORLEVEL 0, -302, -306
> >   PROCESSOR  16F84
> >   RADIX            HEX
> >
> > This will be fixed in a future gpasm release.
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####