gnupic: Re: [gnupic] gpasm: .direct macro doesn't work
Subject:
Re: [gnupic] gpasm: .direct macro doesn't work
From:
David ####@####.####
Date:
6 Oct 2007 18:54:43 +0100
Message-Id: <20071006135159.1daad742@DEEPTHOUGHT.BARNET.net>
On Fri, 5 Oct 2007 21:44:06 -0700 (PDT)
"Scott Dattalo" ####@####.#### wrote:
> On Fri, 2007-10-05 at 22:19 -0400, David wrote:
> > I think I know exactly what's happening now. Prior to 6/17/07 a
> > single-character string literal was considered identical to a
> > character literal. For example "e" meant the same as 'e'. This was
> > a hack for some fancy coercion in MPLAB and meant that it was
> > impossible to represent the string literal "e".
>
> Hi David,
>
> Maybe I don't understand the whole issue, but would it have made more
> sense to keep the parser and lexer the same and make the coercion
> decisions at a higher level?
The changes to the lexer and some of the changes to the parser are
absolutely necessary to make any coercion decisions possible at higher
levels. In the past the lexer made the decision at the beginning for all
levels. You can see now that decision is deferred to 2 places at higher
levels.
> For example, based on the hints you gave me here, I made a simple
> change to the 'do_direct()' function.
That is similar to what I had in mind, and it certainly won't cause
any problems for the time being. I totally understand your rush to
patch it over and get back to gpsim issues. My concern was that if
possible I don't want to do this case-by-case and bit-by-bit, and I'm
fairly certain the '.direct' directive isn't the only place we'll see
this issue. I'm hoping to find one or a few places to put most of the
coercions for "any directive expecting a character literal but not
string literal". So far we have for that category: 8-bit literal
instruction operands + expression operands + the first operand
of .direct, and you can see how the 3rd category sounds a lot more
specific. Could be it's not much of a problem, and it could be there's
no other option, but I'm hoping not to sprinkle these changes through
the sources.
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.
> BTW, I ran the test suite and found that there are several failures
> there (I verified this change add no new ones). Should we be
> concerned about these.
You're talking about the gpsim test suite, right? I had only been
keeping an eye on gputils regression tests, but if I'm making your
tests fail it means you've got expectations of gputils that I'm not
fulfilling, and we should definitely take a hard look at that.
David Barnett
