Post by thread:MPASM accessing middle bytes...BUG???

>> It's probably easiest if you use parameterized #DEFINEs to define >> the shift-and-AND operations for each byte-position... Then you can >> just say: >> >> MOVLW LSB2(MYCONT) >> >> or whatever. >> >> By the way, it's best to use shift-and-AND macros instead of LOW and >> HIGH... In at least some versions of M >> > >Thanks for the reply, Andy. > >One phrase I didn't understand was "parameterized #DEFINEs". Can >you give me an example? hi Mike the #define - 'string substition engine' is a real powerful feature of MPASM, but apparently there is a bug with >> more than 15 bits see code snipped below, both #define are identical, but only one works. 00004 #define BYTE_2(a) (a >> 16) & 0xFF 00005 #define BYTE_2x(a) (a >> 8 >> 8) & 0xFF 00006 12345678 00007 mylong_thing = 0x12345678 00008 0000 3048 00009 movlw BYTE_2(mylong_thing) ; ^ this one messes up MPASM 1.40 bug??? 0001 3034 00010 movlw BYTE_2x(mylong_thing) ; ^ this one works fine antti -- Silicon Studio Ltd. -- http://www.sistudio.com

Antti Lukats <spam_OUTPICLISTTakeThisOuTMITVMA.MIT.EDU> wrote: > apparently there is a bug with >> more than 15 bits see code > snipped below, both #define are identical, but only one works. > > > 00004 #define BYTE_2(a) (a >> 16) & 0xFF > 00005 #define BYTE_2x(a) (a >> 8 >> 8) & 0xFF > 00006 > 12345678 00007 mylong_thing = 0x12345678 > 00008 > > 0000 3048 00009 movlw BYTE_2(mylong_thing) > ; ^ this one messes up MPASM 1.40 bug??? > > 0001 3034 00010 movlw BYTE_2x(mylong_thing) > ; ^ this one works fine You're going to laugh, Antti... Kim Cooper and I certainly did when we figured out what was happening. Here... I'll walk you through it: 0x12345678, expressed in binary, is: 00010010001101000101011001111000 The result you got was 0x48. Expressed in binary, 0x48 is: 01001000 Ok... Where in the original number does that bit-pattern appear? If you look closely, you'll see that it appears in bit positions 22 through 29... It seems that your "a >> 16" expression was actually working like "a >> 22", right? At this point, the answer should be dawning, but just in case it isn't... Decimal 22 = Hexadecimal 16. Oops. Change your #defines to read ".... a >> 0x10", or add a "LIST R=DEC" directive at the start of your program, and everything will work fine. -Andy === Andrew Warren - .....fastfwdKILLspam@spam@ix.netcom.com === Fast Forward Engineering - Vista, California === === Custodian of the PICLIST Fund -- For more info, see: === www.geocities.com/SiliconValley/2499/fund.html

> If you look closely, you'll see that it appears in bit > positions 22 through 29... It seems that your "a >> 16" > expression was actually working like "a >> 22", right? > > At this point, the answer should be dawning, but just in case it > isn't... > > Decimal 22 = Hexadecimal 16. > > Oops. oops, oops yep I did think it is something simple, I usually always declare radix dec but hence I wrote a simple 5 lines test program I forgot, so let it be a reminder to cross check everuthing inclunding correct radix, if thing dont look they way they should oh, shame shame on me :) antti -- Silicon Studio Ltd. -- http://www.sistudio.com

In message <199703262303.RAA22889KILLspamdfw-ix7.ix.netcom.com> .....PICLISTKILLspam.....MITVMA.MIT.EDU writes: > Antti Lukats <EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.MIT.EDU> wrote: > > > apparently there is a bug with >> more than 15 bits see code > > snipped below, both #define are identical, but only one works. > > > > > > 00004 #define BYTE_2(a) (a >> 16) & 0xFF > > 00005 #define BYTE_2x(a) (a >> 8 >> 8) & 0xFF > > 00006 Andy, I guess I'll just ignore Antti's bug report. Also, I guess the above is what you meant by "parameterized #defines". I didn't know you could do this in MPASM - it open the door to all sorts of things. Regards, Mike Watson