“C is how the computer works” is a dangerous mindset for C programmers • Hacker News Board

Re: “C is how the computer works” is a dangerous mindset for C programmers

#101

Post by gpderetta » Tue, Mar 31, 2020, 3:47 PM UTC

Impossible wrote: post #72

hyperpallium wrote: post #41

Is the world ready for lower-level languages ? e.g. cache-aware. (assembly isn't) In a way, GPU shader languages "fit" parallel GPU architecture (though not cache-aware). Maybe... limited loop code-length to fit in cache; No pointer chasing (though you can workaround anything in a TM). Some java subsets for very limited hardware might be instances.

GPU languages have some cache aware constraints, especially if you're working with the graphics pipeline vs compute where you have more constrained inputs and outputs. Shared memory is also often used as a user managed cache. Cell SPUs had explicit user managed cache and host DMA, and Intel ISPC and Unity Burst compiler/ECS (variants of C and C#) are good examples of programming environments that try to more explicit…

> Cell SPUs had explicit user managed cache and host DMA

just a nitpick, but explicitly user managed caches aren't. They are really better known as scratchpads. A cache is supposed to be mostly transparent except for the performance implications.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#102

Post by dooglius » Tue, Mar 31, 2020, 3:47 PM UTC

vardump wrote: post #88

dooglius wrote: post #65

Earlier quoted context omitted.

Not really, assembly language is extremely close to microcode, much much closer than it is to C. C has a whole bunch of baggage like pointer provenance, inability to read uninitialized memory, doesn't understand cache aliasing, etc that don't fit hardware well.

No, it really isn't on anything modern, like ARM SoCs or x86 CPUs. The number of times I've hit my head to wall trying to understand what the heck the CPU is doing for a given sequence of instructions, like why the number of cycles or memory bandwidth required is way different from my expectation. A modern CPU willy nilly reorders instructions, stores, and creates new "virtual" registers out of thin air to dissolve s…

Can you give an example? The most complicated assembly->microcode examples I can think of are floating-point instructions like FSIN that run CORDIC loops under the hood, and those are still pretty easy to reason about.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#103

Post by CalChris » Tue, Mar 31, 2020, 3:48 PM UTC

ThrowawayR2 wrote: post #42

alekratz wrote: post #11

Someone told me back in high school that "C is just shorthand for assembly", which I think about a lot. Does anyone else feel that way?

> " Someone told me back in high school that 'C is just shorthand for assembly' " That was true for the PDP-11 that the article series mentions and it was true for the early home computers of the '70s and '80s but it became increasingly less true as processors became more and more complicated under the hood. That's kind of the point of the article series but it's not as big a deal as the author makes it out to be bec…

I really like your first point, paraphrasing, that 'C is how the PDP-11 worked, then'. But as for now, I don't agree that most people writing C are in any way really aware of this shift. Instead, I think C is how the computer works is their abstraction level. Unless your homepage is Godbolt's Compiler Explorer [1], you see C, you think C, moreso if it's C++.

[1] https://godbolt.org/

Re: “C is how the computer works” is a dangerous mindset for C programmers

#104

Post by j9461701 » Tue, Mar 31, 2020, 3:48 PM UTC

SuperscalarMeme wrote: post #75

bluetomcat wrote: post #61

"Real hardware" is also an abstract machine. Until you get to the level of each individual transistor, it's hardware abstractions all the way down. Caches, reorder buffers, load and store buffers, instruction decoding are all abstract concepts sitting at a much higher level than the individual transistor. Those abstractions are there mostly for the purpose of speeding up code execution, but also for enabling hardware…

And I bet you physicists argue that transistors are just abstractions of semiconductors

Which is, in turn, merely an abstraction over the actual quantum physics that governs what's really happening on the silicon. And quantum physics might itself one day may be found to be a higher level abstraction of what's really really going on, as happened with Newtonian physics before it.

It's abstractions all the way down. I don't know why they're so maligned by programmers, they're the only way any work gets done.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#105

Post by adrianN » Tue, Mar 31, 2020, 3:48 PM UTC

lidHanteyk wrote: post #9

It's far past time to put C to bed. D, Go, Java, Zig, etc. are all languages that one can use to do approximately C-like things without as much danger. I am tired of seeing a literal Twitter feed of memory unsafety security bugs [0]. We can do better. [0] https://twitter.com/LazyFishBarrel

Good luck rewriting all the programs that are written in C without introducing new security problems.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#106

Post by slfnflctd » Tue, Mar 31, 2020, 3:48 PM UTC

CDSlice wrote: post #32

xwdv wrote: post #23

This may be a little off topic but it is something that until now I’ve never questioned in my entire career: Is the c in C supposed to stand for “computer“? If not, what is it?

According to Wikipedia, C is named C because it resulted from work done by Dennis Ritchie to improve the language B, and C comes after B. B came from Ken Thompson making a cut down version of the language BCPL, so he just kept the first letter. https://en.wikipedia.org/wiki/C_(programming_language)

It almost implies that at the time, they realized a plethora of languages would emerge but were hoping everyone would stick with their alphabetic convention. Instead, someone skipped straight to S, someone else stepped back to R, and then everyone said screw it and started making up their own funny names & acronyms.

I've read some intriguing things about D, though (which came along more recently, interestingly enough). Apparently it's in production at several large companies.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#107

Post by fctorial » Tue, Mar 31, 2020, 3:49 PM UTC

csours wrote: post #7

There's the computer, and then there's the computer, and then there's the computer and then there's the computer: The computer is the thing that has the web browser running on it. The computer is the thing that has the code editor running on it. The computer is the thing that has the compiler running on it. The computer is the thing that provides a virtual hardware interface for running programs. The computer is the…

There's the c1(physical computer), and then there's the c2(os runtime), and then there's the c3(silicon) and then there's the c4(turing machine):

The c1 is the thing that has the web browser running on it.

The c1 is the thing that has the code editor running on it.

The c1 is the thing that has the compiler running on it.

The c2 is the thing that provides a virtual hardware interface for running programs.

The c3 is the thing that the virtual hardware interface interacts with.

The c3 is the thing inside the hard drive/graphics card/other component that the c2 talks to.

The c4 is the thing inside the processor that pre-processes, jits, or otherwise transforms commands from the c2 for the c3 so the c1 ... ... ...

Is this correct?

Re: “C is how the computer works” is a dangerous mindset for C programmers

#108

Post by steveklabnik » Tue, Mar 31, 2020, 3:49 PM UTC

cryptonector wrote: post #78

beervirus wrote: post #4

Earlier quoted context omitted.

> Basically, the overall thrust of this series has been this: C is not the hardware, it’s an abstract machine. But that machine runs on real hardware, and abstractions are leaky. If you go too far into “purely only the abstract machine,” you may not be able to accomplish your tasks. If you go too far into “C runs directly on the hardware,” you may be surprised when a compiler does something that you didn’t expect. Se…

But is Rust a more faithful model of HW? I'm happy to accept that C sucks (it does) and that Rust and others are superior (they are). But if you stop at the quoted statement, you've not said much. I upvoted the submission blindly, then read it, then un-upvoted it. TFA is not useful. It would have been better to not write TFA at all. There already are many many very good articles about how Rust is better than C.

I don't really understand why Rust is in this discussion at all. This isn't a post about Rust.

(And Rust is not really any better than C in this regard. At least, in a vacuum. I guess you could make the argument that it's better because fewer people have false beliefs about it, but that's not an argument I'm making, either in the blog post nor here.)

Re: “C is how the computer works” is a dangerous mindset for C programmers

#109

Post by sys_64738 » Tue, Mar 31, 2020, 3:49 PM UTC

C is like water. Atomically it is the DNA of all other programming languages. There's a reason why C is generally the fastest language with smaller binaries, and there's a reason why language like Python fallback to C for doing anything processor intensive. C will still be here when the latest fad languages of today are long forgotten.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#110

Post by [deleted] » Tue, Mar 31, 2020, 3:49 PM UTC

steveklabnik wrote: post #87

radarsat1 wrote: post #81

Earlier quoted context omitted.

> pointer provenance, inability to read uninitialized memory what do you mean by these two? not sure about the former. as for the latter, of course you can read uninitialized memory, unless you mean something else?

For the first, https://blog.regehr.org/archives/1621 For the second, https://www.ralfj.de/blog/2019/07/14/uninit.html (the second one is a bit more Rust focused but the core idea is the same)

[deleted]