This appears to be triggered by my answer to another question, in which I asserted that C was originally conceived as a "portable assembly language" with the PDP-11 in mind. This does not at all mean that C should be thought of as targetting a virtual PDP-11. Rather, the PDP-11 had a relatively complete feature set, which was used as a model for what operations C should directly support.
By the time C came along, several other high-level compiled and interpreted languages were already well established. Some, like FORTRAN and BASIC, were relatively simple; others, like Algol, were extremely complex and correspondingly difficult to implement. C had, as its primary goal, the capability to write large parts of an operating system's kernel and utilities, a goal which was not met by these high-level languages, and demanded a language which did not abstract the underlying machine too much.
Hence C was designed to be easy to write an efficient compiler for, initially targeting the PDP-11 but also applicable to many other machines, and so that the code expressed in it would have a similar structure to competent assembly language.
There is no built-in memory management except for the CPU's stack, with
free() being library routines that are themselves written in C. Native string types require built-in memory management, so in C strings are just arrays of
char, and arrays in turn are just pointers to some known element within them (usually the first). This closely matches how strings and memory are handled in assembler.
Today's CPUs have grown many capabilities that the PDP-11 did not have. To some extent the C language has not kept up with these developments. But I have never heard of a C compiler which actually generated PDP-11 code as an intermediate product before translating it to its actual target; indeed that would be absurd.