Well, first of all, the "best" code for one architecture or even one chip within that architecture, is not code that's written to be easily portable between architectures. While it may be good to write code that's portable when you're trying to decide on an architecture, or perhaps a particular chip from a list, the truly best code for a specific task, IMHO, is the code that's been written for that task, often with parts in ASM, and sometimes entirely in ASM, because it fully utilizes the features of that particular architecture or chip. No generic HLL compiler is going to do that for you. You have to determine for yourself which parts have to be "hand-tweaked" and which do not, and those always will vary between architectures. Not only that, when you're moving from one chip within that architecture to another, each one will have strengths and weaknesses that have to be handled carefully and precisely.

If one wants code that's easily portable, one has to give away some of the advantages that one chip or one architecture has over another in order to make each feature set fit the generic compiler.

The REAL problem with single-sourced components lies in the behavior of your supply chain. If you're using 10E6 parts per year, you probably won't have to worry about getting your weekly allocation. If, however, you use 100 components per year, it's very likely your deliveries will be haphazard because the behemoth corporation down the street absorbs them as part of your order from time to time, and the distributor doesn't really care whether or not YOU go out of business because he missed scheduled delivery.

RE