On Mon, 13 Sep 2010 06:56:29 -0700, you wrote: >Quoting Olin Lathrop : > >> ... >> really don't understand the reluctance to use assembly when required. > >Not a reluctance, but a consideration (and hence investigation) to try =20 >C instead, yet be able to handle some low-level comms. The thought of =20 >C came up because I'd need to do a considerable amount of =20 >floating-point math, and I'm also considering Atmel chips (which =20 >really touts C as being able to do everything). > >I'm now reminded of eevblog where he discussed assembly-language =20 >programmers. :) > >Cheers, >-Neil. In practice, once you get used to a compiler, you can write fiddly code and= have a pretty good idea what code it's going to generate. You can always look at the generated code= to check it's doing what you think it should. Inline assembler or seperate assembler modules are also not a problem to do= , however you may have some constrints imposed by the way the compiler uses memory or registers. M= ost MCU compilers' documentation gives a reasonable amount of info on the constraints, calling= conventions etc. when mixing C and assembler. An issue that can be problematic to work round is where you have a very tim= e-critical interrupt routine and the compiler insists on doing more context-save than is necessa= ry, so in this case you may start having to fiddle with the standard startup/linker files and have = assembler- only interrupt routines.=20 Looking at a compiler's assembler output will tell you a lot about how it l= ikes to do things, and alert you to possible pitfalls.=20 --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .