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

Should you learn C to “learn how the computer works”?

words.steveklabnik.com

Post reply on HN
Print view View original

131–140 of 381 posts

Re: Should you learn C to “learn how the computer works”?

#131

Post by geofft »

jolmg wrote: post #109
tomjakubowski wrote: post #97

Earlier quoted context omitted.

Sometimes the bugs don't happen when optimizations are off. (-:

That'd be a compiler bug, then. I don't think those would be common. EDIT: I suppose the other possibility is that the program is doing some weird things, like reading its own machine code from memory.

Neither of the above are required: your code might be racing with some other API. If your code finishes fast enough, the other code isn't ready for you. With optimizations off, you consistently lose the race and the bug doesn't show up.

Re: Should you learn C to “learn how the computer works”?

#132

Post by jcelerier »

jerf wrote: post #63
chacham15 wrote: post #41

I find this article to be disingenuous. Yes, C isnt "how a computer really works". Neither is assembly. The way a computer works is based off of transistors and some concepts built on top of that (ALUs for example). However, there is no need to know about any of that because you're presented with an abstraction (assembly). And thats really what people mean when they say C is closer to how a computer actually works: i…

But in addition to the mismatch between the abstractions provided and the real hardware, C qua C is missing a huge number of abstractions that are how real hardware works, especially if we pick C99 as Steve did, which doesn't have threading since that came later. I don't think it has any support for any sort of vector instruction (MMX and its followons), it doesn't know anything about your graphics card which by raw…

> computer does not need to implement a stack and a heap and have copy-based functions and so on.

AFAIK intel cpus have a hardware stack pointer

Re: Should you learn C to “learn how the computer works”?

#133

Post by geofft »

jimmaswell wrote: post #94
geofft wrote: post #86

Earlier quoted context omitted.

> What that means is that most C operations can be easily translated into the machine code equivalents and that makes debugging of compiled code so much easier. A disassembly of many binaries will reveal their C roots by function calls being equivalent to jump statements, as an example. If you have the C source then you can usually figure out what's going on. This is very much not true in my experience. Optimization…

Why would you turn on optimization while debugging?

Because you're debugging a failure in production code. Extraordinarily common.

Re: Should you learn C to “learn how the computer works”?

#134

Post by Animats »

steveklabnik wrote: post #85
Animats wrote: post #61

What C teaches is that the underlying memory model is a flat, uniform, byte-addressed address space. One of the consequences of C is the extinguishing of machine architectures where the underlying memory model is not a flat, uniform, byte-addressed address space. Such as Symbolics or Burroughs architectures, or word-addressed machines.

We have our differences, but you’re totally correct here, and I’m not sure why you’re downvoted. The “byte addressable” thing is exactly why C was created over B, even, right? That was one of the crucial features not supported.

I'm not sure why C was created over B. ANSI C had more abstraction than K&R C; early versions of C didn't have function prototypes or type checking. There seems to have been a slow progression towards more abstractions, as the machines used for compiling got bigger. Many of the early bad decisions in C probably come from having to run the compiler in a very small, slow machine. Today we expect to get the whole program into an in memory data structure within the compiler, but that was not possible in the PDP-11 era.

C abstracts control flow, but not memory access. C data access is pretty much what the hardware gives you. Memory is bytes addressed by integers. There's even pointer arithmetic. C puts a layer of data structures on top of that, but the underlying memory model is one "(char *)" cast away. Every call to "write" implies that cast.

By the time you get to, say, Python or Javascript, that flat memory model is completely hidden. There could be a compacting garbage collector underneath, changing the addresses of everything while the program is running, and you'd never know.

Re: Should you learn C to “learn how the computer works”?

#135

Post by pq0ak2nnd »

t0mbstone wrote: post #130
ashleyn wrote: post #58

Earlier quoted context omitted.

C at the very least teaches the difference between stack and heap memory, a crucial concept obscured by most higher-level languages.

Just playing devil's advocate here... why is this such a "crucial" concept, for someone who is using a higher level language (like Python or Ruby)? If 99% of what that person does is gluing together APIs and software modules, and they can see their memory usages are well within range, why does it matter?

