gnupic: Thread: gpasm-0.8.3.tar.gz

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

- added more processors
- fixed install bug - if the directory for the special.inc file is
non-existant, make install will go ahead and create it. 

Btw, In developing the 18cxxx support for gpasm I found that I could not
use the 'special.inc' file. Mainly because of the hardcoded references to
the status register. So I came up with a way to support multiple
instruction sets for one processor. We could do away with 'special.inc'
very easily. But I don't want to fix everything that's not broken. Can
anyone provide a good reason one way or the other about whether
'special.inc' should exist?

On Fri, Jan 07, 2000 at 07:55:09AM -0600, Scott Dattalo wrote:
> Can anyone provide a good reason one way or the other about whether
> 'special.inc' should exist?

It is plain text documentation, it is exhibited by strace during a run
of gpasm, and users can tailor it without having to rebuild gpasm.

Or maybe I've misunderstood what you plan to do with it?

-- 
James Cameron   ####@####.####   http://quozl.us.netrek.org/

On Mon, 10 Jan 2000, James Cameron wrote:

> On Fri, Jan 07, 2000 at 07:55:09AM -0600, Scott Dattalo wrote:
> > Can anyone provide a good reason one way or the other about whether
> > 'special.inc' should exist?
> 
> It is plain text documentation, it is exhibited by strace during a run
> of gpasm, and users can tailor it without having to rebuild gpasm.
> 
> Or maybe I've misunderstood what you plan to do with it?

First, it's not used for the 18cxxx stuff. The reason is that some of the
macros defined in special.inc are instructions in the 18cxxx instruction
(e.g. bc, bra, etc.). I tried to create another 'special.inc' file for the
18cxxx instruction set but I abandonded it (for reasons I can't recall).

My view on include files (which all special.inc is) is to have the code
that needs them be responsible for the including. If, OTOH, the macros are
part of the assembler then they should be part of the assembler code. I
realize that this is an opinion and so I haven't made the change in gpasm.
The only reason I bother to mention it is that I found another way to
incorporate additional instruction sets within the infrastructure of
gpasm. For example, the 18cxxx instruction set is derived from two
separate instruction sets: op_18cxx[] consists of the mnemonics found in
the data sheet, while op_18cxx_sp[] consists of macros (like clrc). The
same could be done for the 14 and 12 bit cores too.

There are a few benefits. First, if someone wishes to install gpasm in a
directory other than where make install places it then the executable can
be copied without having to worry about the 'special.inc' file. Although,
with the new automake I believe it's possible to specify the install
directory during ./configure . Second, if we want to support the parallax
version of the instructions it would be fairly simple to select the
instruction set based on a compiler flag. Third, the sx instructions
currently duplicate the entire 12bit instruction and adds in the few
additional sx-specific instructions. These additional instructions could
be loaded separately.

Each of these points is not strong enough to motivate me to go changing
things around. This is one of those it ain't exactly broke kinda things...
so why go fix it? That's why I wanted to get some feed back from others.

Thanks James,

Scott

On Mon, Jan 10, 2000 at 08:36:43AM -0600, Scott Dattalo wrote:
> First, it's not used for the 18cxxx stuff. The reason is that some of the
> macros defined in special.inc are instructions in the 18cxxx instruction
> (e.g. bc, bra, etc.). I tried to create another 'special.inc' file for the
> 18cxxx instruction set but I abandonded it (for reasons I can't recall).

Why not just place the code in special.inc within processor specific
conditional assembly sections?

#ifdef __18cxxx
#endif

> Although, with the new automake I believe it's possible to specify 
> the install directory during ./configure [...]

Yes.  ./configure --prefix=/usr

-- 
James Cameron   ####@####.####   http://quozl.us.netrek.org/