GPasm maint

[Rob Hamerling-3]

Hi,
I wanted to use GPasm under ComStation (OS/2).  The most recent native
OS/2 version of GPasm I could find was 0.11.1 alpha (dd 2003). I tried
to compile the 0.13.6 source with the Open Watcom C/C++ compiler and
succeeded with home made makefiles. I encountered some problems, both
during compile and use of GPasm, which I would like to report and
discuss. Looking in the bug tracker there seems not to be much
maintenance activity.... Is GPasm still maintained? And is this mailing
list a good place to discuss these issues?
Regards, Rob.

--
Rob Hamerling, Vianen, NL (http://www.robh.nl/)

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

[David Barnett-3]

On Fri, 04 Jul 2008 09:32:22 +0200
Rob Hamerling <robhamerling@...> wrote:

> Hi,
> I wanted to use GPasm under ComStation (OS/2).
> ...
> I encountered some problems, both during compile and use of GPasm,
> which I would like to report and discuss. Looking in the bug tracker
> there seems not to be much maintenance activity.... Is GPasm still
> maintained? And is this mailing list a good place to discuss these
> issues?
Yes and yes. 0.13.6 was released less than 2 months ago. One man can
only do so much, especially as a hobby, but I try to apply user patches
as they come in, fix some critical bugs as they turn up, and make a
release now and then. And we have a few fairly helpful users that submit
huge patches on occasion.

If you have specific bugs, go ahead and file those in the tracker, but
for any free-format discussion, this is the place. Fire away.

David

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

[Rob Hamerling-3]

Hi David,

[RobH]
>> I wanted to use GPasm under ComStation (OS/2).
>> ...
>> I encountered some problems, both during compile and use of GPasm,
>> which I would like to report and discuss. Looking in the bug tracker
>> there seems not to be much maintenance activity.... Is GPasm still
>> maintained? And is this mailing list a good place to discuss these
>> issues?

David wrote:
> Yes and yes. 0.13.6 was released less than 2 months ago. One man can
> only do so much, especially as a hobby, but I try to apply user patches
> as they come in, fix some critical bugs as they turn up, and make a
> release now and then. And we have a few fairly helpful users that submit
> huge patches on occasion.

Thanks David for the encouragement.

About building GPASM: I got a couple of warnings. This might be related
to the compiler I use, or related the macro defines like HAVE_MALLOC_H,
etc) in my makefile. Most warnings do not worry me (like missing
prototype for unlink). There is one that may be important:
> parse.c(422): Warning! W129: #endif matches #if in different source file 'parse.y'
I think there must be an '#endif' missing in parse.y

Probably an issue with optimisation of LibGPUtils:
> gpcoffgen.c(434): Warning! W124: Comparison result always 0
> gpcoffgen.c(447): Warning! W124: Comparison result always 0
> gpprocessor.c(649): Warning! W124: Comparison result always 0
> gpprocessor.c(668): Warning! W124: Comparison result always 0

An error I 'circumvented' by excluding vsnprintf from the library
> vsnprintf.c(42): Error! E1055: Unable to open 'config.h'
I cannot find 'config.h', nor do I see any possible macro definition to
prevent it being included.  So I (temporarily) left out the module from
the library (just lucky that GPasm seems not to need it?).


> If you have specific bugs, go ahead and file those in the tracker, but
> for any free-format discussion, this is the place. Fire away.

If you prefer these to be reported in the tracker, then I'll do.

-------------------

About using GPasm: I get a syntax error on a #v() expression. I saw in
the tracker an entry about #v(), but I don't understand the remarks (I'm
hardly familiar with PIC assembly).  The program I tried to assemble is
the 'TinyBld' bootloader, a 16F88 variant. I think the error is quite
'isolated'. An include file contains the following code:

> RoundResult SET 0                              
> Round   macro aa,bb
>         LOCAL rr = aa/bb
>         LOCAL d1 = aa - rr*bb
>         LOCAL d2 = (rr+1)*bb - aa
> RoundResult = rr
>         if d1 >= d2
> RoundResult++
>         endif
>         endm
>
> AbsResult SET 0
> Abs     macro nr
>         if nr>=0
> AbsResult = nr
>         else
> AbsResult = -nr
>         endif
>         endm
>
>         Round xtal,(16*baud)
> spbrg_value EQU RoundResult-1
>
>         Round xtal,(16*(spbrg_value+1))
> baud_real EQU RoundResult
>         Abs(baud_real-baud)
> errpercent EQU AbsResult*100/baud
>         if errpercent > 4
>                 ERROR big error in baudrate: #v(errpercent)%
>         endif
>         if errpercent >= 2
>                 MESSG baudrate not exact: #v(errpercent)%
>         endif

