The assumption that you, when you mention PIC, Z80, M68HCxxx's, do mean what compiler to use when switching between architectures, and not what compiler to use for 8051?

What you did write was that Keil did not have compilers for a number of different architectures, and I noted that it was irrelevant if I had to switch compiler vendor when switching hardware architecture.

It does not matter a hoot what the SDCC or Keil C51 compiler do to access the chip-specific parts of a 8051 chip or what their individual code-generation looks like if I switch to a Z80. Even if Keil did have a Z80 or PIC compiler, I could just as well select a Z80 (or PIC) compiler from someone else - the learning step would have been similar anyway.

Switching C compilers is not a big issue under the assumption that the developer is competent in C.

The thing you do not want to do is to switch vendor (or even compiler version) for an already released product unless you have a very strong need to, since a compiler change for the same product (implying the same architecture) would lead to a new read-through of the assembler output and a new review of all test cases to make sure that they are relevant. Such a tool replacement would also often require that a number of certification reports from notified bodies would be invalidated because the used tools are often part of the documentation for the certification process.

The above is not relevant when switching to a new architecture, since that would represent a new product anyway, so whatever compiler that would be used would require a full analysis from scratch.

You are often talking about being competent in assembler. But as soon as you start talking about different C compilers, you must assume competence with C. It is irrelevant what problems a bungler with C will have.