Re: [Mspgcc-users] Multiplication using Horner's method
On Sep 2, 2010, at 12:35 PM, Andres Vahter wrote: mov.w R12,R13 ; The operand input in register R12 rla.w R13 add.w R12,R13 ; X1=X*2^1+X rla.w R13 rla.w R13 add.w R12,R13 ; X2=X1*2^2+X rla.w R13 add.w R12,R13 ; X3=X2*2^1+X rla.w R13 add.w R12,R13 ; X4=X4*2^1+X rla.w R13 rla.w R13 rla.w R13 add.w R12,R13 ; Final Result=X5=X4*2^3+X It computes (((X*2 + X)*4 + X)*2 + X)*2 + X)*8 + X = (12X) + X)*2 + X)*2 + X)*8 + X = 26X + X)*2 + X)*8 + X =54X + X)*8 + X = 440X + X = 441*X Which is what it said at the top; multiplies 41 * 441. It looks to me like a pretty standard multiplication algorithm, only since one argument is a know constant, you get to leave out the steps that would involve adding 0. I've seen code generators for other microcontrollers that claim to generate the optimal sequence for multiplying a register by any constant. It should be possible to do for MSP430 too. Perhaps the C compiler already does so? (probably not; I've also seen complaints that gcc does a poor job of multiplying by constants.) BillW
Re: [Mspgcc-users] Multiplication using Horner's method
Could someone point me out how to modify it so that the second argument isn't
hardcoded or just take power of 2 from the input.
uint16_t mul(uint16_t input1, uint16_t input2){}
On 03.09.2010, at 2:31, William Chops Westfield wrote:
On Sep 2, 2010, at 12:35 PM, Andres Vahter wrote:
mov.w R12,R13 ; The operand input in
register R12
rla.w R13
add.w R12,R13 ; X1=X*2^1+X
rla.w R13
rla.w R13
add.w R12,R13 ; X2=X1*2^2+X
rla.w R13
add.w R12,R13 ; X3=X2*2^1+X
rla.w R13
add.w R12,R13 ; X4=X4*2^1+X
rla.w R13
rla.w R13
rla.w R13
add.w R12,R13 ; Final Result=X5=X4*2^3+X
It computes (((X*2 + X)*4 + X)*2 + X)*2 + X)*8 + X
= (12X) + X)*2 + X)*2 + X)*8 + X
= 26X + X)*2 + X)*8 + X
=54X + X)*8 + X
= 440X + X
= 441*X
Which is what it said at the top; multiplies 41 * 441.
It looks to me like a pretty standard multiplication algorithm, only
since one argument is a know constant, you get to leave out the steps
that would involve adding 0.
I've seen code generators for other microcontrollers that claim to
generate the optimal sequence for multiplying a register by any
constant. It should be possible to do for MSP430 too. Perhaps the C
compiler already does so? (probably not; I've also seen complaints
that gcc does a poor job of multiplying by constants.)
BillW
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] problem while installing GDB of MSPGCC4
On Sep 2, 2010, at 12:16 PM, Baruch Siach wrote: A fully open-source implementation exists, it's called mspdebug (http://mspdebug.sourceforge.net/). And the protocol is not a USB one, it's a serial protocol over a USB-to-serial chip (the TI3410). So, all you need is a driver for the TI3410 for your OS, and you're done. Thank you for the hint! With only minor pain, I got mspdebug to build on my Mac, found and installed the serial port driver from TI and configured it to recognize my eZ430 dongle and MSP430-UIF device, and successfully programmed a simple LED-blinker program into the MSP430F2012 from my original eZ430 kit. Hooray! With my eZ430-RF2500, I found it to be necessary to use the --fet-force-id option to get mspdebug to correctly identify the chip type and program it properly. Otherwise, it seems to work ok. I am very pleased that I now have a no-code-size-limitation, open-source toolchain for the MSP430, and that I can build for and program the devices on my Mac without needing to bring up another OS in a virtual machine. It took some minor pain to get everything up and running, but I think it was well worth the effort. Woohoo! BTW, I also tried the FET-Pro430 Lite program, and it worked just fine on my virtual WinXP machine. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page.
Re: [Mspgcc-users] Multiplication using Horner's method
On Sep 2, 2010, at 12:35 PM, Andres Vahter wrote: I would like to use Horner's method for fast multiplication on MSP430f2234. I found source files from: http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=slaa329 You need to read the app note associated with that code, which is here: http://focus.ti.com/lit/an/slaa329/slaa329.pdf It says, among other things: The memory requirement is much higher for Horner's method since, for each multiplier or divisor, the code is different. In cases where speed is of prime concern, this is not a serious limitation. That is, the multiplication algorithm they talk about (and the performance improvement they get) is only suitable for a constant multiplier. If you need multiplication faster than that provided by the C compiler, you probably have to give up some that the C compiler assumes. It's not like the C compiler writers sit around going Well, we're a HLL, so we can make our multiply function needlessly complex! One possibility is a mixed-size multiplication. C (probably) assumes a 16x16bit multiply, and if you KNOW your arguments are always going to be less than 16 bits, you can write a significantly faster multiply function. BillW
Re: [Mspgcc-users] Multiplication using Horner's method
Indeed, Horners method is for a constant multiplier, as needed for some algorithms. (e.g. fixed scaling of gazillions of values). It is not suitable if both parameters change. The standard multiplication of the C compiler has some limitations. First, it does at least 16 bit multiplication even if the arguments are 8 bit or mixed, and then it uses always same arguments and result size. So to get a 32 bit result, you'll need to expand the arguments (possibly 8 and 16 bit) to 32 bit and do a 32x32 bit multiplication, even if only a 16x16 multiplication is needed. A formula like int32 = int16*int16 gives only a 16 bit result. You'll need to cast one of the int16 to int32 if you want a 32 bit result and then the second parameter is also turned in an int32 implicitely and an (unnecessary) 32x32 bit multiplication is done. Even with the hardware multiplier this is inefficient, as the hardware multiplier already gives a 32 bit result from a 16x16 multiplication. I wrote a set of multiplication macros (using inline assembly) which gives a 16 bit result from 8x8 multiplication and so on (using the 32 bit hardware multiplier). It is MUCH faster than using the normal * operator and does not need typecasting of the parameters to avoid result truncation. The combination of method (so result does not need to be the same size as the arguments) and macro (inlined and optimizable) together with the hinting you can usie in GCCs inline assembly, results in very fast code. I think I published the file some time ago here in the list. But maybe not the latest version. JMGross - Ursprüngliche Nachricht - Von: William ChopsWestfield An: GCC for MSP430 - http://mspgcc.sf.net Gesendet am: 03 Sep 2010 09:28:43 Betreff: Re: [Mspgcc-users] Multiplication using Horner's method On Sep 2, 2010, at 12:35 PM, Andres Vahter wrote: I would like to use Horner's method for fast multiplication on MSP430f2234. I found source files from: http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=slaa329 You need to read the app note associated with that code, which is here: http://focus.ti.com/lit/an/slaa329/slaa329.pdf It says, among other things: The memory requirement is much higher for Horner's method since, for each multiplier or divisor, the code is different. In cases where speed is of prime concern, this is not a serious limitation. That is, the multiplication algorithm they talk about (and the performance improvement they get) is only suitable for a constant multiplier. If you need multiplication faster than that provided by the C compiler, you probably have to give up some that the C compiler assumes. It's not like the C compiler writers sit around going Well, we're a HLL, so we can make our multiply function needlessly complex! One possibility is a mixed-size multiplication. C (probably) assumes a 16x16bit multiply, and if you KNOW your arguments are always going to be less than 16 bits, you can write a significantly faster multiply function. BillW -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Multiplication using Horner's method
It would be interesting. Could you publish them again if it isn't too much trouble. Andres On 03.09.2010, at 12:46, JMGross wrote: I think I published the file some time ago here in the list. But maybe not the latest version. JMGross - Ursprüngliche Nachricht - Von: William ChopsWestfield An: GCC for MSP430 - http://mspgcc.sf.net Gesendet am: 03 Sep 2010 09:28:43 Betreff: Re: [Mspgcc-users] Multiplication using Horner's method On Sep 2, 2010, at 12:35 PM, Andres Vahter wrote: I would like to use Horner's method for fast multiplication on MSP430f2234. I found source files from: http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=slaa329 You need to read the app note associated with that code, which is here: http://focus.ti.com/lit/an/slaa329/slaa329.pdf It says, among other things: The memory requirement is much higher for Horner's method since, for each multiplier or divisor, the code is different. In cases where speed is of prime concern, this is not a serious limitation. That is, the multiplication algorithm they talk about (and the performance improvement they get) is only suitable for a constant multiplier. If you need multiplication faster than that provided by the C compiler, you probably have to give up some that the C compiler assumes. It's not like the C compiler writers sit around going Well, we're a HLL, so we can make our multiply function needlessly complex! One possibility is a mixed-size multiplication. C (probably) assumes a 16x16bit multiply, and if you KNOW your arguments are always going to be less than 16 bits, you can write a significantly faster multiply function. BillW -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Multiplication using Horner's method
On 03/09/2010 02:31, William Chops Westfield wrote: On Sep 2, 2010, at 12:35 PM, Andres Vahter wrote: mov.w R12,R13 ; The operand input in register R12 rla.w R13 add.w R12,R13 ; X1=X*2^1+X rla.w R13 rla.w R13 add.w R12,R13 ; X2=X1*2^2+X rla.w R13 add.w R12,R13 ; X3=X2*2^1+X rla.w R13 add.w R12,R13 ; X4=X4*2^1+X rla.w R13 rla.w R13 rla.w R13 add.w R12,R13 ; Final Result=X5=X4*2^3+X It computes (((X*2 + X)*4 + X)*2 + X)*2 + X)*8 + X = (12X) + X)*2 + X)*2 + X)*8 + X = 26X + X)*2 + X)*8 + X =54X + X)*8 + X = 440X + X = 441*X Which is what it said at the top; multiplies 41 * 441. It looks to me like a pretty standard multiplication algorithm, only since one argument is a know constant, you get to leave out the steps that would involve adding 0. I've seen code generators for other microcontrollers that claim to generate the optimal sequence for multiplying a register by any constant. It should be possible to do for MSP430 too. Perhaps the C compiler already does so? (probably not; I've also seen complaints that gcc does a poor job of multiplying by constants.) BillW I've only got a somewhat older msp430 gcc compiler. But a quick test on other gcc targets with newer gcc versions shows that gcc can generate better code than this app note, of the form: (((x 3) - x) 6) - ((x 3) - x) The ((x 3) - x) is only calculated once, and the results are stored. Thus you have a shift by 3, a subtract, a copy, a shift by 6, and another subtract. The msp code would be something like: mov.w r12, r13 rla.w r13 rla.w r13 rla.w r13 sub.w r12, r13 mov.w r13, r12 rla.w r12 rla.w r12 rla.w r12 rla.w r12 rla.w r12 rla.w r12 sub.w r13, r12 That's marginally smaller and faster than the app note version. For other constants, using subtraction and re-using partial results can make a significant difference. This code (or at least, it's equivalent for the avr and the ColdFire) was generated using x = x * 441 - i.e., the compiler generates it. So if the newer versions of msp430 gcc do the same job as other current gcc ports, just write the C code properly and let the compiler figure out the best way to implement it. Note that you might have to use particular flags, such as -O2 rather than -Os, to get this optimisation.
Re: [Mspgcc-users] problem while installing GDB of MSPGCC4
Am 02.09.2010 20:38, schrieb Mark J. Blair: On Sep 2, 2010, at 10:52 AM, Arturo Gurrola wrote: try184.c:1:20: error: curses.h: No such file or directory and then Note that you must have libcurses developer headers installed. Abort.. I'm also installing MSPGCC4 under Cygwin right now, and I ran into the same problem. I have libncurses-devel installed, which provides ncurses/curses.h, but MSPGCC4's do-gdb.sh script looks for curses.h and doesn't find it. Since the compilation runs so terribly slowly for me (I'm running WinXP in a virtual machine on my Mac, and the compilation is easily an order of magnitude slower than it was when doing it natively under OSX), and buildgcc.pl does a brute-force compilation which will rebuild gcc before it even gets around to choking on gdb... I decided to try skipping do-gdb.sh and instead compile gdb manually. Sorry for that, I've done that quick hack as an assistance to newbies, but evidently it backfires on recent Cygwin and some Solaris versions. I have now figured that finding curses.h reliably and portably is a major undertaking (way more time that I can spend), and will anyways not necessarily match what ./configure digs out later, so let's just remove the check. As a quick fix, remove the exit 1 line related to the curses.h complain from do-gdb.sh before running buildgcc.pl. I'm submitting a series of fixes to Peter, including a fix for this, for review. Best regards MA
Re: [Mspgcc-users] problem while installing GDB of MSPGCC4
On Sep 3, 2010, at 7:33 AM, M. Andree wrote: Sorry for that, I've done that quick hack as an assistance to newbies, but evidently it backfires on recent Cygwin and some Solaris versions. I have now figured that finding curses.h reliably and portably is a major undertaking (way more time that I can spend), and will anyways not necessarily match what ./configure digs out later, so let's just remove the check. Don't feel too bad... making any complex package build portably can be very difficult! I'm up and running with MSPGCC4 and mspdebug under OSX now, and I'm really happy that this fully open and complete toolchain exists. I hope that I'll be able to contribute in some small way towards its growth and improvement, because I believe that it's beneficial for development tools to be free in order to enable and stimulate creation of new and better things. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page.
[Mspgcc-users] mspgcc questions; re: OS X; interaction with IAR Workbench
I'm attempting to use mspgcc on an OS X (Snow Leopard) system. I have a MSP-FET430UIF USB based programmer for the target board. I was able to compile and install all of the mspgcc tools, and compile and link a program that I earlier had working on an IAR Workbench (Windows 7) system. The Windows 7 machine is able to interact with the MSP-FET430UIF without trouble, and I was able to download/debug from IAR Workbench. This Windows 7 machine is running in a VMware Fusion 3.1 virtual machine on the OS X (Snow Leopard) system. Back on OS X (Snow Leopard) mspdebug seems to be suggesting that I need some sort of serial port. When I plug in the MSP-FET430UIF, I get the following on the USB bus: MSP-FET430UIF JTAG Tool: Product ID: 0xf430 Vendor ID: 0x0451 (Texas Instruments) Version: 1.01 Serial Number: TUSB3410332587F2415DFF7D Speed: Up to 12 Mb/sec Manufacturer: Texas Instruments Location ID: 0x0410 Current Available (mA): 500 Current Required (mA): Unknown (Device has not been configured) but never see a serial port added. I tried also on a Debian system (virtual machine also). Again, there was no serial port created for the MSP-FET430UIF. I had installed libusb-1.0 and libusb-compat before compiling mspdebug. As far as my IAR Workbench question goes, I've created a load module on the OS X system; I can turn it from ELF into hex, but is there a way to 1) transform it into the format that IAR Workbench needs, and 2) use some sort of IAR workbench tool to load it? I transferred it over, but can't figure out how to open it with IAR Workbench to upload it.
Re: [Mspgcc-users] problem while installing GDB of MSPGCC4
MA: Thanks. The patches look good, and I've merged them to the next branch of the git repository. MB: Help is certainly welcome. Wiki pages with updated instructions, especially how to build (especially on windows) would address the biggest problems; perhaps, having recently succeeded, you could document what you did? As we're moving back to putting everything under mspgcc, and we have to keep mspgcc4 somewhat stable due to external references to its content by the WASP project, I'd suggest that be done on the existing mspgcc wiki at: https://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=MSPGCC_Wiki If you need somebody to give you write access, contact me directly with your sourceforge userid. Just mark the stuff that's currently only relevant to mspgcc4; I don't think we're going to change the existing mspgcc infrastructure, just supersede it. I'm hoping for a new release under the mspgcc project within a couple weeks, with my updates that eliminate all the specialized hard-coded chip-specific addresses and assumptions. Unfortunately, real work has started to interfere again, so it's already later than I'd intended. We could also use a downstream packager for OSX, so people won't have to fight with the build process. (Ubuntu and Windows, too; I think Rob Spanton's doing Fedora/RedHat, though we haven't coordinated the release processes yet: that should be done with the return to mspgcc.) Peter On Fri, Sep 3, 2010 at 10:45 AM, Mark J. Blair n...@nf6x.net wrote: On Sep 3, 2010, at 7:33 AM, M. Andree wrote: Sorry for that, I've done that quick hack as an assistance to newbies, but evidently it backfires on recent Cygwin and some Solaris versions. I have now figured that finding curses.h reliably and portably is a major undertaking (way more time that I can spend), and will anyways not necessarily match what ./configure digs out later, so let's just remove the check. Don't feel too bad... making any complex package build portably can be very difficult! I'm up and running with MSPGCC4 and mspdebug under OSX now, and I'm really happy that this fully open and complete toolchain exists. I hope that I'll be able to contribute in some small way towards its growth and improvement, because I believe that it's beneficial for development tools to be free in order to enable and stimulate creation of new and better things. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] mspgcc questions; re: OS X; interaction with IAR Workbench
On Sep 3, 2010, at 10:51 AM, Kim Toms wrote: I'm attempting to use mspgcc on an OS X (Snow Leopard) system. I have a MSP-FET430UIF USB based programmer for the target board. [...] Back on OS X (Snow Leopard) mspdebug seems to be suggesting that I need some sort of serial port. I went through getting mspdebug working on my Snow Leopard system just last night. Mspdebug talks directly to the eZ430-RF2500 (but still may need a codeless kernel extension to keep the kernel from trying to use the device for its own purposes), but a serial port driver is needed for the MSP-FET430UIF and the eZ430-MSP430F2013 dongle. I found links to both the pre-compiled driver and its source code here: http://e2e.ti.com/support/interface/digital_interface/f/130/t/55982.aspx I downloaded both, but the pre-compiled binaries worked for me. The binaries are here: http://e2e.ti.com/support/interface/digital_interface/m/videos__files/198722.aspx You'll need to copy the .kext file in the binary package into /System/Library/Extensions, then change its ownership and permissions like this: sudo chown -R root:wheel /System/Library/Extensions/TIVCPSerial.kext sudo chmod 755 /System/Library/Extensions/TIVCPSerial.kext You'll also need to modify the Info.plist file in the .kext package so that the MSP-FET430UIF will be recognized (it's probably easier to do this before copying it into the Extensions folder and changing its ownership and permissions. The documentation at the above link suggests that the change needs to be made in the source code, but it can be done on the pre-compiled kernel extension. Open up that Info.plist file in the Property List Editor (double-clicking the .plist file should do that), find the IOKitPersonalities section, copy one of the existing entries with 3410 in their name under there, then change the copy as follows: * Rename the entry to something like MSP-FET430UIF * Optionally, change IOTTYBase Name to something like MSP-FET430UIF * Change bcdDevice to 257 * Change idProduct to 62512 After doing all of this stuff, you can load the kernel extension like this: sudo kextload /System/Library/Extensions/TIVCPSerial.kext If all goes well, then when you plug in the UIF, a pair of device nodes for it should show up under /dev, looking something like these: /dev/cu.MSP-FET430UIF640/dev/tty.MSP-FET430UIF640 A dialog box may also pop up asking you to configure a new network interface. You can cancel it each time, or you can go into Preferences and deactivate the device entry that got created for the UIF. Depending on how comfortable you already are editing plist files and installing kernel extensions under OS X, I may or may not have left out important details... so feel free to ask more questions if what I wrote above doesn't get you all the way there. I also typed most of this from memory, so mistakes could have snuck in. Note that I've verified that my MSP-FET430UIF is recognized by my Mac, but I haven't used it with mspdebug yet. I did successfully use mspdebug with my eZ430-MSP430F2013 dongle (which appears to use the same driver as the UIF) and my eZ430-RF2500 last night. Good luck! -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page.
Re: [Mspgcc-users] problem while installing GDB of MSPGCC4
On Sep 3, 2010, at 11:59 AM, Peter Bigot wrote: MB: Help is certainly welcome. Wiki pages with updated instructions, especially how to build (especially on windows) would address the biggest problems; perhaps, having recently succeeded, you could document what you did? I'd rather document what I did on the Mac side... my whole goal is to eliminate my need to ever touch Windows, and I was only building there because I didn't know yet that I could flash and debug chips under OS X with mspdebug! We could also use a downstream packager for OSX, so people won't have to fight with the build process. (Ubuntu and Windows, too; I think Rob Spanton's doing Fedora/RedHat, though we haven't coordinated the release processes yet: that should be done with the return to mspgcc.) I'm not sure if I know how to do that (particularly, capturing any needed prerequisites from MacPorts or Fink), but I might look into that if somebody more experienced in that area doesn't grab the task first. It took a bit of pain to build the compiler toolchain, build mspdebug, find-patch-install needed kernel extensions and so forth, and it'd be really nice if future Mac users could just drag a folder out of a .dmg or double-click a .pkg! I'm still not quite at the finish line, since Insight wouldn't build for me and I decided to put off debugging that until I got the other stuff basically working. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page.
