I'm still waiting with interest for someone to pick up the ball and tell why they don't agree with my previous post.

Some architectures will be better to handle one C code construct while another architecture will better handle other constructs.

With a 8051 chip, we can have a single C statement that sets/clears a processor pin, and it will end up as an optimal match in assembler. Same when we assign values to the SFR to configure a peripherial.

Another processor may dislike immediate addresses but love register-indirect pointers with additional offset. So they will get optimum code when everything is accessed using a pointer to a structure mapping the individual SFR for the peripherial. The pointer access has zero cost, and the offsets are so small that they can be embedded directly in the access instruction.

But to be able to know what maps well and what maps badly, we just have to be able to read assembler output. Even if not able to write code, we must be able to see the amount of instructions, and recognize which instructions are expensive (such as giving memory access/pipeline stalls or a multi-clockcycle divide) and which large set of assembler instructions that could be reduced to just one or two if the original C code had described the problem in another way potentially removing a C language standard forced requirement for the compiler.