gnupic: Thread: Re: [gnupic] GPasm maint

On Fri, 04 Jul 2008 09:32:22 +0200
Rob Hamerling ####@####.#### 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

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/)

On Fri, 04 Jul 2008 18:04:55 +0200
Rob Hamerling ####@####.#### 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

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

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

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/)

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/)

On Fri, 4 Jul 2008, David ####@####.#### 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.      |

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/)

On Sat, 05 Jul 2008 17:58:25 +0200
Rob Hamerling ####@####.#### 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

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/)