gnupic: Thread: gpasm

I was interrupted last weekend during the release.  The
gpasm.sourceforge.net wasn't updated.  I have been out of town on
business all week.

I will update the website and make a release announcement later tonight.

Samuel Tardieu wrote:
> 
> Yes, why, is it out of date?
> --
> Samuel Tardieu -- ####@####.####

Hello Listers,

I have recently had a bit of a problem with gpasm, that I am hoping
someone may be able to explain.  I have an include file of subroutines
forreading and writing MChip I2C EEPROMS, that I use in my hobby
dataloggers.  The type of EEPROM chip is defined in the main source file,
before the file is included.  

Much of the code is common for different EEPROM chips, but the steps to
address a 24LC16B are different from a 24LC256.  The diffences are defined
as macros and these macros are invoked in the body of the code.  The macros
to use are selected by the type of EEPROM chip defined.

I have been using gpasm 0.9.6 for some time.  I have recently upgraded to
0.9.14 , but have not had to assemble this code, until a couple of days
ago.   gpasm 0.9.6 would assemble the code, without sneezing, but 0.9.14
will generate a warning telling me that I am callng a macro in column 1,
when in fact what I am doing is defining a macro, but that macro is not in
a block for which the condition is true.  I don't think that my description
make a lot of sense, so I have included below a small test file that
demonstates what I mean

  
; mactest.asm --
;   A simple test to recreate the funny with conditional
;   selection of macros


      list p=16f84            

	ifdef foo
mac1 macro
	nop
	sleep
	endm
	endif
	
	ifndef foo
mac1 macro
	nop
	clrwdt
	endm
	endif
	
	org 0
	mac1

        end

Assemble with and without defining foo

condamine:~/d501/picsrc$ gpasm mactest.asm
mactest.asm:10:Warning [206] Found call to macro in column 1.
condamine:~/d501/picsrc$ 

condamine:~/d501/picsrc$ gpasm -Dfoo mactest.asm
mactest.asm:17:Warning [206] Found call to macro in column 1.
condamine:~/d501/picsrc$


Could this be a bug or am I missing something?  

Cheers

JD

I was looking on the sourceforge site for a tarball of gpasm. I didn't
see one. Is there a tar file of a current working version somewhere,
or do I need to figure out CVS?

Thanks,

Philip

> I was looking on the sourceforge site for a tarball of gpasm. I didn't
> see one. Is there a tar file of a current working version somewhere,
> or do I need to figure out CVS?

Check here:

  http://gputils.sourceforge.net/

gpasm is included in gputils now.

-- 
Anthony Tekatch

Your interest is probably for the SDCC pic target?  I have cc'ed the
gnupic list.  I think most of SDCC developers are listening.

I have put in a lot of work.

There are a couple of minor bugs in the gpasm coff output, but I believe
all devices are working.  All but two of the gpasm coff test files are
passing.

gputils-0.11.0 was the first version with a functional linker (gplink)
and archive tool (gplib).  I have been using them with 14 bit devices,
things seem to be working.  My next big task is to write test files and
fix bugs.

You are probably interested in linking 18xx objects.  I havn't tried. 
There are probably some big bugs that I don't know about.  The test
files should help me fix them.

I am encouraged by what has been accomplished, but realistically it will
take a few more minor releases (6-8 weeks) before gplink will be alpha
for all devices.  I am calling it pre-alpha now.  I would like SDCC to
start using the linker.  This will help to uncover the bugs faster.

I wish I had some time to put into SDCC, but it just hasn't been
possible.  There has been too much work on the backend.  As I stated
before, I have an SDCC patch started.  Some of the basics are taken care
of, but not much more.  I think I will clean up what I have and send to
to everyone.  Give me a couple of days.  Maybe Scott can make an SDCC
cvs branch for the relocatable changes.

> Martin Dubuc wrote:
> 
> Craig,
> 
> Have you worked on gpasm the past few months? I am curious to learn
> about the ongoing improvments. Have you worked on relocation/link?
> 
> Martin

On Sat, 5 Apr 2003, Craig Franklin wrote:

> Your interest is probably for the SDCC pic target?  I have cc'ed the
> gnupic list.  I think most of SDCC developers are listening.
> 
> I have put in a lot of work.
> 
> There are a couple of minor bugs in the gpasm coff output, but I believe
> all devices are working.  All but two of the gpasm coff test files are
> passing.
> 
> gputils-0.11.0 was the first version with a functional linker (gplink)
> and archive tool (gplib).  I have been using them with 14 bit devices,
> things seem to be working.  My next big task is to write test files and
> fix bugs.
> 
> You are probably interested in linking 18xx objects.  I havn't tried. 
> There are probably some big bugs that I don't know about.  The test
> files should help me fix them.
> 
> I am encouraged by what has been accomplished, but realistically it will
> take a few more minor releases (6-8 weeks) before gplink will be alpha
> for all devices.  I am calling it pre-alpha now.  I would like SDCC to
> start using the linker.  This will help to uncover the bugs faster.
> 
> I wish I had some time to put into SDCC, but it just hasn't been
> possible.  There has been too much work on the backend.  As I stated
> before, I have an SDCC patch started.  Some of the basics are taken care
> of, but not much more.  I think I will clean up what I have and send to
> to everyone.  Give me a couple of days.  Maybe Scott can make an SDCC
> cvs branch for the relocatable changes.

I'm starting to get back on to SDCC. I'll look at transitioning to gplink.

Also Martin and I have started discussing how the pic16 and pic14 ports of
SDCC need to be more tightly integrated. Many of the basic snippets that 
the two ports generate are identical. I not sure how we can do this 
without generating major spaghetti code...

