gnupic: Question about #v() in macro invocation
Subject:
Question about #v() in macro invocation
From:
####@####.#### (Byron A Jeff)
Date:
23 Feb 2002 02:40:00 -0000
Message-Id: <200202230235.g1N2Z4Y29025@cleon.cc.gatech.edu>
Hi folks,
Over on the PICLIST a new PIC user introduced himself and asked about Linux
based PIC development tools. After seeing the rather lame suggestions of
'mpasm + dosemu' and the snide remark about Linux users having an "attitude
problem" and "insist on not using Windows" (totally uncalled for IMHO) I
pointed the gentleman to the gputils pointing out that it was almost as good
as MPASM.
This exchange reminded me that one area where gpasm still generates errors
is in the area of #v() processing. So I decided to spend a couple of hours
checking out what the problems are.
First thing I did is add a bit a code in scan.l so that I could dynamically
control parse debugging info from comments in the source code. Here's the
change:
---BEFORE-----------
;.* { }
---AFTER------------
;.* { extern int yydebug;
char *rv;
if (rv=strstr(yytext,"YY"))
yydebug = rv[2] - '0'; }
. {
--------------------
Now a comment of
; YY1
Turns on parse debugging while:
; YY0
turns it off. So You can generate the parse debugging output for a single
faulty line.
Tool in hand, I waded into my critical application: WLoader written by Wouter
van Ooijen (http://www.voti.nl/wloader). Wouter loves macros, conditional
compilation, and the use of the #v() to do dynamic text selection. Here's a
concise sample of his style of work:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
test1 macro ; Dummy macro 1
cblock ; Declare a local variable
testme1#v($) ; ERROR!!!
endc
local test = testme1#v($) ; rename local var defined above 'test'
movlw test ; Then use it.
endm
test2 macro ; Same as macro above.
cblock
testme2#v($) ; ERROR!!!
endc
local test = testme2#v($)
movlw test
endm
whichtest macro select ; Combining macro that selects
; between the two above.
test#v(select) ; ERROR!!!
endm
whichtest(1) ; Show use of whichtest
whichtest(2)
end
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Now the primary problem is that the parser doesn't allow for a cidentifier
to be on a line by itself as a statement. So each of the lines marked ERROR!!!
fail to parse. This is because cidentifier is considered only to be part of
an expression and not a statement.
The secondary issues is that even if a cidentifier is allowed to parse, that
processing it is going to be an issue. What needs to happen is that there needs
to be a text substitution of the value of the #v(expr). Then the result of
that concatenation needs to be treated as an identifier and reprocessed.
And it gets tougher because those error lines are going to have to be
untouched until the macro is involked. But cidentifier breaks down the line
into a CONCAT tree so saving the original isn't going to be very much fun.
Maybe we simply need a new parse rule and another utility function that will
generate the correct identifier depending on if we're in macro.
So that's the tack I'm going to take. I'll spend another hour at it tonight
and report any progress in the morning.
BAJ
