gnupic: Re: [gnupic] Re: debugging gpasm
Subject:
Re: [gnupic] Re: debugging gpasm
From:
Byron A Jeff ####@####.####
Date:
19 Mar 2007 11:13:36 +0000
Message-Id: <20070319111307.GA13037@cleon.cc.gatech.edu>
On Sun, Mar 18, 2007 at 10:34:06PM -0500, David wrote:
> 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?
My instant gut thought is first think through what the common usage would be
and figure out if the current infrastructure can support it. A complete
overhaul would be painful I think.
BAJ