Scott

So far, it works very much like the mplink.  I have attached some of its
manuals to:

http://gputils.sourceforge.net/#Support

The gputils docs will be updated, but probably not for a while.

I highly recommend that you fetch the sources from cvs and periodically
update.  Although I havn't commited any changes since 0.11.1, some are
in the pipeline.

Keep me updated on any success or failure that you have.  Having others
use the linker will really help me out.

Martin Dubuc wrote:
> 
> Craig,
> 
> I am really impressed with what you have achieved so far. I really like the
> fact that SDCC can make use of a linker. This should make for smaller
> programs.
> 
> One thing I have noticed porting SDCC to PIC18F is that the problem of bank
> selection is not as prevalent in PIC18F because all registers are in the
> same bank. Actually, the first bank contains all registers and 128 bytes
> that can be used for RAM. If a program uses little RAM, then, it is possible
> that no bank selection will be required! This should also make the code much
> smaller.
> 
> I will have some time free in a week or two. I would like to try the linker
> with PIC18F to see if it works. Can you give me some instructions on how to
> use it (or is it documented anywhere on the gpasm/gplink Web page)?
> 
> Thanks,
> 
> Martin
> 
> ----- Original Message -----
> From: "Craig Franklin" ####@####.####
> To: "Martin Dubuc" ####@####.####
> Cc: ####@####.####
> Sent: Saturday, April 05, 2003 6:05 PM
> Subject: Re: gpasm
> 
> > Your interest is probably for the SDCC pic target?  I have cc'ed the
> > gnupic list.  I think most of SDCC developers are listening.
> >
> > I have put in a lot of work.
> >
> > There are a couple of minor bugs in the gpasm coff output, but I believe
> > all devices are working.  All but two of the gpasm coff test files are
> > passing.
> >
> > gputils-0.11.0 was the first version with a functional linker (gplink)
> > and archive tool (gplib).  I have been using them with 14 bit devices,
> > things seem to be working.  My next big task is to write test files and
> > fix bugs.
> >
> > You are probably interested in linking 18xx objects.  I havn't tried.
> > There are probably some big bugs that I don't know about.  The test
> > files should help me fix them.
> >
> > I am encouraged by what has been accomplished, but realistically it will
> > take a few more minor releases (6-8 weeks) before gplink will be alpha
> > for all devices.  I am calling it pre-alpha now.  I would like SDCC to
> > start using the linker.  This will help to uncover the bugs faster.
> >
> > I wish I had some time to put into SDCC, but it just hasn't been
> > possible.  There has been too much work on the backend.  As I stated
> > before, I have an SDCC patch started.  Some of the basics are taken care
> > of, but not much more.  I think I will clean up what I have and send to
> > to everyone.  Give me a couple of days.  Maybe Scott can make an SDCC
> > cvs branch for the relocatable changes.
> >
> > > Martin Dubuc wrote:
> > >
> > > Craig,
> > >
> > > Have you worked on gpasm the past few months? I am curious to learn
> > > about the ongoing improvments. Have you worked on relocation/link?
> > >
> > > Martin

Craig,

I am really impressed with what you have achieved so far. I really like the
fact that SDCC can make use of a linker. This should make for smaller
programs.

One thing I have noticed porting SDCC to PIC18F is that the problem of bank
selection is not as prevalent in PIC18F because all registers are in the
same bank. Actually, the first bank contains all registers and 128 bytes
that can be used for RAM. If a program uses little RAM, then, it is possible
that no bank selection will be required! This should also make the code much
smaller.

I will have some time free in a week or two. I would like to try the linker
with PIC18F to see if it works. Can you give me some instructions on how to
use it (or is it documented anywhere on the gpasm/gplink Web page)?

Thanks,

Martin

----- Original Message -----
From: "Craig Franklin" ####@####.####
To: "Martin Dubuc" ####@####.####
Cc: ####@####.####
Sent: Saturday, April 05, 2003 6:05 PM
Subject: Re: gpasm


> Your interest is probably for the SDCC pic target?  I have cc'ed the
> gnupic list.  I think most of SDCC developers are listening.
>
> I have put in a lot of work.
>
> There are a couple of minor bugs in the gpasm coff output, but I believe
> all devices are working.  All but two of the gpasm coff test files are
> passing.
>
> gputils-0.11.0 was the first version with a functional linker (gplink)
> and archive tool (gplib).  I have been using them with 14 bit devices,
> things seem to be working.  My next big task is to write test files and
> fix bugs.
>
> You are probably interested in linking 18xx objects.  I havn't tried.
> There are probably some big bugs that I don't know about.  The test
> files should help me fix them.
>
> I am encouraged by what has been accomplished, but realistically it will
> take a few more minor releases (6-8 weeks) before gplink will be alpha
> for all devices.  I am calling it pre-alpha now.  I would like SDCC to
> start using the linker.  This will help to uncover the bugs faster.
>
> I wish I had some time to put into SDCC, but it just hasn't been
> possible.  There has been too much work on the backend.  As I stated
> before, I have an SDCC patch started.  Some of the basics are taken care
> of, but not much more.  I think I will clean up what I have and send to
> to everyone.  Give me a couple of days.  Maybe Scott can make an SDCC
> cvs branch for the relocatable changes.
>
> > Martin Dubuc wrote:
> >
> > Craig,
> >
> > Have you worked on gpasm the past few months? I am curious to learn
> > about the ongoing improvments. Have you worked on relocation/link?
> >
> > Martin