Also somehow the implied argument that computing hardware and operating systems simulate a PDP-11 for the sake of C is completely backwards. Historically, there were other approaches, e.g. processors designed for object-oriented programming or actors etc.. All those were not very successful.
UNIX for PDP-7 in Assm -> UNIX for PDP-11 in Assm -> UNIX for PDP-11 in C
https://news.ycombinator.com/item?id=42644851
and
A. you reduce impedance mismatch, but making the new language using similar concepts and mechanisms
--
You're right, this table is just a coincidence, probably derived from the standard math notation, and used in many PLs like FORTRAN and Python ;)
PDP-11 C
INC R ++i
DEC R --i
ADD src, dst dst += src
SUB src, dst dst -= src
(R)+ *p++
-(R) *--p
X(R) p[x]
@(R)+ **pp++
@X(R) *p[x]
BR label goto label ; near jump
JMP label goto label ; far jumpIt would also completely contradict the whole idea that everything today simulates the PDP-11 design because of C, as few architectures have this auto-in/decrement addressing modes despite C having native syntax.
PDP-11 was hugely influential in the later designs of various Hardware, Software, OS, Languages etc. See for example; Dave Cheney's What Have We Learned from the PDP-11? - https://dave.cheney.net/2017/12/04/what-have-we-learned-from... The conclusion from the article;
While its development was sometimes chaotic, and not without its flaws, the PDP-11 is at the intersection of many threads of history.
Hardware, software, programming languages, operating systems, have all been influenced by the PDP-11. I wager there is not a single person in this room who cannot trace the lineage of the language they work with, the computer they use, or the operating system it runs, back to the PDP-11.
And that is worth celebrating.
While the PDP-11 instruction set was certainly influential in the design of the "C Abstract Machine" the latter was generalized to accommodate other architectures extent at that time (eg. Honeywell 6000, IBM System/370) with enough flexibility that you can implement a C compiler for almost any architecture you can think of. That is its strength.
David Chisnall's criticisms in his C Is Not a Low-level Language: Your computer is not a fast PDP-11 (https://queue.acm.org/doi/10.1145/3212477.3212479) has to do mainly with the fact that the abstract machine was serial execution with no concept of memory protection/models. But this very flexibility is what makes C easily portable to dinky little MCUs which do not have those features while allowing the programmer to explicitly program those using libraries on more complex processors with lots of parallel cores, mmus etc.
Thus a single thread runs on a "C abstract machine" on a core (i.e. the bare minimum) and it is up to the programmer to manage interactions between the threads on various cores. We have lost nothing but perhaps burdening the programmer with more knowledge of hardware complexity which was an acceptable tradeoff then. Note also that there already exists various extensions to C to handle parallel programming directly eg. "Concurrent C" by Narain Gehani et al. The industry however chose to settle on external libraries and optional thread support in C11 again keeping with its minimality and flexibility mantras.
However, it is a good article to read and understand low-level multiprocessing issues.
Those that don’t need low level details can spend their professional career in languages like python and JavaScript while still have a sense of what lies beneath the abstraction.
For those that do want or need to go deeper, C is an excellent jumping off point into ASM and arch specifics.
Deliberate efforts to surface this deeper layer back to the programmer-facing ISA (VLIW, notably Itanium) failed spectacularly outside of niche applications. C and its contenders can't simply hop over the CPU abstraction presented to them without having to map backward from some lower-level model to the surface ISA it's forced to target then having the rug pulled every few years due to microarchitectural changes. It has managed to evolve surprisingly gracefully over decades from tiny 16 and 18-bit machines, sometimes segmented, to 32 and 64 bit machines, and even accommodating SIMD reasonably gracefully via intrinsics (which is about the best we can do at present, as CPUs continue to diverge wildly in this area, though I'm begrudgingly impressed by what modern compilers can do via autovectorization to optimize simple loops).
C is still heavily abstracted. Modern OS evolved in conjunction with C s.t. it behaves like a C runtime simulating a PDP11 (I remember reading a nice article on that). To learn system, what you need is an OS course, not C. I'd say the current C-based stack is in a quite embarrassing state.