gnupic: Thread: Re: [gnupic] gpasm: #v support

On Mon, 08 Oct 2007 09:17:29 -0700
Scott Dattalo ####@####.#### wrote:

> David wrote:
> 
> with regards to gpasm regression test failures
> ...
> I just looked in there to see that the #v tests are present.
> Maybe I can take a look at adding support for these.
I had a look at that at one time, so I'll tell you what I found so
far. I explained a lot of this in different wording in this bug report:
http://sourceforge.net/tracker/index.php?func=detail&aid=1250441&group_id=41924&atid=431665

There is very limited support for #v syntax right now, but you'd hardly
notice it's there at all. The symbol-matching part only looks up
"symbols", which don't include #define substitutions. The most
"architectural" gotcha is that the arity is assumed 1 *before* the
substitution. You'll pbb see what I mean if you go digging through the
code, but in the example on the bug report, that explains why "bsf
sol_beer#v(1)" will be "missing" the bit argument even though it should
evaluate to "bsf portd, 4".

I think the solution might involve moving the #v substitution from the
parser back up to the lexer, because #defines need to be able to rescan
the substituted text. Look for the {IDENT} rule in gpasm/scan.l and in
particular the "push_string(buffer)" line to see how normal #define
substitution does it now. (I consider this push_string line a hack, but
if I ever fix it, it will be just as easy to fix in 2 places as it
would be in 1).

> Do you know if we still receive regression tests from Microchip?
I haven't asked them about it, but my impression was they gave us a big
batch of regression tests at once (gpasm.mchip). I think it said
something in there like they weren't obligated to give us tests in the
future or something, but it sounded like they would be glad to give us
what they have if we asked again.

David Barnett

David wrote:
> I think the solution might involve moving the #v substitution from the
> parser back up to the lexer, ...

I agree that the #v() syntax needs to handled in the lexer. 
Specifically, we need to create a new lexer mode.

>> Do you know if we still receive regression tests from Microchip?
>>     
> I haven't asked them about it, but my impression was they gave us a big
> batch of regression tests at once (gpasm.mchip). I think it said
> something in there like they weren't obligated to give us tests in the
> future or something, but it sounded like they would be glad to give us
> what they have if we asked again.
>   

I'm not aware of any significant changes to the MPASM language in the 
last few years. So the set of tests we have now are probably adequate. 
And considering that there are quite of few we don't support, there's 
plenty to work on for now.

Scott