Babar,

That's an interesting question. Here's how I do it.

First I analyze the product specification and to determine the critical design issues. This may be things like power consumption for battery operation, interrupt response time, repetitive computations support, input/output requirements. Whatever the device requires that is hardest to attain, I prioritize in a list and use it to filter the selection of the microprocessor.

The first productive test is: "Does the last microprocessor we've worked with, and for which we have support equipment and software, fit this design?" Using the same microprocessor has obvious efficiencies so I won't enumerate them.
Through out my career, I've only followed one design with the previous microprocessor, roughly 30% of the time. Of course, I'm not counting when I do a design that is actually sold as a productline of several models; since they are designed as one, I count them thus.

So usually, I'm working with a new microprocessor.

I'm using the 8051 family now in the product upon which my company is based. I had not used the 8051 family since 1982. I looked at EVERY microprocessor for the best fit, assuming the HC11 family would win. Working with a 40% schematic including the outward interconnect devices for our maximum configuration, I started screening the list of micros down. Two dominated: I made a schematic for the HC11 and the 8051.

Since I didn't know the 8051, I spent 3 work days reading its microprocessor data book over and over. This gives me time to assess the hidden power of the microprocesser, i.e. what can it due best due to its unique opcode set.

The 8051 is a very odd micro. It appeared to have a collection of ideas from computer science opcode theory but poorly combined. The more I examined it, the things I hated about it, became where the hidden power was. For example, my early disgust over its DPTR construct became moot when I relized that the DPTR was seldom the thing to use. I could count DPTR references in code to quickly screen out who I wanted to hire... :-)

I learned each 8051 opcode and both its execution time and byte count. Most think this is wasted effort but I do real-time programming applications and unless you are intimate with the microprocessor, you can't achieve magic. The way I do this is by putting the execution time and byte count in the first block of every opcode comment line. Repetition teaches. As I learn this, I start writing tighter code.

I've used this trick since I started hand-assembling 8080 code for my first home computer in 1977 (I had to key-in programs in hex-dump format - which was better that using panel switches)

Most gurus I talk with know the execution times and byte counts of their favorite micro, but I don't know of any that actually type them as they code.
:-)

-Jay C. Box