Ok, well, as for readability, I was going to generate an inline function call that would perform the assembly DADD: inline int dadd( int one, int two ); Or some such. (How do I deal w/ the carry bit?) As for power, the LCD uses something like 100pA to run.. But 50uS is probably about the complete length of my loop( the CPU will be off most of the time). Thanks for the info tho, this is definitely fast. -Mark
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of David Brown Sent: Thursday, November 21, 2002 2:25 PM To: [email protected] Subject: Re: [Mspgcc-users] Fwd: MSPGCC question I cannot image that converting from hex to bcd is really going to make any significant differance to your program - even with a very inefficient convertion function, the power required for running the core an extra fifty microseconds is negligble compared to the power taken to display the result. BCD instructions are quite convenient at the assembly level, but they are seldom worth the cost in readability for C. If you want a fast (but 100 byte long) convertion routine for hex to bcd (single byte only), try using: const unsigned char hexToBcd[100] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59, 0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69, 0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 0x79, 0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88, 0x89, 0x90, 0x91, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97, 0x98, 0x99}; Python is just *so* useful for doing this sort of thing, don't you think? >>> ', '.join(map(lambda x : "0x%02d" % x, range(100))) > > no way to force gcc to issue 'dadd' > Instead: > asm volatile("dadd %1,%0": "=r" (a) : "r" (b)); > > > > ---------- Forwarded Message ---------- > > Subject: MSPGCC question > Date: Thu, 21 Nov 2002 11:30:42 -0500 > From: "Mark Stokes" <[email protected]> > To: <[email protected]> > > Howdy, from South Carolina, USA. I am very pleased to find the MSPGCC > project. Since I've developed a bunch of asm code for the 337 version > of the MSP430, and am not upgrading to the 44x version, I really needed > to find a solution that will work and not cost $2000 (IAR). I had been > using the "Simulation Environment" provided by TI, but it doesn't > support the flash devices. So, here I am. > > I have a very fundamental question: > I am on a very tight power requirements budget. One of the things I am > doing to meet that budget is to deal with most/all my numbers as BCD > numbers. This means when I need to increment something, I use the DADD > instruction. This is one of the reasons I like the MSP430 (that it has > decimal math instructions). However, the IAR compiler doesn't have any > way to force the compiler to use these instructions when performing +/- > operations. This seems stupid and I'm not interested in wasting the > extra battery power it takes to constantly convert a hex# to a BCD# (I > am using the onboard LCD output/driver). > Is there a way (aside from generating a library of asm routines, which > I'm not opposed to doing), to force mspgcc to use DADD? At the time > (and I think only recently they have fixed this), IAR didn't even allow > inline assembly, only inline-machine (which is totally useless). So > after purchasing it for $3k (US), almost 3 years ago, I sent it back. > > > > If you want me to put this is the discussion, I will. But I thought I'd > ask here first. > > Thanks > -Mark Stokes > > ------------------------------------------------------- > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users
