gnupic: Update on #v()
Subject:
Re: Update on #v()
From:
Craig Franklin ####@####.####
Date:
25 Feb 2002 03:50:59 -0000
Message-Id: <3C79B385.64C4C376@attbi.com>
Things went better than expected. I released gputils-0.10.1 with the
new macro stuff. Many old problems are fixed.
I know that it doesn't fix everything, but it gets us much closer. Your
goal is to get Wloader by Wouter van Ooijen working, right? This will
be a challenge. I will start working on it next.
Craig Franklin wrote:
>
> 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: ####@####.####
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
