gnupic: Update on #v()


Previous by date: 23 Feb 2002 13:46:02 -0000 Question about #v() in macro invocation, Byron A Jeff
Next by date: 23 Feb 2002 13:46:02 -0000 Re: Update on #v(), Craig Franklin
Previous in thread:
Next in thread: 23 Feb 2002 13:46:02 -0000 Re: Update on #v(), Craig Franklin

Subject: Update on #v()
From: ####@####.#### (Byron A Jeff)
Date: 23 Feb 2002 13:46:02 -0000
Message-Id: <200202231341.g1NDf5b21400@cleon.cc.gatech.edu>

To recap:

> 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.
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> 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
> ; [Deleted for brevity ] 
> 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
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

The parse doesn't currently allow for the two lines commented with 'ERROR!!!'.
The first is a 'const_line' and the second in an statement.

My initial line of thinking was that the expression in the #v(expr) should not
be parsed in a macro context. But rethinking on it a bit, I realized that
the parser must be parsing normal expressions. So to test I ran this:
;;;;;;;;;;;;;;;;;;;;;;;
testme	macro	n1,n2
	movlw	1*(n1+n2)
	endm
;;;;;;;;;;;;;;;;;;;;;;;

And sure enough the expression was parsed in its entirety. So that means that
the macro gathering code retains parsed expressions.

OK so we clearly need to go with that flow and allow the expression in the
#v(expr) to be parsed. That throws out all the ideas I had of making a syntax
change in macro context forcing #v(expr) to become #v(string).

label_concat kind of points out the right direction. It allows for both a
label and a VARLAB_BEGIN which has a #v(expr) in it. But it disallows this
type of label in a macro context. This needs to be fixed.

So this is what the problem reduces to is how to represent a parsed #v(expr)
tree in a spot where and INDENTIFIER or LABEL goes. And specifically so that
it can be stored in a macro context and be properly evaluated upon macro
invocation.

So it's off to figure off what evaluate_macro does with both expressions and
INDENTIFIERS. It may just be as simple as adding a new type of node...

Let me know if anyone else has any ideas.

BAJ

Previous by date: 23 Feb 2002 13:46:02 -0000 Question about #v() in macro invocation, Byron A Jeff
Next by date: 23 Feb 2002 13:46:02 -0000 Re: Update on #v(), Craig Franklin
Previous in thread:
Next in thread: 23 Feb 2002 13:46:02 -0000 Re: Update on #v(), Craig Franklin


Powered by ezmlm-browse 0.20.