Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

words.steveklabnik.com

Post reply on HN
Print view View original

141–150 of 387 posts

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

#141

Post by mark-r »

aequitas wrote: post #94
deelowe wrote: post #67

Earlier quoted context omitted.

Even binary code isn't "how the computer works" these days.

Never has been. Deep down 1's and 0's are still analog voltages, subject to capacity and inductance, on a tiny wire between transistors. Without proper timing you end up reading the voltage half way between ascending from 0 to 1 and who knows what value you end up with.

If you violate the timing for a flip-flop circuit, you can put it into a metastable state where the "digital" output varies between 0 and 1 for a very long time.

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

#142

Post by 8K832d7tNmiQ »

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…

You are mixing up how branch prediction works with how processing unit works.

One of those only worth of time to learn as hardware engineers, but understanding both of them will give you an introduction to Spectre vulnerability.

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

#143

Post by TomMarius »

scottLobster wrote: post #92
dpc_pw wrote: post #66

Earlier quoted context omitted.

M............................................C M..............................................Java Look. C is much closer to how the machine (M) works.

Give that Java is written in C++ which is in turn an extended version of C, I'm not sure that chart is entirely to scale.

That is no argument in this discussion, IMHO - what does it change? The discussion is about the language (and in case of Java, the runtime) and it's machine abstraction, which is nearly the same for Java and C, even if JVM was written in Lisp.

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

#144

Post by vardump »

Jasper_ wrote: post #139
vardump wrote: post #127

Earlier quoted context omitted.

Pseudo-code: a = 10; b = 20; c = b + 30; bar = a + b; x = 1; y = 2; z = y + 3; foo = x + y; ... in order to remove dependency stalls might be executed as: b = 20; y = 2; a = 10; x = 1; c = b + 30; z = y + 3; bar = a + b; foo = x + y; This would still be true, even if 'x' and 'a', 'y' and 'b' etc. variables (well, registers) had same name. In that case CPU would just make up new "variables" as required and do the same…

This has nothing to do with microcode. It doesn't even have anything to do with microops. Reordering instructions (likely register renaming or load-store forwarding here, though the pseudo C code doesn't let me determine) is just part of how the processor retires instructions.

The example I gave, yes. No assembler code can have anything to do with micro-ops; they're implementation specific.

On x86, a lot of instructions are close matches, yet some are removed entirely (say "xor eax, eax") or fused into one micro-op, (like "cmp #123, eax / je ").

Future CPUs might even do some data flow analysis to optimize code even further.

Say speculative "constant" folding based on runtime profile to remove chunks of code from hot inner loops.

Or to replace longer instruction patterns with HW optimized implementation, if that's what it takes to get some extra performance for the next year's model.

https://en.wikichip.org/wiki/macro-operation_fusion

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

#145

Post by fennecfoxen »

chrisseaton wrote: post #119
gruez wrote: post #91

Earlier quoted context omitted.

>inability to read uninitialized memory printf("%x", *(int*)0x12345678);

This is not a well-defined C program though.

At some point, the question of "well-defined C program" is philosophical. Let's get down to brass tacks: If someone sat down and wrote this, would it happily compile? Would it compile under some compilers and configurations but not others? Would it throw warnings instead of errors under some configurations? Which of these configurations are the default configurations? Which non-default configurations are considered best practices? How complex are the best practices, and how widespread is knowledge about them?

In short, how much does the concept of a "well-defined C program" differ from the concept of a "C program" as implemented in practice? Can we say that most C programs, or even a medium-sized percentage of C programs, are well-defined?

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

#146

Post by vardump »

8K832d7tNmiQ wrote: post #142
vardump wrote: post #88

Earlier quoted context omitted.

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…

You are mixing up how branch prediction works with how processing unit works. One of those only worth of time to learn as hardware engineers, but understanding both of them will give you an introduction to Spectre vulnerability.

No, branch prediction is not involved with what I was talking about.

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

#147

Post by JdeBP »

slfnflctd wrote: post #106
CDSlice wrote: post #32

Earlier quoted context omitted.

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…

That creation myth rather falters on the fact that a fair number of languages had already emerged. This was the 1970s, not the 1950s. No-one expected language namers to follow some universal alphabetic convention beginning with BCPL.

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

#148

Post by dooglius »

Jasper_ wrote: post #128
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.

Microcode is not used for the majority of operations. Are you confusing it with micro-ops?

Maybe you have a different definition in mind than I do? I'm using microcode to mean sequences of micro-ops. Wikipedia [0] seems to agree, "the microcode is a layer of hardware-level instructions that implement higher-level machine code instructions or internal state machine sequencing in many digital processing elements". My understanding is that with a couple exceptions (IIRC mov and zeroing xor are treated specially as part of register renaming) all assembly instructions get translated into microcode (i.e. a sequence of micro-ops).

[0] https://en.wikipedia.org/wiki/Microcode

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

#149

Post by vardump »

dooglius wrote: post #137
vardump wrote: post #127

Earlier quoted context omitted.

Pseudo-code: a = 10; b = 20; c = b + 30; bar = a + b; x = 1; y = 2; z = y + 3; foo = x + y; ... in order to remove dependency stalls might be executed as: b = 20; y = 2; a = 10; x = 1; c = b + 30; z = y + 3; bar = a + b; foo = x + y; This would still be true, even if 'x' and 'a', 'y' and 'b' etc. variables (well, registers) had same name. In that case CPU would just make up new "variables" as required and do the same…

Okay, you're talking about OoO execution here, and you're right that this can be hard to reason about (in terms of stalls/latencies), however that's orthogonal to microcode translation.

OoO and the fact that CPUs really are free to do whatever transformations they deem fit, as long as the end result within limits of memory model is same.

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

#150

Post by csours »

fctorial wrote: post #107
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 th…

Sure, but you can also run non-trivial code in the web browser.

I wasn't being super-precise with my comment, and my point is that there is no one thing that "is the computer". There are many computers in your computer, and many definitions of what a computer is.

I've never had to go below the HAL, or inside the JIT, but to some people that's where "the" computer really is. If that's where the computer really is, then I'm not a computer programmer (HINT: I'm not, but I do write code sometimes and get paid for it).

So if I write code, but it doesn't tell the computer what to do, what am I even doing?

Well, I write code that gets consumed by pre-processors and lexers and parsers and compilers and linkers and build agents and I don't know how the soup works, and you probably don't either, you may know more or less of the of the alpha-bits in the soup, but it's still soup. The soup is turned into jello and fed to a virtual machine, which is a fake computer, but it works well enough.

---

If I were to be more precise, I would say that there's a von Neumann machine C0 that is represented by some hardware abstraction layer C1 by a operating system kernel. There may be a virtual machine C2 running in the C1 context.

But, inside that C0 von Neumann machine there are a bunch of microprocessors that may be called computers that may have Turing complete instruction sets.

---

Or you could say, anything that can be Turing complete is a computer, in which case your web browser is a computer (among many others).

Post reply on HN