Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> It’s still an abstraction

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.

 help



Probably thinking of this article: "C Is Not a Low-level Language: Your computer is not a fast PDP-11."

https://queue.acm.org/doi/10.1145/3212477.3212479


I think this PDP-11 meme is quite misleading. There is nothing really in the C programming model specific to the PDP-11 and C was used on systems much weirder than a PDP-11. C is also very successfully the basis of many parallel programs running on multi-processor systems with a memory model in the standard that was created much later than the PDP-11.

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.


It's clear that the authors were either inspired by the PDP-11 ISA and/or designed the language to make porting UNIX from PDP-11 Assm to it easier.

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

https://news.ycombinator.com/item?id=43245166


I do not think that pre- and postincrement operator being inspired by PDP-11 has anything to with fundamental system design questions.

> Q. How do you port an OS from one language to a new one, pre-LLM?

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 jump

I do not disagree with the point that some superficial aspects are inspired by the PDP-11, I disagree with that this has anything to do with the fundamentals of computing architecture.

It 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.


You are being somewhat disingenuous with your comment ;-)

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.


Note that IMHO there are quite a few things incorrect or misleading in this article.

Do you mean in Cheney's article or Chisnall's article or in my comment?

Chisnall's article. A lot of the general criticism would still apply if you replace "PDP-11" with "von Neumann architecture" which makes the whole thing a bit weird. But also many specific comments about C are bit off (the cost of copying padding, the sequencing, provenance, etc.)

You might find Beyond the PDP-11: Architectural support for a memory-safe C abstract machine by David Chisnall et al. also interesting - https://dl.acm.org/doi/10.1145/2786763.2694367

Yes, I have much less complaints about the content of this paper, except for the PDP-11 meme aspect.

Right. Its catchy title gained it notoriety and then got amplified by human parrots.

However, it is a good article to read and understand low-level multiprocessing issues.


For someone just starting to learn CS, it should not matter whether they're on PDP-11 or x64 or ARM. You can't start teaching with pipelining and speculative branch execution. So C is good choice because there is a simple CPU architecture that it maps to well.

Fully agree. C sits in an almost perfect level of abstraction for students to get a vague sense of how the computer runs code.

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.


C hasn't presented an accurate model of how computers actually work for decades. It's a high level language LARPing as a low level language.

Computers haven't presented an accurate model of how computers actually work for decades. Compare the surface ISA of anything mainstream since the mid 90s versus all of the superscalar and out-of-order execution happening under the hood.

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).


Sure, you need an OS course, but that's when students should learn C as well.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: