Subject:
RE: #v()
From:
"Kevin Blain" ####@####.####
Date:
12 Apr 2002 07:49:51 -0000
Message-Id: <00e401c1e1f5$915a35d0$b802a8c0@wdtadley.woodanddouglas.co.uk>
Only a #v()+1 calculation.
> -----Original Message-----
> From: ####@####.####
> ####@####.#### On Behalf Of Craig Franklin
> Sent: 12 April 2002 01:51
> To: Kevin Blain
> Subject: Re: #v()
>
>
> Thanks for the response.
>
> Your example shows, what I would consider, good uses of #v().
> They are creating unique labels. I don't see any in your
> example where the numeric result of #v() is used in a
> calcuation. Did I miss one?
>
> Kevin Blain wrote:
> >
> > Here's a macro used for processing I2C Activity. It isn't great, in
> > fact in the end, I never used it, but it illistrates a use
> of #v. Hope
> > it helps. I havn't tried it without #v actually.
> >
> > Regards, Kevin
> >
> > It could be used like this
> >
> > Check_Read .66
> >
> > Stuff here if it's code 66
> >
> > Check_Read .67
> >
> > Stuff here if it's code 67
> >
> > CheckRead_68: ; required as the "case otherwise" bit
> >
> > Here's the macro
> >
> > Check_Read MACRO i
> >
> >
> > checkRead_#v(i):
> > MOVLW i
> > xorwf Command,w
> > btfss STATUS,Z
> > goto checkRead_#v(i+1)
> > endm
> >
> > ;===============================
> >
> > new_byte_in macro DATi
> > local
> > Start_Again,check_buff,state2,read_buffer,state_fail,exit_m
> >
> > Start_Again:
> > BANKSEL PORTC
> > BSF SSPCON,CKP ;enable the clock
> >
> > btfss PIR1,SSPIF ;wait for the arrival of
> the data byte
> > goto $-1
> > bcf PIR1,SSPIF
> >
> > ;****************************************************
> > ;examine the clock line- if it is low keep it low:
> >
> > btfsc PORTC,3
> > goto $-1
> > ;****************************************************
> >
> > BCF SSPCON,CKP ;HOLD THE CLOCK
> >
> > ;_______________________________________
> >
> > ;see if unit is in state 2 i.e. everyhing ok, data byte received:
> >
> > check_buff:
> > BANKSEL SSPSTAT
> >
> > movf SSPSTAT,w
> > andlw b'00101101'
> > banksel SSPSTAT_Temp
> > movwf SSPSTAT_Temp
> >
> > state2:
> > movlw b'00101001' ;received data pattern
> > xorwf SSPSTAT_Temp,w
> >
> > btfss STATUS,Z
> > goto state_fail
> > ; goto read_buffer ;ok read the buffer
> > ;---------------------------------------------
> >
> > read_buffer:
> >
> > movf SSPBUF,w ;read the buffer
> > movwf DATi
> >
> > btfsc SSPCON,SSPOV
> > bcf SSPCON,SSPOV
> > goto exit_m
> > ;-----------------------------------------------
> >
> > state_fail:
> >
> > banksel SSPCON
> > bsf SSPCON,CKP
> > banksel SSPSTAT
> > bcf SSPSTAT,BF
> > pg0
> >
> > goto I2C_Int
> >
> > ; call RESET
> >
> > ;-----------------------------------------------
> >
> > exit_m:
> > ENDM
> >
> > > -----Original Message-----
> > > From: ####@####.####
> ####@####.####
> > > On Behalf Of Craig Franklin
> > > Sent: 11 April 2002 03:43
> > > To: ####@####.####
> > > Subject: #v()
> > >
> > >
> > > I have seen several examples of code that used #v() in a strange
> > > way.
> > >
> > > number equ 0xf
> > >
> > > movlw #v(number + 1)
> > >
> > > The #v() operator evaluates the expression within the parentheses
> > > and outputs a decimal string representing its value. It
> is useful
> > > for automatically creating unique labels (mylabel_#v(1 + 2) =
> > > mylabel_3).
> > >
> > > The above expression will always be substituted with:
> > >
> > > movlw 16
> > >
> > > The thing I don't understand is why someone would want to
> do this.
> > > The example below demonstrates what I mean.
> > >
> > > source file
> > > -----------
> > >
> > > processor 16c74
> > >
> > > number equ 0xf
> > >
> > > radix dec
> > >
> > > movlw #v(number + 1)
> > > movlw number + 1
> > >
> > > radix hex
> > >
> > > movlw #v(number + 1)
> > > movlw number + 1
> > >
> > > end
> > >
> > > list file
> > > ---------
> > > 00001 processor 16c74
> > > 00002
> > > 0000000F 00003 number equ 0xf
> > > 00004
> > > 00005 radix dec
> > > 00006
> > > 0000 3010 00007 movlw 16
> > > 0001 3010 00008 movlw number + 1
> > > 00009
> > > 00010 radix hex
> > > 00011
> > > 0002 3016 00012 movlw 16
> > > 0003 3010 00013 movlw number + 1
> > > 00014
> > > 00015 end
> > >
> > > If the radix is decimal the #v() is unecessary. With any other
> > > radix, the 16 is interpretted as 16 in that radix. In
> the example
> > > above, 15 + 1 = 22.
> > >
> > > I intentionally never added gpasm support for this notation.
> > > However, a few users have reported the lack of support as a gpasm
> > > bug. MPASM does support this, so techically it is a bug.
> > >
> > > I must be missing something. Will someone send me an
> example where
> > > this specific behavior is desired.
> > >
> > > Thank you.
> > >
> > >
> --------------------------------------------------------------------
> > > -
> > > To unsubscribe, e-mail: ####@####.####
> > > For additional commands, e-mail: ####@####.####
> > >
> > >
> > >
> > > *****************************************************************
> > > This email has been checked by the altohiway e-Sweeper Service
> > > *****************************************************************
> > >
> > >
>
>
> *****************************************************************
> This email has been checked by the altohiway e-Sweeper Service
> *****************************************************************
>
>
