gnupic: Update on #v()
Subject:
Re: Update on #v()
From:
Craig Franklin ####@####.####
Date:
23 Feb 2002 17:39:01 -0000
Message-Id: <3C77D297.99BF6095@attbi.com>
Several monthes ago I started working on the macro problems. I have
mentioned it few times on this list. I havn't had enough time to finish
the work I started. Over the last couple of monthes my paying job has
sucked every bit of life out of me.
At the core of this and many other problems is the way macros are
handled. Macros should be a simple text substitutions.
Last weekend I created a patch against 0.10.0 that includes all of my
fixes. I will create a branch in cvs and apply the patch. We can play
with it for a couple of weeks then release it if all goes well. Give me
48 hours to put everything in cvs. I will send out a message with
instructions when everything is ready.
Below is one of my test files. It demonstrates that things are fairly
close but there are still some problems.
gpasm-0.10.0 alpha macro.asm 2-23-2002 11:26:59
PAGE 1
LOC OBJECT CODE LINE SOURCE TEXT
VALUE
00001 processor 16c84
00002
00003 list n=0
00004
00000005 00005 craig equ 5
00006
00007 test1 macro number1, number2, number3, number4
00008 movlw number1
00009 fill (movlw number2), number3
00010 movlw number4
00011 endm
00012
00013 test2 macro string
00014 messg string
00015 endm
00016
00017 test3 macro string
00018
00019 string equ 5
00020
00021 endm
00022
00023 test4 macro number, value
00024 label_#v(number) equ value
00025 endm
00026
00027 test5 macro number
00028 if (number==1)
00029 exitm
00030 else
00031 movlw 0
00032 endif
00033 movlw 0
00034 endm
00035
00036 #include "test.inc"
00001
0000 3005 00002 movlw 5
00037
00038 test1 1, 2, 3, craig
0001 3002 3002 M fill (movlw number2), number3
0003 3002
0004 3005 M movlw number4
00039
00040 test2 "hello"
Message [301] : hello
M messg string
00041
00042 test3 franklin
M
00000005 M string equ 5
M
00043
00044 test4 3, 4
00000004 M label_#v(number) equ value
00045
00046 test5 0
M if (number==1)
M exitm
M else
0005 3000 M movlw 0
M endif
0006 3000 M movlw 0
00047
00048 test5 1
M if (number==1)
M exitm
00049
0007 3005 00050 movlw 5
00051
Warning [212] : Expected (ENDIF)
gpasm-0.10.0 alpha macro.asm 2-23-2002
11:26:59 PAGE 2
SYMBOL TABLE
LABEL VALUE
__16C84 00000001
craig 00000005
franklin 00000005
label_3 00000004
MEMORY USAGE MAP ('X' = Used, '-' = Unused)
0000 : XXXXXXXX-------- ---------------- ----------------
----------------
All other memory blocks unused.
Program Memory Words Used: 8
Errors : 0
Warnings : 1 reported, 0 suppressed
Messages : 1 reported, 0 suppressed
Byron A Jeff wrote:
>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
