gnupic: Re: [gnupic] Re: debugging gpasm
Subject:
Re: [gnupic] Re: debugging gpasm
From:
David ####@####.####
Date:
19 Mar 2007 03:39:15 +0000
Message-Id: <20070318223406.33d3be32@DEEPTHOUGHT.BARNET.net>
On Sun, 18 Mar 2007 10:58:45 -0400
Byron A Jeff ####@####.#### wrote:
> On Sun, Mar 18, 2007 at 08:23:52AM -0500, David wrote:
> > I'm trying to patch up some of the bugs with text substitution from
> > the bug tracker, but I'm not getting very far without gdb. BTW, I'm
> > currently looking into bug #1250441 with the #v syntax. I added
> > some comments about some interesting developments.
>
> As soon as I saw the #v syntax, memories came flooding back. It's
> definitely broken.
Yes, I know. Traumatic, isn't it? I added some more comments to the
effect that the problem is much more complicated than I expected
(but at least I know what it is now). I was hoping to add some small
features to find my way around gputils, but it turned out to need sort
of an overhaul. I may need to work on something else until I get a
better feel for the architecture.
On that note, I've done some thinking about how the different text
substitutions interact. The categories I can think of are assembler
variables, #defines, #v substitutions, and macros. gpasm enforces a
sort of hierarchy to them, which simplifies some things, but I think
each of them can be nested in each of the others. MPASM makes 8 passes
and then gives up on any remaining relocations, I think without any
concept of precedence. I don't like the arbitrary restriction since
any code could happen to just barely need 9 passes, and then it would
be difficult to work around the limitation. I think for gpasm to fix
all of the related bugs, it will need to do away with the hierarchy,
but we should be able to detect infinite recursion so that we can
provide arbitrary levels of nesting.
Does anyone disagree or have any comments?
David
