From j_baraclough at zetnet.co.uk Fri Aug 8 00:40:21 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Fri Aug 8 01:44:28 2008 Subject: [Icc-430] OT: Imagecraft in Elektor online magazine In-Reply-To: <200808080519.m785JAPh082890@mail.imagecraft.com> References: <489B8750.9020907@t-online.de> <200808080519.m785JAPh082890@mail.imagecraft.com> Message-ID: <489BF865.5000705@zetnet.co.uk> This article was just published today. I thought you may like to see it. http://www.elektor.com/news/icc-for-parallax-propeller.630545.lynkx John From kris at abbey.co.nz Tue Aug 19 19:01:34 2008 From: kris at abbey.co.nz (Kris Heidenstrom) Date: Tue Aug 19 20:04:20 2008 Subject: [Icc-430] ICC430 7.08A divmod8u instead of shifts for power-of-2 division on byte vars Message-ID: <48AB7AFE.4030403@abbey.co.nz> It looks like ICC430 7.08A uses a helper function divmod8u instead of register shift-right operations for unsigned division by two if the variables are bytes (unsigned char) instead of words (unsigned int). Compiling with 7.08A for MSP430F1232 target: 1 ... 2 (1912) unsigned char length; 3 (1913) unsigned char nfactors; 4 ... 5 (1922) nfactors = (length / 2) - 1; 6 E68E 436F mov.B #2,R15 7 E690 454E mov.B R5,R14 8 E692 12B0 F602 call #divmod8u <------- helper function! 9 E696 4E46 mov.B R14,R6 10 E698 8356 dec.B R6 11 (1923) if (nfactors != 0) { 12 E69A 9346 tst.B R6 13 E69C 2439 jeq ... But if I change the variables to 16-bit unsigned: 1 ... 2 (1912) unsigned int length; 3 (1913) unsigned int nfactors; 4 ... 5 (1922) nfactors = (length / 2) - 1; 6 E68E 454B mov.B R5,R11 7 E690 C312 clrC 8 E692 104B rrc.B R11 <-------------- register rotate 9 E694 835B dec.B R11 10 E696 4B46 mov.B R11,R6 11 (1923) if (nfactors != 0) { 12 E698 9346 tst.B R6 13 E69A 2439 jeq ... As far as I can see, there's no reason why unsigned division by 2 should ever be done with a helper function on the MSP430, no matter what size the variables are. There are two more missed opportunities for optimisation visible in this code fragment. 1. The CLRC / RRC.B instructions (lines 7 and 8) could be replaced with an RRA instruction, because the top half of R11 is known to be zero because it was just loaded using a MOV.B instruction. 2. The TST.B R6 instruction on line 12 isn't needed because the zero flag is still set/cleared from the DEC.B R11 instruction at line 9. Both of these optimisations would fall into the general category of "keep track of known aspects of the MCU's state, and take advantage of this to reduce code size and/or execution time", and if ICC430 isn't already doing this, I expect it would be a major change to add it, but I think the benefits could be significant. Anyway the real issue for me is the helper function used for unsigned division by two. Regards Kris -- Kris Heidenstrom Embedded systems designer / programmer kris@abbey.co.nz Abbey Systems Ltd - Telemetry Specialists Wellington NEW ZEALAND Voice +64-4-385-6611 Fax +64-4-385-6848 From richard at imagecraft.com Wed Aug 20 01:20:16 2008 From: richard at imagecraft.com (Richard Man) Date: Wed Aug 20 02:24:03 2008 Subject: [Icc-430] 430X > 64K support Message-ID: <200808200924.m7K9O2O5066051@mail.imagecraft.com> I am now adding compiler support for the 430X >64K addressing. At the minimum, we need to support function code and flash constant placement anywhere in the 20-bit address map. A new IDE/linker option to activate 20-bit address support will be added. This *may* be the default for any 430X device with > 64K flash memory. The general guideline is that we will support > 64K code but not data as there is no 430X devices with more than 64K SRAM. Function Calls: use CALLA/RETA Branches: use BRA Any instructions that touch the PC will use the "A" variants. **************** As for pointer type, the obvious choice is to support 16 bits data pointer and 32 bits (or 24 bits, but that is difficult to express) code pointers. Unfortunately, the compiler architecture is not mixed pointer size friendly. To change that will require a lot of effort, and with the 430X devices being a relatively rare part, I am not entirely sure the ROI is worth it. A compromise is to use 16 bits pointer, but that the (16 bits) code pointer is actually a pointer to a 3 byte real pointer. This is not as odd as it sounds, as to support the Code Compressor, we already do this extra level of indirection for code pointer, so making the entry to be a full 24 bits pointer should be fairly easy. There is one extra level of indirection for code pointer reference, but as mentioned, this is already done. **************** This should satisfy most people's requirements for using the 430X devices. I will of course add support for new instructions like multiple bit shifts etc. Comments? Suggestions? // richard blog: On-line orders, support, and listservers available on web site. [ For technical support on ImageCraft products, please include all previous replies in your msgs. ] From richard-lists at imagecraft.com Wed Aug 20 01:57:55 2008 From: richard-lists at imagecraft.com (Richard Man) Date: Wed Aug 20 03:01:43 2008 Subject: [Icc-430] ICC430 7.08A divmod8u instead of shifts for power-of-2 division on byte vars In-Reply-To: <48AB7AFE.4030403@abbey.co.nz> References: <48AB7AFE.4030403@abbey.co.nz> Message-ID: <200808201001.m7KA1g1H067308@mail.imagecraft.com> All 3 improvements should be doable. I will take a look. At 07:01 PM 8/19/2008, Kris Heidenstrom wrote: >It looks like ICC430 7.08A uses a helper function divmod8u >instead of register shift-right operations for unsigned >division by two if the variables are bytes (unsigned char) >instead of words (unsigned int). > >Compiling with 7.08A for MSP430F1232 target: > > 1 ... > 2 (1912) unsigned char length; > 3 (1913) unsigned char nfactors; > 4 ... > 5 (1922) nfactors = (length / 2) - 1; > 6 E68E 436F mov.B #2,R15 > 7 E690 454E mov.B R5,R14 > 8 E692 12B0 F602 call #divmod8u <------- helper function! > 9 E696 4E46 mov.B R14,R6 >10 E698 8356 dec.B R6 >11 (1923) if (nfactors != 0) { >12 E69A 9346 tst.B R6 >13 E69C 2439 jeq ... > >But if I change the variables to 16-bit unsigned: > > 1 ... > 2 (1912) unsigned int length; > 3 (1913) unsigned int nfactors; > 4 ... > 5 (1922) nfactors = (length / 2) - 1; > 6 E68E 454B mov.B R5,R11 > 7 E690 C312 clrC > 8 E692 104B rrc.B R11 <-------------- register rotate > 9 E694 835B dec.B R11 >10 E696 4B46 mov.B R11,R6 >11 (1923) if (nfactors != 0) { >12 E698 9346 tst.B R6 >13 E69A 2439 jeq ... > >As far as I can see, there's no reason why unsigned division >by 2 should ever be done with a helper function on the MSP430, >no matter what size the variables are. > >There are two more missed opportunities for optimisation >visible in this code fragment. > >1. The CLRC / RRC.B instructions (lines 7 and 8) could be > replaced with an RRA instruction, because the top half > of R11 is known to be zero because it was just loaded > using a MOV.B instruction. > >2. The TST.B R6 instruction on line 12 isn't needed because > the zero flag is still set/cleared from the DEC.B R11 > instruction at line 9. > >Both of these optimisations would fall into the general >category of "keep track of known aspects of the MCU's >state, and take advantage of this to reduce code size >and/or execution time", and if ICC430 isn't already >doing this, I expect it would be a major change to add >it, but I think the benefits could be significant. > >Anyway the real issue for me is the helper function used >for unsigned division by two. > >Regards > >Kris >-- >Kris Heidenstrom Embedded systems designer / programmer >kris@abbey.co.nz Abbey Systems Ltd - Telemetry Specialists >Wellington NEW ZEALAND Voice +64-4-385-6611 Fax +64-4-385-6848 > >_______________________________________________ >Icc-430 mailing list >Icc-430@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-430 // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From bailey at peak.org Wed Aug 20 03:54:33 2008 From: bailey at peak.org (bailey@peak.org) Date: Wed Aug 20 04:57:17 2008 Subject: [Icc-430] 430X > 64K support In-Reply-To: <200808200924.m7K9O2O5066051@mail.imagecraft.com> References: <200808200924.m7K9O2O5066051@mail.imagecraft.com> Message-ID: <1094.69.59.200.77.1219229673.squirrel@webmail.peak.org> I'm not fully up on the 430X devices, but this sounds like a workable approach. I was wondering how you were going to handle code pointers, and this is a better approach than anything I've come up with. If you want to support flash constant placement >64K, how will you handle data pointers relative to base page data pointers? Or do you mean you will support >64K flash constant data that semantically can't be "addressed"? I'm also assuming that 20 bit address support would be independent of whether the compiler takes advantage of the other new instructions, such as multi-bit shifts, etc? keeping it independent would certainly help the execution speed for small applications. Kirk Bailey > I am now adding compiler support for the 430X >64K addressing. At the > minimum, we need to support function code and flash constant > placement anywhere in the 20-bit address map. > > A new IDE/linker option to activate 20-bit address support will be > added. This *may* be the default for any 430X device with > 64K flash > memory. The general guideline is that we will support > 64K code but > not data as there is no 430X devices with more than 64K SRAM. > > Function Calls: use CALLA/RETA > Branches: use BRA > > Any instructions that touch the PC will use the "A" variants. > > **************** > As for pointer type, the obvious choice is to support 16 bits data > pointer and 32 bits (or 24 bits, but that is difficult to express) > code pointers. Unfortunately, the compiler architecture is not mixed > pointer size friendly. To change that will require a lot of effort, > and with the 430X devices being a relatively rare part, I am not > entirely sure the ROI is worth it. > > A compromise is to use 16 bits pointer, but that the (16 bits) code > pointer is actually a pointer to a 3 byte real pointer. This is not > as odd as it sounds, as to support the Code Compressor, we already do > this extra level of indirection for code pointer, so making the entry > to be a full 24 bits pointer should be fairly easy. There is one > extra level of indirection for code pointer reference, but as > mentioned, this is already done. > > **************** > > This should satisfy most people's requirements for using the 430X > devices. I will of course add support for new instructions like > multiple bit shifts etc. > > Comments? Suggestions? > > > > // richard blog: > > On-line orders, > support, and listservers available on web site. > [ For technical support on ImageCraft products, please include all > previous replies in your msgs. ] > > _______________________________________________ > Icc-430 mailing list > Icc-430@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-430 > From jdurand at interstellar.com Wed Aug 20 08:30:12 2008 From: jdurand at interstellar.com (Jerry Durand) Date: Wed Aug 20 09:36:47 2008 Subject: [Icc-430] 430X > 64K support In-Reply-To: <200808200924.m7K9O2O5066051@mail.imagecraft.com> References: <200808200924.m7K9O2O5066051@mail.imagecraft.com> Message-ID: <1219246212.698.11.camel@Gandalf2.interstellar.com> On Wed, 2008-08-20 at 01:20 -0700, Richard Man wrote: > I am now adding compiler support for the 430X >64K addressing. At the > minimum, we need to support function code and flash constant > placement anywhere in the 20-bit address map. My requirements for the extended code are fairly simple: 1) I need to be able to write C code and have the IDE fit it all into the part, I don't care where constants and code go. If all strings/arrays have to be below 64K, that's fine with me if the IDE puts them there automatically. 2) I need to be able to assemble my flash-burn utility for use with the X parts. It is relocatable and runs from ram. It reads in a firmware update and burns it to all of FLASH so it will need to use the extended instructions. 3) Has to work with NoICE. 4) Has to work with Salvo. If possible the standard library so my customers don't need to get a PRO license, but if needed I'll compile an X library. -- Jerry Durand, Durand Interstellar, Inc. Los Gatos, California, USA, www.interstellar.com tel: 408-356-3886, Skype: jerrydurand From richard at imagecraft.com Sat Aug 23 18:21:11 2008 From: richard at imagecraft.com (Richard Man) Date: Sat Aug 23 19:24:26 2008 Subject: [Icc-430] REXIS: a Subsumption Architecture OS Message-ID: <200808240224.m7O2OOu1065302@mail.imagecraft.com> Check out our blog (see sig) if you are interested in an unusual but potentially useful RTOS based on the subsumption architecture. // richard blog: On-line orders, support, and listservers available on web site. [ For technical support on ImageCraft products, please include all previous replies in your msgs. ]