On Sun, 2 Mar 2014, Jason White wrote: > > I don't see what everyone gets so caught up on optimization. The real > reason to move to C is not for efficiency, its for ease of development > and portability. Hobbyists (and often engineers too) don't need to to > worry about squeezing every last bit out of a chip that only costs > $0.90 to start with. The time spent often outweighs the marginal costs > of increased flash usage. Repectfully, you've missed a very important aspect of optimisation - speed= =20 of execution. When people move from interpreted BASIC to compiled C they often see a=20 speed increase in the order of 200 to 300 TIMES!!! This turns a dinky toy=20 that can flash a LED in response to a push button into a serious tool that= =20 can do some really amazing things. If you have a PIC stuck at running at 5MIPS just going to a bigger version= =20 with more code space will not give you the extra horse power you might=20 actaully need. If however you can reduce the TIME it takes to execute the=20 code... Well do I really need to spell it out. > > C works just fine on the 8 bit PICs, the only time optimization > becomes an issue is when you start doing operations that the processor > can't do natively. No this is not the case. One of goals of using a high level language is to= =20 allow the computer to do the "book keeping" for you. So that you describe=20 the problem in the most natural way to you and the computer (the compiler=20 actually) uses that description to solve your problem in the most=20 efficient way possible. It's the age old argument of being an expert=20 assembly code programmer vs. an engineer that only know HLL programming.=20 Given a good compiler the engineer should be able to churn out code that=20 is on a par with the expert assembly code programmer. He should be an=20 expert in his own field and be able to concentrate on solving his problem=20 without needing to be an expert assembly code programmer. He should be=20 able to write well understood mantainable code without resorting to obsure= =20 sequences of machine code that have a myriad side effects. Optimization isn't just about converting one HL statement into the=20 smallest number of machine code instructions, it's about understanding the= =20 relationship of multiple HL statements to each other. > Relative offset addressing, floating point math, > division, dynamic memory, and other advanced features enabled by C > should be used with caution. However that does not mean that either C > or the processor are inherently bad. The compiler only does what you > tell it, if stick to basic basic operations like you would do in > assembly (writing to registers, loops, 8 bit integer math) there > shouldn't be an issue at all. > You should ask more from your compiler than it simply (blindly) translates= =20 one HLL statement to several machine code instructions. Until you do,=20 that's all you'll get :-) Regards Sergio Masci --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .