[<<] [<] Page 2 of 2 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: gpasm
From: Craig Franklin ####@####.#### Date: 18 May 2001 22:42:15 -0000 Message-Id: <3B05A684.B6949BC3@home.com> 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 -- ####@####.#### | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
gpasm
From: John Duncan ####@####.#### Date: 4 Jan 2002 09:52:09 -0000 Message-Id: <3.0.1.32.20020102095044.006df35c@postoffice.qld.bom.gov.au> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
gpasm
From: Philip Balister ####@####.#### Date: 15 Apr 2002 13:24:05 -0000 Message-Id: <20020415091650.B17989@nemesis.maddog.net> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: gpasm
From: Anthony Tekatch ####@####.#### Date: 15 Apr 2002 13:31:16 -0000 Message-Id: <20020415092639.56aa51d1.anthony@unihedron.com> > 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: gpasm
From: Craig Franklin ####@####.#### Date: 5 Apr 2003 22:17:49 -0000 Message-Id: <3E8F5331.759315D2@attbi.com> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: gpasm
From: Scott Dattalo ####@####.#### Date: 6 Apr 2003 03:05:07 -0000 Message-Id: <Pine.LNX.4.44.0304051847150.28594-100000@ruckus.brouhaha.com> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: gpasm
From: Craig Franklin ####@####.#### Date: 7 Apr 2003 01:02:35 -0000 Message-Id: <3E90D8F9.4B89F9DE@attbi.com> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: gpasm
From: "Martin Dubuc" ####@####.#### Date: 6 Apr 2003 21:30:58 -0000 Message-Id: <00be01c2fc81$8f509980$010210ac@flfrd.phub.net.cable.rogers.com> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 2 of 2 [>] [>>] |