gnupic: gpasm-0.8.3.tar.gz
Subject:
Re: gpasm-0.8.3.tar.gz
From:
Scott Dattalo ####@####.####
Date:
10 Jan 2000 14:48:25 -0000
Message-Id: <Pine.LNX.4.05.10001100812390.26030-100000@tempest.blackhat.net>
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
