gnupic: Re: [gnupic] gpasm: .direct macro doesn't work
Subject:
Re: [gnupic] gpasm: .direct macro doesn't work
From:
David ####@####.####
Date:
8 Oct 2007 16:53:06 +0100
Message-Id: <20071008114844.08b5f3f4@DEEPTHOUGHT.BARNET.net>
On Mon, 8 Oct 2007 07:22:39 -0700 (PDT)
"Scott Dattalo" ####@####.#### wrote:
> On Sat, 2007-10-06 at 13:51 -0400, David wrote:
> > I know you're not too much on top of the intricacies of gputils,
> > but I thought you or someone else might have some ideas or concerns
> > I'm not thinking of.
>
> In my opinion, the character literal and strings are fundamental
> types and should be kept separate up to the point where the language
> is unambiguous and can perform an implicit type cast. I don't think
> the MPASM language is rigorous enough to say that *all* single
> character strings can be treated as literal characters.
I definitely agree. I'm not sure if you missed this point, but the
original bug report was that DA "x" put 1 byte ('x') instead of 2 ('x',
'\0') into memory, because it coerced to a character when a string
would have worked. I believe MPLAB behaves as expected (surprised?) on
that point. So there are times when the coercion *needs* to be late, and
fixing that led to your bug. Now instead of "too much" of the feature
changing correct behavior, there's "too little" of it so that things
like .direct "e" weren't being coerced.
FYI, I think the "evaluate" function in gpasm/evaluate.c gives me a
"choke point" to coerce most (all?) string literals that must have a
character value. It's supposed to return an integer type for a given
expression, so the caller should always expect a character and never a
string (strings don't have integer values). There's a bit of a
side-effects vs. redundancy issue with the "can_evaluate" function, but
it seems like the way to go, anyway. I'll give it a little more thought
before I change it in CVS.
> >> BTW, I ran the test suite and found that there are several failures
> > You're talking about the gpsim test suite, right?
>
> Actually no, I'm talking about gpasm.
Ah, yes. Those aren't new at all. If you remember from the discussion
way back when, there was a typo in the test scripts that hid some
failures. Those errors have AFAIK always been there, and we're just
slowly working toward full MPASM compatibility. I seem to remember a
lot of those failures are caused by one bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=564641&group_id=41924&atid=431668
Instead of giving warnings like "Warning: directive found in column 1",
gpasm completely ignores things with the wrong indentation and fails
from side-effects.
Anyway, I fixed the typo way back then but also commented out the
failure part until we iron out those errors. I just diff the output
from one test run to the next to check for new errors for now.
David Barnett
