5 ms·

> C can be viewed as a pleasant, portable, assembly language. Do I have to buy what you're on from some guy on the street or is it available as a prescription?

> C can be viewed as a pleasant, portable, assembly language. Do I have to buy what you're on from some guy on the street or is it available as a prescription? > As such, it lets you "feel" the bare metal, much more so than a scripting language like Python or Javascript. C hasn't been bare metal since the PDP-11. There are like eight layers of abstraction between char *foo = "bar"; and the "bare metal"; I don't know why people are desperately clinging to this "C is basically portable assembly nonsense".

akubera 9y ago
https://godbolt.org/g/q01z7n https://godbolt.org/g/q01z7n I'm not sure what you mean by layers of abstraction (type checking? optimization?) but C code often does have a pretty straightforward translation to assembly. Perhaps you had a bad experience and can clarify what you mean?
chousuke 9y ago
Eight layers? That made me curious about how many are there really, though? My understanding is rather vague at this level, though hopefully good enough to know when I need to look deeper. So the compiler is obviously one layer. Then there's the assembler and the linker. Does the C runtime count too? You think you have a "string", but it's actually just an address to a (hopefully) nul-terminated chunk of "contiguous" virtual memory. If you wanted to read the first byte of that array, it would first go through the OS's virtual memory system, so that's one rather large abstraction. (I'm lumping in the hardware's virtual memory support here, too) Then when you actually access a piece of "real" memory, there are a number of caches between your data and the request to fetch it. And what about the DRAM itself? Can it access only a single byte of memory at a time, or is that too an abstraction? Instruction decoding is one or two layers at least, since chances are the processor doesn't actually execute x86 opcodes directly. And when you run out of software abstractions, how many levels of abstraction is there in the actual hardware? I only have vague ideas of what actually happens at this level, and whenever I stop to think about it, it's pretty amazing our software stacks work at all...

akubera 9y ago

https://godbolt.org/g/q01z7n https://godbolt.org/g/q01z7n I'm not sure what you mean by layers of abstraction (type checking? optimization?) but C code often does have a pretty straightforward translation to assembly. Perhaps you had a bad experience and can clarify what you mean?

chousuke 9y ago

Eight layers? That made me curious about how many are there really, though? My understanding is rather vague at this level, though hopefully good enough to know when I need to look deeper. So the compiler is obviously one layer. Then there's the assembler and the linker. Does the C runtime count too? You think you have a "string", but it's actually just an address to a (hopefully) nul-terminated chunk of "contiguous" virtual memory. If you wanted to read the first byte of that array, it would first go through the OS's virtual memory system, so that's one rather large abstraction. (I'm lumping in the hardware's virtual memory support here, too) Then when you actually access a piece of "real" memory, there are a number of caches between your data and the request to fetch it. And what about the DRAM itself? Can it access only a single byte of memory at a time, or is that too an abstraction? Instruction decoding is one or two layers at least, since chances are the processor doesn't actually execute x86 opcodes directly. And when you run out of software abstractions, how many levels of abstraction is there in the actual hardware? I only have vague ideas of what actually happens at this level, and whenever I stop to think about it, it's pretty amazing our software stacks work at all...