Unless you are doing large production runs why use the 10F and 12F family? Maybe pin count or huge production runs. I have one of two of the 12F on the shelf and have been wanting to play with them but the desire/need has not reached the top of my stack.
To be honest, because I'm cheap and stuped
In more details ... I used to play with electronics some ~10+ years ago, and then I stopped as "bread and butter" job took over 100% of my time (sys development, realtime applications, database systems - i work for mysql now as mysql cluster consultant & developer). Some short time ago (~1year ago) I got some time on my hands and returned back to playing with electronics, brushed up old tools etc.. found that I forgot whole bunch of it and started from scratch... at the time, pic was the most appealing uC to play with, and I found a bunch of samples for 12F and 16F pic's .. so I went and got me a bunch of them in local store, purchased mikroelektronika's tool (easypic4, mikroC) and started playing with it ..
EDIT: I do not use mikroC nor EasyPic almost at all as pickit2 + picc for 16F and C18 for 18F get the job done "faster"
Now, I purchase only 18F (as there is really no real price difference for hobby use, and there are some pretty small 18F's too) but still have bunch of 12F and 16F's .. (think I still have ~50 16F84
.. and darn thing was more expensive then 16F268)
hence - I use 12F's and 16F's where I can, just to "use them up"
conclusion - yup, /me stuped
Last summer I wrote an unpublished article that compared the code generated by C18, BoostC and Swordfish. The idea was to show the user how similar they actualy were. I ran into some interesting things.
post it post it
would give me good place to start
A comparision article would be a very good thing. Perhaps Bill would like to publish it in JPUG.
let me first write it
If it has not already been said: It is a bad idea to try to optimize C code when using a compiler with an optimizer. Optimizers tend to know how to optimize simple logical code. Tricky C code may be tighter but the generated machine code is often larger.
I'm pretty familiar with optimisations, optimisation bug's, compilers etc... as system developer, one must know those things
sometimes the slower but shorter code is actually going to be faster as it will fit in the cpu cache, on the other hand a simple mistake can slow things down with factor of 10 .. now, with uC's this is bit different, actually, lot different, especially with pic's architecture, and in most cases one do not have to worry about it - but some "general pointers" are good to have when one decide to use one particular compiler.