Both the ERROR and MESSG statements just here above cause:
> Error [103] : syntax error

MPASM (run under XP in a Virtual PC) doesn't complain.

Also candidate for a (new) tracker entry?

Regards, Rob.




--
Rob Hamerling, Vianen, NL (http://www.robh.nl/)

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

[David Barnett-3]

On Fri, 04 Jul 2008 18:04:55 +0200
Rob Hamerling <robhamerling@...> wrote:

> Hi David,
>
> ...
> About building GPASM: I got a couple of warnings. This might be
> related to the compiler I use, or related the macro defines like
> HAVE_MALLOC_H, etc) in my makefile. Most warnings do not worry me
> (like missing prototype for unlink). There is one that may be
> important:
> > parse.c(422): Warning! W129: #endif matches #if in different source
> > file 'parse.y'
> I think there must be an '#endif' missing in parse.y

There aren't any #if's in parse.y, and I can't find anything mismatched
in any of the included files. Did you edit stdhdr.h? You mentioned
problems with HAVE_MALLOC_H, and there's a double #if/#endif around a
reference to HAVE_MALLOC_H in stdhdr.h. Is it possible you got confused
there?

> Probably an issue with optimisation of LibGPUtils:
> > gpcoffgen.c(434): Warning! W124: Comparison result always 0
> > gpcoffgen.c(447): Warning! W124: Comparison result always 0
> > gpprocessor.c(649): Warning! W124: Comparison result always 0
> > gpprocessor.c(668): Warning! W124: Comparison result always 0
On this I have no idea, but the code does look a little suspicious w/
the values it's comparing.

> An error I 'circumvented' by excluding vsnprintf from the library
> > vsnprintf.c(42): Error! E1055: Unable to open 'config.h'
> I cannot find 'config.h', nor do I see any possible macro definition
> to prevent it being included.
config.h is supposed to be auto-generated from config.h.in when you
run ./configure.

The #v() issue isn't *exactly* what's reported in bug #1250441, but
it falls under the same heading. Notice how I said "...the #v syntax for
gpasm currently only works for actual "symbols" and *not* defines."
ERROR and MESSG directives are treated almost the same way as #defines,
so gpasm just can't handle your usage quite right. I've been hacking
away at parsing problems like this one, but I've gotten bogged down
pretty badly in parsing hell. Not sure how it'll turn out.

David

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

[Borut Razem]

Just FYI:

gputils are meant to be compiled using the GNU autoconf/automake tools
and gcc compiler. I don't know if the OS/2 ports exists, but if they do,
then I would say that this is a preferred way to compile gputils.

But on the other hand it is always interesting to compile the
application with different compilers, since each of them shows different
potential problems, for example "Comparison result always 0" warning
with Watcom C/C++...

Borut


David wrote:

> On Fri, 04 Jul 2008 18:04:55 +0200
> Rob Hamerling <robhamerling@...> wrote:
>
>  
>> Hi David,
>>
>> ...
>> About building GPASM: I got a couple of warnings. This might be
>> related to the compiler I use, or related the macro defines like
>> HAVE_MALLOC_H, etc) in my makefile. Most warnings do not worry me
>> (like missing prototype for unlink). There is one that may be
>> important:
>>    
>>> parse.c(422): Warning! W129: #endif matches #if in different source
>>> file 'parse.y'
>>>      
>> I think there must be an '#endif' missing in parse.y
>>    
> There aren't any #if's in parse.y, and I can't find anything mismatched
> in any of the included files. Did you edit stdhdr.h? You mentioned
> problems with HAVE_MALLOC_H, and there's a double #if/#endif around a
> reference to HAVE_MALLOC_H in stdhdr.h. Is it possible you got confused
> there?
>
>  
>> Probably an issue with optimisation of LibGPUtils:
>>    
>>> gpcoffgen.c(434): Warning! W124: Comparison result always 0
>>> gpcoffgen.c(447): Warning! W124: Comparison result always 0
>>> gpprocessor.c(649): Warning! W124: Comparison result always 0
>>> gpprocessor.c(668): Warning! W124: Comparison result always 0
>>>      
> On this I have no idea, but the code does look a little suspicious w/
> the values it's comparing.
>
>  
>> An error I 'circumvented' by excluding vsnprintf from the library
>>    
>>> vsnprintf.c(42): Error! E1055: Unable to open 'config.h'
>>>      
>> I cannot find 'config.h', nor do I see any possible macro definition
>> to prevent it being included.
>>    
> config.h is supposed to be auto-generated from config.h.in when you
> run ./configure.
>
> The #v() issue isn't *exactly* what's reported in bug #1250441, but
> it falls under the same heading. Notice how I said "...the #v syntax for
> gpasm currently only works for actual "symbols" and *not* defines."
> ERROR and MESSG directives are treated almost the same way as #defines,
> so gpasm just can't handle your usage quite right. I've been hacking
> away at parsing problems like this one, but I've gotten bogged down
> pretty badly in parsing hell. Not sure how it'll turn out.
>
> David
>  

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

[Rob Hamerling-3]

Hi David,

David wrote:

>> I think there must be an '#endif' missing in parse.y

> There aren't any #if's in parse.y, and I can't find anything mismatched
> in any of the included files. Did you edit stdhdr.h? You mentioned
> problems with HAVE_MALLOC_H, and there's a double #if/#endif around a
> reference to HAVE_MALLOC_H in stdhdr.h. Is it possible you got confused
> there?

Confusion and user-errors are always possible!

I have not edited stdhdr.h, I have specified some macros on the
commandline of the compiler:
-DVERSION="0.13.6" &
-DHAVE_STRING_H    &
-DHAVE_STDLIB_H    &
-DHAVE_STRICMP     &
-DHAVE_MALLOC_H    &
-DYY_NO_UNISTD_H   &
-DHAVE_DOS_BASED_FILE_SYSTEM &
-DPACKAGE_BUGREPORT="robhamerling@..."

Well, since it is a 'warning' the compiler creates an proceeds


>> An error I 'circumvented' by excluding vsnprintf from the library
>>> vsnprintf.c(42): Error! E1055: Unable to open 'config.h'
>> I cannot find 'config.h', nor do I see any possible macro definition
>> to prevent it being included.
> config.h is supposed to be auto-generated from config.h.in when you
> run ./configure.

Ah, I have no experience with autoconf and automake!
I think there is no 'native' OS/2 version of these.
Maybe I could create config.h under Linux, I'll see.

>
> The #v() issue isn't *exactly* what's reported in bug #1250441, but
> it falls under the same heading. Notice how I said "...the #v syntax for
> gpasm currently only works for actual "symbols" and *not* defines."
> ERROR and MESSG directives are treated almost the same way as #defines,
> so gpasm just can't handle your usage quite right. I've been hacking
> away at parsing problems like this one, but I've gotten bogged down
> pretty badly in parsing hell. Not sure how it'll turn out.

Thanks for the explanation, I have removed the #v from these statements.

Regards, Rob.


--
Rob Hamerling, Vianen, NL (http://www.robh.nl/)

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

[Rob Hamerling-3]

Borut Razem wrote:
> Just FYI:
>
> gputils are meant to be compiled using the GNU autoconf/automake tools
> and gcc compiler. I don't know if the OS/2 ports exists, but if they do,
> then I would say that this is a preferred way to compile gputils.

There is a native OS/2 GCC compiler, and also a port of autoconf/make,
but this would require me to setup a sort of simulated Linux
environment.  Too much for me at this moment.

> But on the other hand it is always interesting to compile the
> application with different compilers, since each of them shows different
> potential problems, for example "Comparison result always 0" warning
> with Watcom C/C++...

I prefer to go into another direction than the masses..... hence still
OS/2?!
A feature of Watcom which I really like: it allows me to build under
OS/2 executables for OS/2, Linux and Windoze (and Dos). My XWisp2
program for the Wisp628/648 PIC programmers (and some other programs) is
built that way.

Regards, Rob.

--
Rob Hamerling, Vianen, NL (http://www.robh.nl/)

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

[Robert Pearce-3]

On Fri, 4 Jul 2008, David <daviebdawg@...> wrote :
>> > parse.c(422): Warning! W129: #endif matches #if in different source
>> > file 'parse.y'
>> I think there must be an '#endif' missing in parse.y
>There aren't any #if's in parse.y, and I can't find anything mismatched
>in any of the included files.
To my eye, that looks like a tool-chain "confusion" issue. I'd guess
that parse.c is built from parse.y (with bison), so the real problem is
likely to be a missing #line directive on the #endif. If so it's
probably safe to ignore.

That said, I've not looked too closely at the gpasm source, so I'm just
guessing.
--
Rob Pearce                       http://www.bdt-home.demon.co.uk

The contents of this | Windows NT crashed.
message are purely   | I am the Blue Screen of Death.
my opinion. Don't    | No one hears your screams.
believe a word.      |

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

[Rob Hamerling-3]

Hi David,

[RobH]
>> An error I 'circumvented' by excluding vsnprintf from the library
>>> vsnprintf.c(42): Error! E1055: Unable to open 'config.h'
>> I cannot find 'config.h', nor do I see any possible macro definition
>> to prevent it being included.

[David]
> config.h is supposed to be auto-generated from config.h.in when you
> run ./configure

Is 'config.h' of real importance (in my case)? Reason to ask:
- I didn't define HAVE_CONFIG_H and therefore the 'include config.h' is
   skipped by most modules, except libiberty/vsnprintf.c
- But when I comment out the 'include config.h' in vsnprintf.c I don't
   get any compiler error or warning
So it seems to me superfluous.

Regards, Rob.


--
Rob Hamerling, Vianen, NL (http://www.robh.nl/)

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

[David Barnett-3]

On Sat, 05 Jul 2008 17:58:25 +0200
Rob Hamerling <robhamerling@...> wrote:

>
> Hi David,
>
> ...
> Is 'config.h' of real importance (in my case)? Reason to ask:
> - I didn't define HAVE_CONFIG_H and therefore the 'include config.h'
> is skipped by most modules, except libiberty/vsnprintf.c
> - But when I comment out the 'include config.h' in vsnprintf.c I don't
>    get any compiler error or warning
> So it seems to me superfluous.

It's filled with #defines to select different options at build time. I

attached the config.h from my system so you can see what I mean. I
think most of the places you need it have #ifdefs, so that you won't
get "undefined" errors, you'll just have strange settings.

David
[config.h]

---

/* config.h.  Generated from config.h.in by configure.  */
/* config.h.in.  Generated from configure.ac by autoheader.  */

/* Define to one of `_getb67', `GETB67', `getb67' for Cray-2 and Cray-YMP
   systems. This function is required for `alloca.c' support on those systems.
   */
/* #undef CRAY_STACKSEG_END */

/* Define to 1 if using `alloca.c'. */
/* #undef C_ALLOCA */

/* Define if you want to enable GPUTILS debug features. */
/* #undef GPUTILS_DEBUG */

/* Define to 1 if you have `alloca', as a function or macro. */
#define HAVE_ALLOCA 1

/* Define to 1 if you have <alloca.h> and it should be used (not on Ultrix).
   */
#define HAVE_ALLOCA_H 1

/* Define to 1 if you don't have `vprintf' but do have `_doprnt.' */
/* #undef HAVE_DOPRNT */

/* Define if your host uses a DOS based file system. */
/* #undef HAVE_DOS_BASED_FILE_SYSTEM */

/* Define to 1 if you have the <inttypes.h> header file. */
#define HAVE_INTTYPES_H 1

/* Define to 1 if you have the <libintl.h> header file. */
#define HAVE_LIBINTL_H 1

/* Define to 1 if your system has a GNU libc compatible `malloc' function, and
   to 0 otherwise. */
#define HAVE_MALLOC 1

/* Define to 1 if you have the <malloc.h> header file. */
#define HAVE_MALLOC_H 1

/* Define to 1 if you have the `memmove' function. */
#define HAVE_MEMMOVE 1

/* Define to 1 if you have the <memory.h> header file. */
#define HAVE_MEMORY_H 1

/* Define to 1 if you have the `mempcpy' function. */
#define HAVE_MEMPCPY 1

/* Define to 1 if you have the `memset' function. */
#define HAVE_MEMSET 1

/* Define to 1 if your system has a GNU libc compatible `realloc' function,
   and to 0 otherwise. */
#define HAVE_REALLOC 1

/* Define to 1 if you have the <stddef.h> header file. */
#define HAVE_STDDEF_H 1

/* Define to 1 if you have the <stdint.h> header file. */
#define HAVE_STDINT_H 1

/* Define to 1 if you have the <stdlib.h> header file. */
#define HAVE_STDLIB_H 1

/* Define to 1 if you have the `strcasecmp' function. */
#define HAVE_STRCASECMP 1

/* Define to 1 if you have the `strchr' function. */
#define HAVE_STRCHR 1

/* Define to 1 if you have the `strdup' function. */
#define HAVE_STRDUP 1

/* Define to 1 if you have the `strerror' function. */
#define HAVE_STRERROR 1

/* Define to 1 if you have the `stricmp' function. */
/* #undef HAVE_STRICMP */

/* Define to 1 if you have the <strings.h> header file. */
#define HAVE_STRINGS_H 1

/* Define to 1 if you have the <string.h> header file. */
#define HAVE_STRING_H 1

/* Define to 1 if you have the `strrchr' function. */
#define HAVE_STRRCHR 1

/* Define to 1 if you have the `strtol' function. */
#define HAVE_STRTOL 1

/* Define to 1 if you have the `strtoul' function. */
#define HAVE_STRTOUL 1

/* Define to 1 if you have the <sys/stat.h> header file. */
#define HAVE_SYS_STAT_H 1

/* Define to 1 if you have the <sys/types.h> header file. */
#define HAVE_SYS_TYPES_H 1

/* Define to 1 if you have the <unistd.h> header file. */
#define HAVE_UNISTD_H 1

/* Define to 1 if you have the `vprintf' function. */
#define HAVE_VPRINTF 1

/* Define to 1 if you have the <windows.h> header file. */
/* #undef HAVE_WINDOWS_H */

/* Name of package */
#define PACKAGE "gputils"

/* Define to the address where bug reports for this package should be sent. */
#define PACKAGE_BUGREPORT "<URL:http://gputils.sourceforge.net/>"

/* Define to the full name of this package. */
#define PACKAGE_NAME "gputils"

/* Define to the full name and version of this package. */
#define PACKAGE_STRING "gputils 0.13.6"

/* Define to the one symbol short name of this package. */
#define PACKAGE_TARNAME "gputils"

/* Define to the version of this package. */
#define PACKAGE_VERSION "0.13.6"

/* If using the C implementation of alloca, define if you know the
   direction of stack growth for your system; otherwise it will be
   automatically deduced at runtime.
        STACK_DIRECTION > 0 => grows toward higher addresses
        STACK_DIRECTION < 0 => grows toward lower addresses
        STACK_DIRECTION = 0 => direction of growth unknown */
/* #undef STACK_DIRECTION */

/* Define to 1 if you have the ANSI C header files. */
#define STDC_HEADERS 1

/* Define to 1 if your <sys/time.h> declares `struct tm'. */
/* #undef TM_IN_SYS_TIME */

/* Define if you want to add default search paths. */
#define USE_DEFAULT_PATHS 1

/* Version number of package */
#define VERSION "0.13.6"

/* Define to 1 if `lex' declares `yytext' as a `char *' by default, not a
   `char[]'. */
#define YYTEXT_POINTER 1

/* Define to empty if `const' does not conform to ANSI C. */
/* #undef const */

/* Define to rpl_malloc if the replacement function should be used. */
/* #undef malloc */

/* Define to rpl_realloc if the replacement function should be used. */
/* #undef realloc */

/* Define to `unsigned int' if <sys/types.h> does not define. */
/* #undef size_t */

---

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

[Rob Hamerling-3]

Hi David,

David wrote:
> I attached the config.h from my system so you can see what I mean. I
> think most of the places you need it have #ifdefs, so that you won't
> get "undefined" errors, you'll just have strange settings.

I managed to get an OS/2 version of GPASM working and it seems to work
without problems. I got several working PIC programs.
One test I did was to assemble the Wisp648 firmware. It is written in
Jal, but I assembled the ASM output from the JalV2 compiler. I got
identical hex files.

I tested some (not all) of the other utils (e.g. GPDASM) and encountered
no problems, so I assume the others will work as well.

I have put the OS/2 version of GPutils on my site and on Hobbes
(http://hobbes.nmsu.edu/). The 'GPUTILS OS/2' link on the gputils page
will point to the current version 0.13.6 (and some ancient versions!).

Regards, Rob.


--
Rob Hamerling, Vianen, NL (http://www.robh.nl/)

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