true. it's like interior decorator vs. interior designer

if you're just going to move couches around and put down throw pillows, who cares about a solid foundation of design fundamentals and architectural psychology.

Re: Should you learn C to “learn how the computer works”?

#136

Post by intrasight »

I learned how computers work by breadboarding CPUs from smaller logic components.

Learning how commercial CPUs work I did by programming the 6502 and 6800 using machine language and assembly language.

For learning how to write good assembly language, I compiled C into assembly language. So C definitely helped me learn.

Re: Should you learn C to “learn how the computer works”?

#137

Post by kens »

hfdgiutdryg wrote: post #71
jerf wrote: post #63

Earlier quoted context omitted.

But in addition to the mismatch between the abstractions provided and the real hardware, C qua C is missing a huge number of abstractions that are how real hardware works, especially if we pick C99 as Steve did, which doesn't have threading since that came later. I don't think it has any support for any sort of vector instruction (MMX and its followons), it doesn't know anything about your graphics card which by raw…

A computer does not need to implement a stack What general purpose computer exists that doesn't have a stack? Push/pop have been fundamental to all the architectures I've used.

Hardware stacks are a relatively recent feature (in historical terms) even though subroutine calls go way back. Many systems did subroutine calls by saving the return address in a register. On the IBM 1401, when you called a subroutine, the subroutine would actually modify the jump instruction at the end of the subroutine to jump back to the caller. Needless to say, this wouldn't work with recursion. On the PDP-8, a jump to subroutine would automatically store the return address in the first word of the subroutine.

On many systems, if you wanted a stack, you had to implement it in software. For instance, on the Xerox Alto (1973), when you called a subroutine, the subroutine would then call a library routine that would save the return address and set up a stack frame. You'd call another library routine to return from the subroutine and it would pop stuff from the stack.

The 8008, Intel's first 8-bit microprocessor, had an 8-level subroutine stack inside the chip. There were no push or pop instructions.

Re: Should you learn C to “learn how the computer works”?

#139

Post by steveklabnik »

jcelerier wrote: post #132
jerf wrote: post #63

Earlier quoted context omitted.

But in addition to the mismatch between the abstractions provided and the real hardware, C qua C is missing a huge number of abstractions that are how real hardware works, especially if we pick C99 as Steve did, which doesn't have threading since that came later. I don't think it has any support for any sort of vector instruction (MMX and its followons), it doesn't know anything about your graphics card which by raw…

> computer does not need to implement a stack and a heap and have copy-based functions and so on. AFAIK intel cpus have a hardware stack pointer

That's correct, but "does not need to implement" and "this kind of computer does implement" are not incompatible statements.

Re: Should you learn C to “learn how the computer works”?

#140

Post by geofft »

jreck wrote: post #68
chacham15 wrote: post #41

I find this article to be disingenuous. Yes, C isnt "how a computer really works". Neither is assembly. The way a computer works is based off of transistors and some concepts built on top of that (ALUs for example). However, there is no need to know about any of that because you're presented with an abstraction (assembly). And thats really what people mean when they say C is closer to how a computer actually works: i…

Except it isn't, not really. Even just the distinction between the stack & heap is wrong. They aren't different things, just different functions called on the otherwise identical memory. It's why things like Go work fine, because the stack isn't special. It's just memory. malloc & free are also totally divorced from how your program interacts with the OS memory allocator, even. GC'd languages don't necessarily sit on…

> Even just the distinction between the stack & heap is wrong. They aren't different things, just different functions called on the otherwise identical memory. It's why things like Go work fine, because the stack isn't special. It's just memory.

To add to this: I have seen people who learned C and thought it to be "close to the metal" genuinely believe that stack memory was faster than heap memory. Not just allocation: they thought that stack and heap memory were somehow different kinds of memory with different performances characteristics.

And the C abstract machine maps just fine to computers where the heap and stack are separate, unrelated address spaces, so this isn't even necessarily mistaken reasoning for someone who just knows C.

Post reply on HN