Funny enough, pointers are a great example of an abstraction provided by C that people assume is isomorphic to hardware, when they don't: https://blog.regehr.org/archives/1621
That said, I 10000% agree that pointers are a thing that is great to learn.
> You really should understand how things like .size or lengh() aren’t “free” and how they work.
You're talking about strings here, right? This is not true in all languages, but certainly is true that these are not free in C :)
> You're talking about strings here, right? This is not true in all languages, but certainly is for C :)
It costs O(1) in memory to delimit strings with a null terminator and O(n) in time to execute strnlen(), right? It's not free. Though, if you're lucky your string is in rodata and the compiler can calculate the sizeof() in advance, this is very-nearly-free.
Only if your strings are null terminated; many languages do not use null termination for various reasons, and that's one of them. "Pascal strings" being the nickname, given how old this idea is, and given it was a direct competitor to C at the time.
> > You really should understand how things like .size or lengh() aren’t “free” and how they work.
> You're talking about strings here, right? This is not true in all languages, but certainly is for C :)
I realize now that I misread this. It sounded as if you were saying '...but it is [free] for C', and on re-read I now understand that's not what you said at all.
Right. But some languages prefix the string data with its length and omit the null terminator. So, depending on if the struct is passed in registers, you could say .length is free, in that it wouldn't even need a load.
That assumes that all strings are C strings which isn't true. For example, Pascal-style strings have a size before the string data, and Rust and C++ strings have the size as metadata on stack and the string data in heap.
I think I may miss your meaning. In what sense is .size or length() not "free?"
At some point, some O(n) work was done somewhere to construct the n-element structure we're getting size on, but I don't think I've ever encountered a core library that implements .size as anything other than "Look up the cached length value that I computed the last time my length changed."
I think I just gave away the game on how long it's been since I programmed in C itself. Even C++ has "free" length() in std::string (in the sense that it's specified that it must be a constant-time operation).
... that's actually a good example of the trap of thinking of C as "what's really going on." If you assume C's treatment of char* is how strings have to be done, you're out of alignment with basically all other programming languages and you might be writing unnecessarily slow code (or forcing developers using your code to juggle a homegrown "length" abstraction that the underlying language should be juggling for them).
What really made computers click to me was reading a book that had the premise: "learn just enough assembly to be able to implement C features by hand; we'll show you how". Sadly, I don't remember the title.
Another revelation much later on, was, as discussed here, the realisation that C is indeed defined over an abstract machine. I think much of those realisations were because of reading about how crazy compiler optimizations can be and how UB can _actually_ do anything.
>When GCC identified “bad” C++ code, it tried to start NetHack, Rogue, or Towers of Hanoi. Failing all three, it would just print out a nice, cryptic error message.
The description is a little off. It was more a C thing than a C++ thing. And it was invoked by using any pragma; the gcc developers at the time had borderline religious objections to the idea of pragmas.
Nice! As of a couple months ago I'm actually going through the anime series again with my 9 year old. It's interesting getting his take on the characters, since it's a bit different than mine (and he's way younger than I was when I first watched it). For example, he's mostly bored by any Zoro fights, likely because at this point they are a lot of before and after cuts, but Zoro was always one of my favorite characters. We'll see if that continues, we're only just finishing the Spypeia arc.
I will say, waiting until he was capable and willing to read the subbed version was probably the right choice. Dubbed shows of any genre drive me nuts, and I'm not sure he would have the patience for the series if he was younger (the Alabasta arc was still taxing...). I do take a perverse pleasure in hinting about how crazy stuff becomes later, while also convincing him to not ruin it for himself by looking it up. ;)
I don't know if I'm in the should camp but beneficial? Yes, since so many things in programming might be taken for granted without seeing how things are done another level down. But then you could keep going all the way down, so who decides how far a student should go?
Do you need to learn C to have a successful career in CS or any other field? No. Should you learn it? Yes.
Do you need to bake bread to eat it? No. Should you learn to bake it? Yes.
There are lots of things you should learn to do because they're useful and teach you about how the world works. The miracle of society is that you don't have to learn most of them to enjoy using them.
That bread analogy is on point. The old quote comes to mind,
>A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyse a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -- Robert Heinlein
For one, it misses the fact that learning how to bake it doesn't benefit the eating process. Whereas, learning how to code in C benefits (but is not required) in general programming.
I understand that analogies are always compromises because there is always going to be something that differs from the original motif. Also, analogies should be used when the motif is complicated with many layers of abstraction and using one adds something - whether it is clarity, succicicty or reduction of abstraction. In the case of parent comment, it is not too difficult to understand the original motif. So, the bread analogy adds virtually nothing to it.
> For one, it misses the fact that learning how to bake it doesn't benefit the eating process.
Maybe it works differently for bread, but with whisky, learning how it has made has certainly enhanced my consumption, if only to give me the language needed to describe flavors and compare and contrast.
Worth noting that Heinlein didn't necessarily actually believe this himself. It's spoken by one of the many classic polymath characters which he liked to include in his stories.
Yes! I rarely use C these days to write Mobile Apps but knowing how to use C is absolutely great to be able to do some complicated things some times. It never hurts to be able know more than you need.
I learned assembly language before c which I suspect helped understand pointers. There are plenty of fun ways to learn assembly language. The game Shenzhen IO is one.
I also learned (m68000 & x386) asm before I learned C and subsequently C++ and I agree that having some asm knowledge helps learn how the machine works and how the higher level languages work as well. As for fun ways to learn asm, I'd recommend Core War (https://en.m.wikipedia.org/wiki/Core_War) - I had a lot of fun with that back in the day.
But, I also want to say; If you plan on learning modern C++, skip C. You will just have to unlearn a bunch of stuff when you switch.
I started with MASM because C cost money. By that I mean "Visual C++", and of course 12 year old me had no idea about GNU. I think I got through the MASM tutorials to the point of interacting with the Win32 api before finally figuring out I was doing it wrong.
I definitely found that C made more sense to me on my second attempt at it, after I'd done some assembly language programming. (But then I also had the advantage of another year or so of experience and a much better suited computer for C the second time around.)
I taught myself atmega328 C programming in a breadboard blinking led context last year and thought that was a wonderful learning experience. I sort of knew C, and didn't get much pointer practice, but it was great nevertheless.
Also, Stevens Advanced Programming in the Unix Environment is a great book to work through.
Coming from an operating system background, I find the article's use of "virtual machine" very bizarre. The article confuses very different things by stating that "'runtime', 'virtual machine' and 'abstract machine' are different words for the same fundamental thing".
"global" and "static" are pretty overloaded terms. In LLVM, for example, Global Value Numbering has nothing to do with global values. "const[ant]" is also pretty bad, but that's more because there's several slightly different notions where the distinctions between them are pretty important.
A java virtual machine runs java byte code. It makes sense because the compiler emits code for a machine that is an abstract concept, not something that physically exists, and the virtual machine executes this bytecode.
In typical use of a C compiler, you get code for the target processor, i.e. x86. In theory, you don't have to worry about the underlying hardware, so you could say you are programming for some abstract machine that runs C code, but it is much less meaningful than saying java has a virtual machine.
"Virtual machine" has a broader sense than emulation or virtualization within a hypervisor. From the perspective of an assembly programmer, C implements a low level virtual machine that abstracts much of the drudgery that assembly requires. For instance, you can store 32 signed bits in a variable without caring about the native word size and bit representation in the underlying hardware (though in some circumstances you may still care). That is the "virtual" part of C's abstraction.
Learning C has practical benefits, but gaining an understanding of how computers work is not one of them.
Learning an assembler would be more helpful in this regard, but in my opinion one might want to start with a very well-written article by Mark Smotherman: https://people.cs.clemson.edu/~mark/uprog.html
While I wouldn't suggest anyone learn C for the explicit purpose of learning how computers work, being familiar with pointers and memory allocation can go a long way.
Novice unity programmers struggle to understand why using classes (reference type in c#) in a game loop causes performance issues, but structs (value type in c#) are not as costly. For someone who has called malloc before, this isn't too hard to grasp, but before someone who sticks to garbage collected languages, it seems bizarre and arbitrary.
Of course memory allocation is an OS function, so this isn't "understanding the hardware," but it is a much deeper understanding of computers than not knowing what happens when you create an object.
Learning assembly and/or microarchitecture is another great way to get "knowing how the computer works," and is part of what I was hinting at at the end of the post when I said that C isn't fundamental here.
One of my favorite classes in college was Computer Architecture 1 and 2, which encompassed logic gates, Boolean logic, and progressed to assembly language usage. C was covered in other classes and was a natural next step from Architecture. I credit those classes a ton for my lower level knowledge.
I agree 100%, that was far and away the most valuable single class I took in college. We used the Tannenbaum book and a digital logic simulator, and worked up from basic gates into basic components (e.g. flip-flops and muxes, etc), then combined those into bigger components (ALU, registers, SRAM, etc), combined those into a toy 8-bit CPU, implemented cache and main memory, wrote an assembler that converted a small subset of x86 instructions into the opcodes for that toy CPU, then a limited dialect of C that generated that assembly code, that we converted to opcodes, that we ran on that simulated toy CPU.
It was probably the hardest course of my entire degree, and I ended up taking it twice, but at the end of the second go-round, computers were no longer a magic black box.
>It was probably the hardest course of my entire degree, and I ended up taking it twice,
Interesting. Did you study at a US univ.? I have not heard of being able to take the same course twice (except via, say, failing a year of the degree and having to repeat the whole year). I did hear that US universities are more flexible in some ways than, say, Indian ones, whose rules are probably based on British ones (maybe ones from much before); e.g. being able to mix and match courses, take longer than the standard 4 years for a degree, etc. I have American friends and relatives who told me that. But didn't know one could repeat a course. Seems like a useful feature.
I wasn't really ready to take it the first time (freshman spring...), and dropped it before the halfway point so I wouldn't take the hit on my GPA.
US colleges are all over the map with regards to how flexible they are about course order, and even between different degree programs at the same school. My alma mater had a somewhat weird trimester schedule and was relatively flexible about offering sections of courses year round - they had a bit of a housing shortage that made it impossible to house all the undergrads on campus at the same time.
Got it now, thanks. Interesting about US colleges. I was under the (wrong) impression earlier that all of them had that sort of flexibility about course order and more so, about degree duration. It was based on hearing things from a few friends. I guess I extrapolated, incorrectly.
C doesn't necessarily teach you how computers work. But it does teach you how software works. Our modern software empire is built on mountains of C, and deference to C is pervasive throughout higher-level software design.
>You may have heard another slogan when talking about C: “C is portable assembler.” If you think about this slogan for a minute, you’ll also find that if it’s true, C cannot be how the computer works: there are many kinds of different computers, with different architectures
As with many things, this phrase is an approximation. C is a portable implementation of many useful behaviors which map reasonably closely to tasks commonly done on most instruction sets. C programmers rarely write assembly to optimize (usually to capture those arch-specific features which are unrepresentable in C), but programmers in other languages often reach for C to write the high-performance parts of their code. The same reason C programmers in the early days would reach for assembly is now the reason higher-level programmers reach for C.
Or passing by value vs passing a pointer, or the importance of memory management...
Modern languages solve problems created developing in legacy languages (primarily C). The issue is that knowing a solution without knowing the prior problem which the solution addresses, doesn't really lend itself to clarity.
They don't solve problems created by C, they just solve problems C doesn't. The problems still exist, and sometimes the high-level compiler even picks the wrong solution. Learning C helps you understand when and why this has happened.
Arguably those problems did not exist before the C-era as software wasn't large or complicated enough. C++ directly attempts to improve over C by providing new mechanisms to solve problems encountered by C developers every day.
Point is that out of context, a lot of the things modern languages provide seem superfluous. Why have objects? Why have templates, closures, or lambdas? For a novice programmer, these are many answers for questions yet to be asked.
When you come from a heavy C background and you encounter something like templates, you know EXACTLY what this is for and wish you had it years ago.
I'm as hardcore as they get C programmer and I'm having a ball with C# for this very reason.
When I see templates, I run in the opposite direction at a dead sprint. C++ has added very little of value to the language and templates are one of their worst offerings. Metaprogramming is an antipattern in C.
You can write bad code in any language, C is no exception. We also see people persistently arguing in favor of simpler and less magical C. If you want reliable, maintainable code in any language, do not use magic. Metaprogramming is cool, no doubt about it, but it's unnecessary and creates bad code.
There are many languages which have undefined behavior.
C does have a lot of it, and it can be anywhere. In many languages, you can cause undefined behavior through its FFI. Some languages, like Rust, have UB, but only in well-defined places (a module containing unsafe code, in its case).
If a language lets you cause undefined behaviour via FFI into C, I think it's fair to say that that remains a problem created by C.
I do take your point about Rust, but I'd see that as deriving from LLVM's undefined behaviour which in turn descends from C; I'm not aware of any pre-C languages having C-style exploding undefined behaviour or of any subsequent languages inventing it independently.
> I think it's fair to say that that remains a problem created by C.
That is fair, however, I don't think it's inherently due to C. Yes, most languages use the C ABI for FFI, but that doesn't mean they have to; it's a more general problem when combining two systems, they cannot track statically the guarantees of the other system.
With Rust, it has nothing to do with LLVM; it has to do with the fact that we cannot track things, that's why it's unsafe! Even if an implementation of the language does not use LLVM, we will still have UB.
> With Rust, it has nothing to do with LLVM; it has to do with the fact that we cannot track things, that's why it's unsafe! Even if an implementation of the language does not use LLVM, we will still have UB.
I can see that any implementation of unsafe Rust would always have assembly-like unsafeness (e.g. reading an arbitrary memory address might result in an arbitrary value, or segfault). But I don't see why you would need C-style "arbitrary lines before and after the line that will not execute, reads from unrelated memory addresses will return arbitrary values" UB?
You are right that there's no inherent need for UB. However, we made the choice to have it.
The reason to have it is the exact same reason that the distinction between "implementation defined" and "undefined" exists in the first place: UB allows compilers to assume that it will never happen, and optimized based on it. That is a useful property, but it's a tradeoff, of course.
> I don't see why you would need C-style "arbitrary lines before and after the line that will not execute, reads from unrelated memory addresses will return arbitrary values" UB
This reason this happens is because we don't compile things down to obvious assembly, they get optimized. Each of those optimizations requires assumptions to be made about the the code. If you break those assumptions, then the optimizations can result in arbitrary results happening. Those assumptions determine what is and isn't UB.
Most languages just don't give the programmer any way to break those assumptions, but languages like C and Rust do. Thus, Rust will always have this 'problem' because it can/will make even more aggressive optimizations then C will, meaning badly written `unsafe` code will have arbitrary behavior and results from the optimizer if the compiler doesn't understand what you're doing.
This is literally true but also overly reductive; we do make certain kinds of guarantees, even if there isn't a full specification of the entire language yet.
The reason that a spec is taking so long is that we're interested in making an ironclad, really good spec. Formal methods take time. C and C++ did not have specs for much, much longer than the three years that Rust has existed. We'll get there.
In my opinion as an onlooker of Rust, it seems more interested in shiny features and breaking the language every month than in becoming stable and writing a spec. It's far from replacing C in this regard.
What breaks in the language every month? That’s not the experience our users report. There are some areas where we do reserve the right to tweak things, but we take great care to ensure that these breakages are theoretical, rather than an actual pain. We have large (hundreds of thousands of LOC, and maybe even a few 1MM ones) code bases in production in the wild now, we cannot afford to break things willy-nilly.
You are right that we are far, but that’s because it’s a monumental task, and it’s fundamentally unfair to expect equivalence from a young language. It is fair to say that it is a drawback.
The language doesn't break as much today, but what constitutes "idiomatic" Rust is constantly changing. I don't use Rust but I spend a lot of time with people who do and am echoing what I've heard from them, and seen for myself as a casual user of Rust software and occasional drive-by contributor.
It doesn't have to be a monumental task. Rust is simply too big, and getting bigger.
But C never set out to be what it is today. It was a long time before anyone thought a spec was worth writing. For a language with the stated design goals of Rust, a specification and alternative implementations should be priority #1. You can't eliminate undefined behavior if you don't define any!
Memory management in C is very different than memory management in JavaScript, which throws exceptions when you try to access invalid memory, but will gladly let you create memory leaks inside event callbacks or other loops and keep chugging along gladly until it can't anymore. Writing a safe, efficient, high performing JavaScript app is very different than writing the same thing in C, and although I know both deeply well, I don't think learning C has helped me write better JS.
After recently (1 year) learning Rust I noticed that Rust teaches about low-level CS concepts of passing by value vs passing by pointer a lot better than C. Because you not just have references and values, but also have to think about richer semantics of what you are trying to do: sharing, mutability, and move semantics. So you learn not only that a few low level concepts exist, but you also learn how to use them correctly.
You're joking. There's a very serious distinction between the stack and the heap - perhaps they live in the same memory but they are used very differently and if you mix them up your things will break.
There is no hardware distinction between stack memory and heap memory.
In fact C teaches a model of a semi-standard virtual architecture - loosely based on the DEC PDP7 and/or PDP11 - which is long gone from real hardware.
Real hardware today has multiple abstraction layers under the assembly code, and all but the top layer is inaccessible.
So there's no single definitive model of "How computers work."
They work at whatever level of abstraction you need them to work. You should definitely be familiar with a good selection of levels - and unless you're doing chip design, they're all equally real.
I'm not sure it really pretends that there is so much a distinction so much as C supports stack allocation/management as a language feature, but heap support is provided by libraries.
There are significant performance and strategy differences between the stack and the heap. On the stack, allocation is cheap, deallocation is free and automatic, fragmentation is impossible, the resource is limited, and the lifetime is lexically scoped.
On the heap, allocation might be cheap or it might be expensive, deallocation might be cheap or it might be expensive, fragmentation is a risk, the resource is 'unlimited', and the lifetime is unscoped.
Your statement is equivalent to saying "there's no difference between pointers and integers" - technically, they are both just numbers that live in registers or somewhere in memory. In reality, that approach will not get you far in computer science.
Those performance and strategy differences only exist inside C or other high-level languages, as a result of abstractions created by those languages. They are not in any way reflective of "the computer."
By all means it's certainly a valuable abstraction, one that most high-level languages support. But that's like how functions are a valuable abstraction, or objects, or key-value stores, or Berkeley sockets. Learning those abstractions is absolutely important and also completely irrelevant to understanding "the computer".
(As Dijkstra once said, computer science is no more about computers than astronomy is about telescopes. Learning C is valuable for computer science, but that doesn't mean it gives you a deep understanding of the computer itself.)
You are more than welcome to use a stack in an assembly language too. What you say certainly can be true, but many architectures include dedicated stack pointer registers and operations to manipulate them, either special-purpose (AVR, __SP_H__ and __SP_L__, push, pop) or more generic (x86 %sp, push, pop). I'd argue that functions exist at the hardware level to some extent too in architectures that support, for instance, link registers (PPC $LR) and special instructions (call, ret instead of a generic jump family). Calling conventions, sure, are an attraction over functions.
Well, you can just write a naive allocator that just bumps pointer and never deallocates things :). To appreciate stack vs heap, you have to learn a bit about memory management and some basic algorithms like dlmalloc, imho.
> On the heap, allocation might be cheap or it might be expensive, deallocation might be cheap or it might be expensive,
In other words it might behave just like "the stack"; the differences between different kinds of "heaps" are as large or larger than the difference between "the stack" and "the heap".
> fragmentation is a risk, the resource is 'unlimited', and the lifetime is unscoped.
None of these is true in all implementations and circumstances.
Understanding the details of memory management performance is important for particular kinds of programming. But learning C's version of "the stack" and "the heap" will not help you with that.
I'd argue that given special purpose registers exist on most platforms to support a stack, and instructions dedicated to manipulating them (x86 %sp, push, pop) that the stack is in fact a hardware concept. The heap, however, is left as an exercise to the reader.
> I'd argue that given special purpose registers exist on most platforms to support a stack, and instructions dedicated to manipulating them (x86 %sp, push, pop) that the stack is in fact a hardware concept.
True enough; however sometimes access to "the heap" (in C terms) will use those instructions, and sometimes access to "the stack" will not. Learning one or two assembly languages is well worth doing, since they offer a coherent abstraction that is genuinely relevant to the implementation of higher-level languages. Not so C.
> Your statement is equivalent to saying "there's no difference between pointers and integers" - technically, they are both just numbers that live in registers or somewhere in memory. In reality, that approach will not get you far in computer science.
No, because in reality those are handled by different computational units. Integers are handled by the ALU, and pointers are handled by the loader. They are distinct things to the CPU.
Stack & heap have no such distinction. There isn't even a heap in the first place. There's as many heaps of as many sizes as you want, as the "heap" concept is an abstraction over memory (strictly speaking over virtual address space - another concept C won't teach you, yet is very important for things like mmap). It's not a tangible thing to the computer.
Same with the stack. It's why green-threads work, because the stack is simply an abstraction over memory.
> No, because in reality those are handled by different computational units. Integers are handled by the ALU, and pointers are handled by the loader. They are distinct things to the CPU.
I strongly disagree. Yes some execution units are more let's say "dedicated" to pointers than other, and obviously ultimately you will dereference your pointers, so you will load/store, but compilers happily emit lea to do e.g. Ax9+B and in the other direction, add or sub on pointers. Some ISA even have almost no pointer "oriented" register (and even x64 has very few)
Exactly, this will vary wildly between architectures. I would accept the statement on, for instance, a Harvard architecture but the world is a lot more nuanced in the much more common von Neumann architecture.
No no, haha, that's also not quite right. You can save the stack frame to memory then load it back which is what green threads do [1]. This includes the register state also, which is not what we're talking about here when we say "stack" -- we're referring to stack variables, not full frames. Full frames are even further from the heap, by virtue of including register states which must be restored also.
Although, it sounds like you're agreeing with me that there is in fact a difference between the stack and the heap because to your point one exists supported at the hardware level with instructions and registers, and one doesn't exist or can exist many times over. Hence, different.
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.
Yep. In truth, one can almost never win the argument of, "...but do I really need to know this?" But people should be aware that knowing fundamental things provides insight and advantages.
For sure, but there are diminishing returns. My rule of thumb is that understanding two levels of abstraction below whatever you're doing is usually worth it.
It's also like fluid dynamicist vs quantum physicists. If you're just going to move oil around and put down differential equations, who cares about a solid foundation of quantum gravity and chromodynamics.
I can’t make a thorough argument, but u/flyinglizard (in a comment adjacent to mine) mentioned what I was thinking: Ruby/Python almost entirely abstracts the concept of pointers, references, and memory. For beginners and intermediates, it’s not a big deal until you get mutable data structures like lists and dicts. When I learned CS, we were taught C/C++ first, and I remember the concept of mutability and object identity being not at all difficult.
Without being able to refer to fundamental structures and concepts, I usually just exclusively teach students non-mutable patterns (e.g. list.sorted vs list.sort), while pushing them to become much proactive at inspecting and debugging.
Compared to people who know only high level languages I have noticed that with my C background I can figure out performance problems better because I have an idea how the higher languages are implemented.
Because we haven't figured out a large body of non-leaky
or resilient abstractions yet. If a higher level construct was indeed a true superset of lower level functionality, or was robust enough to be applied to a wide variety of situations, then it would be okay. Right now in web software, because we optimize for development velocity so heavily, the tools a smaller product would reach for are fundamentally different from the tools a very high load service would. Until we can come up with a set of robust higher level abstractions that scale well (or better than they currently do) then we'll be stuck where we're at. Thread pools will saturate, GC will stutter, sockets will timeout, and all sorts of stuff that higher level abstractions do not capture well.
(I kept this post vague but can offer concrete examples of you'd like)
No. In the machine model used by Go, everything is allocated on the heap. The optimizing part of the compiler can then move allocations from the heap onto the stack if it can prove that the allocation does not escape the lifetime of a stack frame.
There is no difference inside the computer between those concepts.
For convenience, many architectures have a single assembly instruction for taking one register (called the "stack pointer"), adjusting it by a word, and moving a register to the address at that word, and a corresponding instruction to move data back to a register and adjust it in the other direction. That's the extent of the abstraction. You can implement it with two instructions instead of one, and then you get as many stack pointers as you want. Zero, if you want.
There is no "heap" on modern OSes. There used to be a thing called the program break, beyond which was the heap. It's almost meaningless now. You ask for an area of virtual memory via mmap or equivalent; it is now one of several heaps you have.
And you can pass around pointers from all your stacks and all your heaps in the same ways, as long as they remain valid.
You need to understand this in order to understand how thread stacks work (you typically allocate them via mmap or from "the heap"); how sigaltstack works and why you need it to catch SIGSEGV from stack oveflows; how segmented stacks (as previously used in Go and Rust) work; how Stackless Python works; how to share data structures between processes; etc.
And some, such as RISC-V, have no predefined stack pointer at all. (Push and pop are implemented by doing them manually; call is implemented by the jump instruction optionally taking an argument for a register to use as the stack.) C, at best, teaches you the C abstract machine, which supports both of these concrete implementations equally well.
I think this is lawyering a bit. There might not be a "heap", per se, but there is stack allocation (which is embedded all the way into the ISA) and "everything else". You can, after all, build a simple "heap" on top of an adequately large static buffer.
Since this is a distinction that is very important both for performance in high-level languages and for correctness in C, and one C forces you to think about and makes plain without having to reason through escape analysis and closures, I think the previous comment's point is well taken.
Stack allocation of return addresses is embedded in most ISAs- but stack allocation of local variables isn't (because that's not A Thing at the ISA level).
Consider, say, shadow stacks- local variables might end up living on a totally separate "stack" from the one "call" pushes onto and "ret" pops from, and one which the ISA has no idea about.
In what sense is stack-relative addressing, PUSH, POP, and addition/subtraction on the stack pointer not ISA-level support for stack allocation of local variables?
Addition, subtraction, and stack-relative addressing are, in most architectures I'm familiar with, generic- stack-relative addressing ends up just being a special case of register-relative addressing, and addition and subtraction are rather important instructions in their own right.
PUSH/POP are more obviously "hey store your locals on the stack, kids", but on, say, x64, how often do you actually see a push instead of bp/sp-relative addressing? Most compilers seem to be much happier representing each stack frame as "a bunch of slots, some for things where the address is taken so it needs to be in memory, and others where I spill things into as needed".
On ARMv7 (i don't know enough about v8 / AARCH64), "push"/"pop" are just stores/loads with postdecrement / postincrement.
Is this lawyer-y? Sure. But I think it's still correct, and this being HN...
There's a reason 32-bit ARM has 'move base register down and then do some stores' and 'do loads and then move base register up' (stmdb and ldmia) rather than just plain old ldm and stm, and I'm pretty sure it's because it makes the entry and exit sequences for function calls with a stack shorter. (The ARM ISA doesn't privilege a downward growing stack, so you can use stmib and ldmda if you want your stack to grow upward; the Thumb ISA, however, does want a downward stack for push and pop.)
That's definitely a large part of it, but it also makes small memcpys nicer (load sizeof(foo)/4 registers from sourceptr with post increment, store them to destptr with post increment)
On x86, push/pop have dedicated hardware optimizations known as the stack engine which perform most of the rsp increments/decrements and passes those offsets into the decoder, instead of using executions slots on them. push/pop are also much smaller than the corresponding mov/add instructions.
It's much more optimal to use a series of push/pops for smaller operations like saving registers before a call than to manually adjust and store onto the stack.
While technically this is still incrementing/decrementing a register and storing, the amount of isa/hardware support for such things clearly demonstrates that the x86 isa and modern x86 hardware gives special treatment to the stack.
The distinction is important for apartmented thread models, such as those found on Windows, where you do have multiple heaps, and pointers allocated on one are not valid in another.
They may not be distinguished at the instruction level, but if you’re trying to argue it’s not a useful thing to teach you’ve lost me. Dynamic vs static vs scoped (stack) allocation is incredibly important to reasoning about basic programs.
Like I established in my opening comment, C tells you how software works, not how hardware works. Regardless, you're still wrong in several ways here. Making it out of several discontinuous regions of memory doesn't make your heap less of a heap. Most architectures also provide instructions for loading data from the stack and optimize for this purpose, using their caches more efficiently and making design decisions which have clearly been influenced by the C (or System V) ABI.
There are no occurrences of the words "stack" or "heap" in this document.
What the spec actually discusses is "storage durations". Now, in many cases you can say, well, "automatic storage duration" means it's on the stack, but that's not something C has any opinions about.
If you want to know about the stack and the heap, saying "learn C, and then learn how these abstract C concepts map onto the stack and the heap" might not actually be the best way to figure this stuff out.
What actually ends up happening, in my experience, is that to figure C out you have to get a decent mental model of how the stack and heap work, and then, from that, say "automatic storage duration and malloc/free are basically just the stack and the heap".
I learned calculus as a kid because I needed it for an online electronics class I was taking. But I'm not going to recommend that folks take electronics classes so they learn calculus! (that said- having a motivation to learn something, having an application in mind, a problem you want to solve... certainly seems to make learning easier.)
"C" doesn't just include the spec but also the customary semantics [1] of the language. The customary semantics certainly include the stack and the heap.
At some point, these conversations seem to always turn into a contest to see who can be the most pedantic. Which I think is pretty fun - and pretty well in the spirit of the original article - but that's me, and I can't fault anyone for being turned off by it.
's funny, I am certainly aware of having, at some point, at least skimmed over the C99 standard encountered the concept of a storage duration. But, aside from that brief few hours, virtually the entirety of my C-knowing career has been spent thinking and talking in terms of stacks and heaps.
Meanwhile, in my .NET career, I really did (and, I guess, still do) feel like it was important to keep track of how .NET's distinction is between reference types and value types, and whether or not they were stack or heap allocated was an implementation detail.
Debates about the "stack" rage every couple of years on comp.lang.c. Invariably people conflate two different meanings: (1) an abstract data structure with LIFO ordering semantics, and (2) #1 implemented using a contiguous block of [virtual] memory.
The semantics of automatic storage necessarily imply #1, but they do not require #2. Indeed, there are widely used implementations which implement #1 using linked lists (e.g. IBM mainframes, and GCC's split stacks or clang's segmented stacks).
Similarly, function recursion semantics necessarily imply #1 for restoring execution flow, but not #2. In addition to the examples above, so-called shadow stacks are on the horizon which maintain two separate stacks, one for function return addresses and another for data.[1] In the near future a single contiguous stack may be atypical.
[1] Some variations might mix data and return addresses if the compiler can prove safe object access. Or the shadow stack may simply contain checksums or other auxiliary information that can be optionally used, preserving ABI compatibility.
And just going to throw out there that IA64 split the function return stack and data stack into different hardware stacks, so they've been out for twenty years at this point at least.
They just call stack allocation "automatic storage duration" in the spec. If you read it, you pretty much have to implement it as a stack; you just don't have to keep the frames contiguous in memory. They still need to maintain stack style LIFO access though, so the only spec compliant implementations that don't use a traditional stack have back pointers in each frame to maintain stack style LIFO semantics.
I think I only got a reasonable understanding on the stack and heap concepts when I got to make a compiler in my undergrad classes. Some 2 years after I learned C.
I'm not even sure the C memory model depends on the code/stack/heap separation.
On hardware level, all those use von Neumann architecture. Wasm, however, exposes Harvard architecture (implemented on top on von Neumann machines). Yet, you can compile C to Wasm, which is a data point about how abstract C is: so abstract that it can target Harvard architecture despite targeting just von Neumann architecture being sufficient for targeting modern hardware.
I spent like a thousand dollars on the box sitting under my desk; I'm pretty sure my C code runs on special hardware too. ;)
(and worth noting: if I pull out the special hardware you're thinking of from that box, my particular thousand-dollar-box is no longer able to run software I need because the GUI requires a graphics accelerator card. The OS authors have already reached for a subset of CUDA to optimize the parts of the GUI that needed optimization).
Our popular software stacks are written in C and C++, but that's more because of history than anything else. I rarely reach for just "classic" C for performance anymore. These days I'm more likely to reach for GPUs, SIMD intrinsics (available in Rust), or at least Rust/Rayon for code that needs maximum performance.
C is fundamentally a scalar language. In 2018, the only code for which "classic" C is the fastest is code that exhibits a low level of data parallelism and depends on dynamic superscalar scheduling. Fundamentally sequential algorithms like LZ data compression, or very branchy code like HTTP servers, are examples. This kind of code is becoming increasingly less prevalent as hardware fills in the gaps. Whereas we used to have C matrix multiplies, now we have TPUs and Neural Engines. We used to have H.264 video codecs, but now we have huge video decoding blocks on every x86 CPU Intel ships. Software implementations of AES used to be the go-to solution, but now we have AES-NI. Etc.
As an example, I'm playing around with high-performance fluid dynamics simulations in my spare time. Twenty years ago, C++ would have been the only game in town. But I went with TypeScript. Why? Because the performance-sensitive parts are GLSL anyway--if you're writing scalar code in any language, you've lost--and the edit/run/debug cycle of the browser is hard to beat.
I'd argue that GPUs and SIMD instructions have so many restrictions that they're useless for general purpose computing. Yeah, they have niche spaces, but in terms of all the different kinds of programs we write, I think those spaces are going to remain niche.
Depends on what you mean by "general purpose computing". Is machine learning general purpose? Are graphics general purpose? Is playing video and audio general purpose? If those aren't general purpose, I'm not sure what "general purpose" means.
GPUs and other specialized hardware aren't good at everything, and I acknowledged as much upthread, but the set of problems they're good at is large and growing.
Vectorised processing is a win according to that paper: it is faster than scalar code. The key point of the paper is that compiled queries---doing loop fusion---is sometimes more of a win (in a database context, where "vectorisation" doesn't always mean SIMD as in this discussion).
Doing fused SIMD-vectorised operations will likely bring the advantages of both, with relatively small downsides. This is a relatively common technique for libraries like Eigen (in C++), that batch a series of operations via "Expression Templates" and then execute them all in as a single sequence, using SIMD when appropriate. (Other examples are C++ ranges and Rust iterators, although these are focused on ensuring loop fusion and any vectorisation is compiler autovectorisation... but they are written with that in mind: effort is put into helping the building blocks vectorise.)
> Our modern software empire is built on mountains of C, and deference to C is pervasive throughout higher-level software design.
This I agree with and also I'd call the most important reason for Rust programmers to learn C. The C ABI is a lingua franca, not because it's good or pure but (as with spoken linguas franca) happened to be in the right place at the right time. It defines certain conventions and assumptions that didn't have to be assumed (implicit stack growth without declared bounds, single return value, NUL-terminated strings, etc.) and a lot of software is written to it, to the point that if you want your (e.g.) Python code and Rust code to interoperate, the easiest way is to get them to both speak C-compatible interfaces, even though you're not writing any actual C code.
Yup. In compiled-languages land it's common to see things that are API-compatible but not ABI-compatible: the compiled objects don't work together, but if you recompiled the same source code it would work with no changes. This happens (sometimes) when you do things like reorder members of a structure or switch to a larger integer type for the same variable.
C and libc have been ABI-stable on most platforms for decades. C++ on some platforms (e.g., GNU) is stable with occasional ABI breakages in the standard library; on others (e.g., MS Visual C++) it breaks with new compiler versions. Rust isn't ABI-stable at all and has no clear plans for it, despite a strong commitment to API stability (i.e., old code will compile on new compiler versions). Swift 5 is targeting ABI stability.
> Our modern software empire is built on mountains of C, and deference to C is pervasive throughout higher-level software design.
this is the key. If you want a real-world view into how the kernel is written (i.e. more of the computer), then C is the only practical choice. Sure, you can write an OS in Java, Haskell, OCaml, etc. But it's roundabout. So, I think the statement, "learn how a computer works more by leveraging C" is valid.
I don't disagree with anything you said, but I wanted to point out you also don't disagree with the author. Your point ("this phrase is an approximation") is also the author's point. I felt he walked through the why fairly and with nuance.
Exactly. Maybe we could say that for 99% of software C is the lowest level. Its implemented in something, that's implemented in something, that's implemented in C. So, if you learn it, you can understand your software stack completely.
Also, C is learn once, write anywhere. If there is some kind of computer, then there is probably a C compiler for it. That's not true of any other language to the same extent. Know C and you can program anything.
C is a useful and universal model of computation not just because most native software is ultimately built on C, but because any hardware that people end up widely using also has to have a sensible C compiler.
The C model is relatively close, I’ve heard, to the hardware of a PDP-11. But there have been tons of abstractions and adaptations on both sides of that coin ever since; not only can a C program provide a language runtime that behaves quite differently from a PDP-11, but the C program itself is compiled to machine code that is sometimes quite different than the code for a PDP-11, and even the low level behavior of the CPU often differs from what’s implied by the ISA. And while all of these models of computation are Turing equivalent, the transformations to and from C are very well known.
There's some charm to it, but in general, assembly languages is far too low level to solve much of any interesting problem (unless the problems one is interested in are in the domain of "How do I reduce this compiler to an assembly implementation so I can use this language on a specific piece of hardware?"). So you may run into some real challenges retaining student interest.
But I think it's a good suggestion; I certainly learned a bit from learning Apple's assembly on the ][c that I hadn't encountered elsewhere.
I think that in order have true mastery of C, one must understand why certain things are undefined. For example signed integer overflow is undefined. Why? Well different architectures handle overflow in their own ways (saturating vs modulo arithmetic, twos compliment). C can a great way to learn about computers in general vs assembly on a specific architecture--unless you approach C undefined behavior as most undergrads do and proclaim how arbitrary the silly C language spec is.
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: its a language with fewer abstractions than many others (most notably, its lack of garbage collection, object oriented behaviors, and a small runtime). That lack of abstraction means that you have to implement those concepts if you want to use them which will give you an understanding of how those abstractions work in the language that has them built in.
> 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).
I'd argue you should know how that works.
Cache-misses, pipelining and all these subtle performance intricacies that seem to have no rhyme or reason just fall out out understanding exactly how you get shorter clock cycles, different types of memory and the tradeoffs that they present.
One of the best things I ever did was go build a couple projects on an FPGA, when you get down to that level all of these leaky (performance) abstractions are clear as day.
That'd be like saying your end user should understand cache misses, however if you're starting a car design/repair shop you might want to know about how transmissions work.
The primary reason for dropping down to native is to get better performance. If you're going to do that you'll leave 10x-50x performance on the table if you don't understand cache misses, prefetching and the other things that manual memory placement open up.
I'm not going to play anymore metaphor/semantic games. It's nice that you did that project, but it's not at all necessary for someone to engage in that in order to understand performance issues.
You're the one that raised the metaphor, but okay?
I'm not saying that you can't do performance work without having done that. Just that you'll be at a disadvantage since you're at the mercy of whatever your HW vendor decides to disclose to you.
If you know this stuff you can work back from from first principals. With a high level memory architecture of a system(say tiled vs direct rendering GPU) you can reason about how certain operations will be fast and will be slow.
And your response was absurd. You don't rebuild a transmission in order to run a shop. You don't even rebuild a transmission as an engineer creating cars, you shop that out to an organization specializing in the extremely difficult task of designing and building transmissions. I wanted to avoid this waste of time, but here we are.
As for the rest of your comment about reasoning about performance, none of that requires the work you did. Again, neat project (for you), but completely unnecessary in general.
Given how many person-years have been saved and how much value has been produced by "slow, bloated, inefficient software", I must disagree in the strongest possible terms. Producing "slow, bloated, inefficient software" is far, far preferable to not producing software at all.
I would rather have no software or write the software myself than waste all the time of my life I've had to waste because of such shitty software, and it is indeed the case I've had to write such software from scratch because the alternatives were utter garbage. So we deeply, vehemently disagree.
I would go further and say that how modern computers work at the level that interests most people is somewhat based on C. It would be very different with another hardware abstraction paradigm such as Lisp Machines (as their name suggests), but that's not what we have :).
EDIT: I was going to update my comment a bit now that I thought more about it and that I'm on a computer rather than a mobile phone, but in the meantime jerf posted a very good reply to the parent comment so just read that ^^.
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 FLOPS may well be the majority of your machine's actual power, I don't think C99 has a memory model, and the list of things it doesn't know about goes on a long ways.
You can get to them from C, but via extensions. They're often very thin and will let you learn a lot about how the computer works, but it's reasonable to say that it's not really "C" at that point.
C also has more runtime that most people realize since it often functions as a de facto runtime for the whole system. It has particular concepts about how the stack works, how the heap works, how function calls work, and so on. It's thicker than you realize because you swim through it's abstractions like a fish through water, but, technically, they are not fundamental to how a computer works. A computer does not need to implement a stack and a heap and have copy-based functions and so on. There's a lot more accidental history in C than a casual programmer may realize. If nothing else compare CPU programming to GPU programming. Even when the latter uses "something rather C-ish", the resemblance to C only goes so deep.
There's also some self-fulfilling prophecy in the "C is how the computer works", too. Why do none of our languages have first-class understanding of the cache hierarchy? Well, we have a flat memory model in C, and that's how we all think about it. We spend a lot of silicon forcing our computers to "work like C does" (the specification for how registers work may as well read "we need to run C code very quickly no matter how much register renaming costs us in silicon"), and every year, that is becoming a slightly worse idea than last year as the divergence continues.
RISC-type architectures with a branch-and-link instruction (as opposed to a jsr- or call-type instruction) generally have a stack by convention only, because the CPU doesn't need one to operate. (For handling interrupts and exceptions there is usually some other mechanism for storing the old program counter.)
I don't have direct experience, but I believe that system/360 programs have historically not had stacks, opting instead for a statically allocated 'program save area'.
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.
From the perspective of "stack" as an underlying computation structure: Have you ever played a Nintendo game? You've used a program that did not involve a stack. The matter of "stack" gets really fuzzy in Haskell, too; it certainly has something like one because there are functions, but the way the laziness gets resolved makes it quite substantially different from the way a C program's stack works.
If a time traveler from a century in the future came back and told me that their programming languages aren't anywhere as fundamentally based on stacks as ours are, I wouldn't be that surprised. I'm not sure any current AI technology (deep learning, etc.) is stack-based.
From the perspective of "stack" as in "stack vs. heap", there's a lot of existing languages where at the language level, there is no such distinction. The dynamic scripting language interpreters put everything in the heap. The underlying C-based VM may be stack based, but the language itself is not. The specification of Go actually never mentions stack vs. heap; all the values just exist. There is a stack and a heap like C, but what goes where is an implementation detail handled by the compiler, not like in C where it is explicit.
To some extent, I think the replies to my post actually demonstrate my point to a great degree. People's conceptions of "how a computer works" are really bent around the C model... but that is not "how a computer works". Computers do not care if you allocate all variables globally and use "goto" to jump between various bits of code. Thousands if not millions of programs have been written that way, and continue to be written in the embedded arena. In fact, at the very bottom-most level (machines with single-digit kilobytes), this is not just an option, but best practice. Computers do not care if you hop around like crazy as you unwind a lazy evaluation. Computers do not care if all the CPU does is ship a program to the GPU and its radically different paradigm. Computers do not care if they are evaluating a neural net or some other AI paradigm that has no recognizable equivalent to any human programming language. If you put an opcode or specialized hardware into something that really does directly evaluate a neural net without any C code in sight, the electronics do not explode. FPGAs do not explode if you do not implement a stack.
C is not how computers work.
It is a particular useful local optimum, but nowadays a lot of that use isn't because "it's how everything works" but because it's a highly supported and polished paradigm used for decades that has a lot of tooling and utility behind it. But understanding C won't give you much insight into a modern processor, a GPU, modern AI, FPGAs, Haskell, Rust, and numerous other things. Because learning languages is generally good regardless, yes, learning C and then Rust will mean you learn Rust faster than just starting from Rust. Learn lots of languages. But there's a lot of ways in which you could equally start from Javascript and learn Rust; many of the concepts may shock the JS developer, but many of the concepts in Rust that the JS programmer just goes "Oh, good, that feature is different but still there" will shock the C developer.
> We spend a lot of silicon forcing our computers to "work like C does" (the specification for how registers work may as well read "we need to run C code very quickly no matter how much register renaming costs us in silicon"
Can you elaborate? I thought I knew what register renaming was supposed to do, but I don't see the tight connection between register renaming and C.
Register renaming was invented to give assembler code generated from C enough variables in the forms of processor registers, so that calling functions wouldn't incur as much of a performance penalty.
The UltraSPARC processor is a stereotypical example, a RISC processor designed to cater to a C compiler as much as possible: with register renaming, it has 256 virtual registers!
Register renaming is older than C (the first computer with full modern OoOE was the 360/91 from 1964). It has more to do with scheduling dynamically based on the runtime data flow graph than anything about C (or any other high level language).
Agreed with your historical information, but the comment about function calls and calling conventions is not without merit. If you have 256 architectural registers you still can't have more than a couple callee-save registers (otherwise non-leaf functions need to unconditionally save/restore too many registers), and so despite the large number of registers you can't really afford many live values across function calls, since callers have to save/restore them. Register renaming solves this problem by managing register dependencies and lifetimes for the programmer across function calls. With a conventional architecture with a lot of architectural registers, the only way you can make use of a sizable fraction of them is with massive software pipelining and strip mining in fully inlined loops, or maybe with calls only to leaf functions with custom calling conventions, or other forms of aggressive interprocedural optimization to deal with the calling convention issue. It's not a good fit for general purpose code.
Another related issue is dealing with user/kernel mode transitions and context switches. User/kernel transitions can be made cheaper by compiling the kernel to target a small subset of the architectural registers, but a user mode to user mode context switch would generally require a full save and restore of the massive register file.
And there's also an issue with instruction encoding efficiency. For example, in a typical three-operand RISC instruction format with 32-bit instructions, with 8-bit register operand fields you only have 8 bits remaining for the opcode in an RRR instruction (versus 17 bits for 5-bit operand fields), and 16 bits remaining for both the immediate and opcode in an RRI instruction (versus 22 bits for 5-bit operand fields). You can reduce the average-case instruction size with various encoding tricks, cf. RVC and Thumb, but you cannot make full use of the architectural registers without incurring significant instruction size bloat.
To make the comparison fair, it should be noted that register renaming cannot resolve all dependency hazards that would be possible to resolve with explicit registers. You can still only have as many live values as there are architectural registers. (That's a partial truth because of memory.)
There are of course alternatives to register renaming that can address some of these issues (but as you say register renaming isn't just about this). Register windows (which come in many flavors), valid/dirty bit tracking per register, segregated register types (like data vs address registers in MC68000), swappable register banks, etc.
I think a major reason register renaming is usually married to superscalar and/or deeply pipelined execution is that when you have a lot of physical registers you run into a von Neumann bottleneck unless you have a commensurate amount of execution parallellism. As an extreme case, imagine a 3-stage in-order RISC pipeline with 256 registers. All of the data except for at most 2 registers is sitting at rest at any given time. You'd be better served with a smaller register file and a fast local memory (1-cycle latency, pipelined loads/stores) that can exploit more powerful addressing modes.
Because I'm an assembler coder, and when one codes assembler by hand, one almost never uses the stack: it's easy for a human to write subroutines in such a way that only the processor registers are used, especially on elegant processor designs which have 16 or 32 registers.
You almost had to, because both Z80 and x86 processors have a laughably small number of general purpose registers. To write code which works along that limitation would have required lots of care and cleverness, far more than on UltraSPARC and MC68000.
On MOS 6502 we used self-modifying code rather than the stack because it was more efficient and that CPU has no instruction and data caches, so they couldn't be corrupted or invalidated.
C doesnt "have", or require, a stack, either. It has automatic variables, and I think I looked once and it doesn't even explitly require support for recursive functions.
You're right. I searched the C99 for "recurs" and found the relevant section that briefly mentions recursive function calls.
That means static allocation is insufficient for an implementation of automatic variables in a conformant C compiler. Nevertheless I still like to think of it as a valid implementation sometimes. In contemporary practice many stack variables are basically global variables, in the sense that they are valid during most of the program. And they are degraded to stack variables only as a by-product of a (technically, unnessary) splitting of the program into very fine-grained function calls.
But that's fighting against a straw man. When people advice others to "learn C," they don't mean the C99 specification they mean C as it is used in the real world. That includes pthreads, simd intrinsics, POSIX and a whole host of other features that aren't really C but what every decent C programmer uses daily.
As you point out, modern architectures are actually designed to run C efficiently, so I'd say that's a good argument in favor of learning C to learn how (modern) computers work. Pascal is at the same level as C, but no one says "learn Pascal to learn how computers work" because architectures weren't adapted according to that language.
> . Pascal is at the same level as C, but no one says "learn Pascal to learn how computers work" because architectures weren't adapted according to that language.
They used to say it though, before UNIX derived OSes took over the computing world.
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 malloc/free, so it's not like that's an underlying building block. It's simply a different building block.
So what are you trying to teach people, and is C really the way to get that concept across? Is the concept even _useful_ to know?
If you want to write fast code, which is what you'll commonly drop to C/C++ to do, then just learning C won't get you any closer to doing that. It won't teach you branch predictors, cache locality, cache lines, prefetching, etc... that are all super critical to going fast. It won't teach you data-oriented design, which is a hugely major thing for things like game engines. It won't teach you anything that matters about modern CPUs. You can _learn_ all that stuff in C, but simply learning C won't get you that knowledge at all. It'll just teach you about pointers and about malloc & free. And about heap corruption. And stack corruption.
Would it be fair to say that it will teach you how to dictate the memory layout of your program, which is key to taking proper advantage of "cache locality, cache lines, prefetching, etc..."?
> 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.
Separate stack and data memory adress spaces will make the machine incompatible with ISO C due to impossibility to convert between "pointer to void" and "pointer to object". Code address space is allowed to be separate.
> 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 malloc/free, so it's not like that's an underlying building block. It's simply a different building block.
The realization that malloc is really just kind of a crappier heavy-manual-hinting-mandatory garbage collector was a real eye-opener in my college's "implement malloc" project unit.
(To clarify: the malloc lib is doing a ton of housekeeping behind the scenes to act as a glue layer between the paging architecture the OS provides and high-resolution, fine-grained byte-range alloction within a program. There's a lot of meat on the bones of questions like sorting memory allocations to make free block reunification possible, when to try reunification vs. keeping a lot of small blocks handy for fast handout on tight loops that have a malloc() call inside of them, how much of the OS-requested memory you reserve for the library itself as memory-bookkeeping overhead [the pointer you get back is probably to the middle of a data structure malloc itself maintains!], minimization of cache misses, etc. That can all be thought of as "garbage collection," in the sense that it prepares used memory for repurposing; Java et. al. just add an additional feature that they keep track of used memory for you without heavy hinting via explicit calls to malloc() and free() about when you're done with a given region and it can be garbage-collected).
Stack accesses _are_ different in hardware these days, which is why AArch64 brings the stack pointer into the ISA level vs AArch32, and why on modern x86 using RSP like a normal register devolves into slow microcoded instructions. There's a huge complex stack engine backing them that does in fact give you better access times averaged vs regular fetches to cache as long as you use it like a stack, with stack-like data access patterns. The current stack frame can almost be thought of as L½.
The stack pointer is just that, a pointer. It points to a region of the heap. It can point anywhere. It's a data structure the assembly knows how to navigate, but it's not some special thing. You can point it anywhere, and change that whenever you want. Just like you can with any other heap-allocated data structure.
It occupies the same L1/L2 cache as any other memory. There's no decreased access times or fetches other than the fact that it just happens to be more consistently in L1 due to access patterns. And this is a very critical aspect of the system, as it also means it page faults like regular memory, allowing the OS to do all sorts of things (grow on demand, various stack protections, etc...)
Google "stack engine". Huge portions of the chip are dedicated to this; if it makes you feel better you can think of it as fully associative store buffers optimized for stack like access. And all of this is completely separate from regular LSUs.
There's a reason why SP was promoted to a first class citizen in AArch64 when they were otherwise removing features like conditional execution.
That's also the reason why using RSP as a GPR on x86 gives you terrible perf compared to the other registers, it flips back and forth between the stack engine and the rest of the core and has to manually synchronize in ucode.
EDIT: Also, the stack is different to the OS generally too. On Linux you throw in the flags MAP_GROWSDOWN | MAP_STACK when building a new stack.
> I find this article to be disingenuous. Yes, C isnt "how a computer really works". Neither is assembly. [...]
He addresses all of that in the subsequent bullet points of his summary, and elaborates on it in the body of the article (your criticism stops at his first sentence of the summary). It goes into a nuanced discussion; it doesn't just make a blanket statement. I don't find it disingenuous at all.
"How a computer works" is both a moving target, and largely irrelevant, as shown by the number of ignorant (not stupid) replies in this very topic. RISC and ARM changed the game in the 90s, just as GP-GPUs did in the 00s and neural and quantum hardware will do in the future.
What's really needed are languages that make it easier to express what you want to accomplish - this is still a huge problem, as evidenced by the fact that even a simple data munging task can be easily explained to people in a few dozen words, but may require hundreds of LOC to convey to the machine...
(BTW, it's time for us to be able to assume that the computer and/or language can do base-10 arithmetic either directly or via emulation. The reasons for exposing binary in our programming languages became irrelevant decades ago - ordinary programmers should never have to care about how FP operations screw up their math, it should just work.)
If you want to learn how it works, it's a lot better to start at the lower level in my opinion. Reverse engineer something you use every day, get an achievable goal, maybe fire up x64dbg, go out and find some malware, make an advanced cheat for your favorite game or crack something.
You'll learn what code looks like to the CPU, you'll get a feeling for how OOP works inside that box (things like the "this" pointer, vtables), what structures look like in memory, how dynamic linking works vs static linking by actually looking at what that code looks like in an executable. And you'll have something to show for it - something to prove you've acquired enough knowledge to achieve goals.
Discussing this with other tech folk in my circle of a certain age, I'm actually in favor of learning BASIC (old-school line-number basic) to learn how a computer works, because the conceptual model is not dissimilar to assembly language.
Concepts of structured programming arise from noting patterns commonly used -- you start using GOSUB instead of GOTO; you tend to make your loops very strictly nested because otherwise the code becomes unmaintainable, you find yourself writing data structures to manage related records, etc. From there, the transition to structured programming becomes very natural -- just formalizing some concepts that you've already internalized.
Is this not a strawman? I've never seen anyone, ever, say that C is "how the computer works". Searching for references (since the author provides pseudo-quotes to refute that they seem to have invented) finds shockingly few making such a claim.
I know its anecdotal, but I hear the phrase all of the time. People who have only ever used higher-level languages, and want to learn more about computers. The say that they would rather learn C over C++, Rust, etc. because C is 'how computers work'.
I stopped reading when I got to "C also operates inside of a virtual machine."
Is the author confusing virtual memory with virtual machine? Perhaps they're referring to the way a high level language abstracts away the details of the H/W. I didn't care enough to read on.
That said, I learned the most about "how a computer works" in a class that taught Intel 8080 assembler on a system running CP/M. (Technically it was MP/M but there was only a single console.) The instructor spent a lot of time explaining what registers were, accumulators, stack pointer, addressing RAM and so on. That's why I learned about H/W details, not because I focused on a particular language.
I thought the entire reason for C was to avoid having to deal directly with the H/W (though it can be done.)
I am, but I also have work to do, and this has blown up a little. I’ll be replying but contrary to popular belief my job is not responding to hacker news comments. (I've now replied to your parent, let's keep it in one thread instead of two :) )
I suspect that by "virtual machine" he means "the C abstract machine". There's arguably little relevant difference between an abstract machine and a virtual machine—for example, Android has an AOT compiler for the Java "virtual machine".
So, this post isn't attempting to address the usefulness angle; that's going to be in the two follow-ups. But I'll give you a summary of where I'm going with this, because you were actually in the back of my mind when I was writing this, and I'm interested in your thoughts. First though, this post.
The first reason that this is useful is that there are a lot of people out there who believe that C is somehow fundamental to computing. You and I both know that this is false, but I run into a ton of people who don't understand this. So, this first post is setting that stage: everything is always an abstraction, in the big picture sense. That's bullet point one.
That said, interpreting people literally isn't a good way to have a conversation, you need to know what they are saying, which may or may not connect to the exact words they used. I think when people are saying this phrase, they don't mean it in a literal sense. Part of the reason why is that there are some differences that matter when you zoom in from the big picture. I speculate a bit as to why, but regardless, knowing that it may not be literal is point two.
I've heard "all models are wrong; some models are useful" attributed to several people, but it's sort of the counter argument to bullet point one, and so makes up bullet point three. Drawing a distinction between the C abstract machine and the JVM can be a useful mental model, even if it's incorrect in some sense. The C abstract machine is closer to hardware than the JVM is, and even if it's not a perfect mapping, you'll be exposed to stuff that's closer than your high level language. As long as you know you're still working with an abstraction, learning C can be a great way to be exposed to this stuff. Just keep in mind that it's not magic, or particularly inherently special.
I do think that this is useful on its own. If you reduce it down to a soundbyte, sure, that's not interesting, but the interesting thing is in the details. In some sense, this is kind of the fundamental point of the article. You may find that boring, but that's okay; this stuff isn't really for you, both in a literal and figurative (experienced C developers generally) sense.
------------------------------------
Part two is going to discuss what happens if you take this to an extreme. I have two small bits of sample code that fundamentally do the same number of operations, and have the same computational complexity, but one runs much, much faster. This is due to how it interacts with caching, which is not part of the C spec, but is the reality of x86 (at least) hardware. This exposes a sort of fundamental tension when thinking about how the abstract machine relates to the physical machine. This is where C is really interesting, because it's low level enough to allow you to control memory allocation and access, which higher-level language users aren't really exposed to. This is the "why is this useful," really. The task is to know what behaviors you can rely on and which ones you can't, and how it relates to the hardware you actually want to support.
------------------------------------
Part three is going to show what happens if you make a mistake with the ideas from part two. If you incorrectly assume that C's abstract model maps directly to hardware, you can make mistakes. This is where UB gets dangerous. While you can take advantages of some properties of the machine you're relying on, you have to know which ones fit within C's model and which ones don't.
------------------------------------
I split this into three parts because it's an MVP, in a sense. Ship the first part so that I don't continue to revise the beginning over and over and over again. They're all related to each other, and could be one whole work, but it's true that this one is less directly useful than the others, as it's really setting the stage.
I think if you'd led with the UB thing, the notion of C targeting an abstraction rather than being an abstraction would have been more compelling to me (the perf argument gets back to a place where basically everything in every language is artifacts and leaky abstractions; it's worth visiting but doesn't persuade me in either direction).
I guess my issue, even with the whole outline laid out (thanks!), is that while C "isn't how the computer works" in sort of the same sense as a SPICE model isn't really how a circuit design works and ns isn't really how a network works, it's close enough to be illuminating in ways most other languages aren't (and has the virtue of most mainstream hardware being explicitly designed to make it, and particularly it, faster).
I think more developers should know C (though I think almost nobody should write in it anymore).
The C abstract machine isn't implemented in hardware. It needs a compiler to translate from the C abstract machine semantics to hardware ISA semantics. Those compilers have grown to exploit the peculiarities of the C abstract machine in ways that no hardware implementation would do.
It's clear this was the author's intention here. He is using the term "virtual machine" broadly. Whether this makes for as effective or interesting a "twist" as he hopes it does is another matter.
> I stopped reading when I got to "C also operates inside of a virtual machine."
Then you missed my actual explanation and description, which is described in the rest of the post. Since others are also apparently confused, I'll re-state it here.
The C language is not defined in terms of hardware. The C language is defined in terms of an "abstract machine." This machine, being abstract, does not exist. "Virtual" and "abstract" are terms that are broadly speaking synonyms in general usage.
The spec even defines this in terms of an "execution environment" which can be "freestanding" or "hosted", and most C programs are, in the spec's language, running in the execution environment of C's hosted, abstract machine.
The rest of the post is exploring how this is conceptually the same, but different in details, than something like the JVM, which is what many people think of when they hear "virtual machine." As mentioned elsewhere in the thread, the sense of "virtual machine" that C uses is where LLVM gets its name from, yet people found that confusing enough that they changed the name.
You may also argue that the abstract machine is practically insignificant. I disagree, but that's what my follow-up posts are about, so this post doesn't address this question directly at all.
> Then you missed my actual explanation and description, which is described in the rest of the post. Since others are also apparently confused, I'll re-state it here.
I think the confusion stems from using the word "operates", which suggests a VM that exists at runtime:
> There’s just one problem with this: C also operates inside of a virtual machine.
I agree with the sibling comment that in this context the term abstract machine would be better. Also, saying "C is defined in terms of an abstract machine" instead of "operates" might be better.
In the language of the spec, it does “operate” inside the machine. Well, the spec says “execute” but that’s even more likely to be confused with a runtime thing.
Additionally, and this is something I really didn’t get into, languages aren’t inherently compiled or interpreted. You could have a C interpreter.
> Additionally, and this is something I really didn’t get into, languages aren’t inherently compiled or interpreted. You could have a C interpreter.
Of course; I was only addressing the confusion that other posters mentioned. While one could have a C interpreter (or any interpreter), for the purposes of the article this seems to be only a marginal point. In practice, C is (almost) never run that way, but your choice of words could suggest a parallel between the C abstract machine and the Ruby or Java VMs, and I think the way usual C implementations differ from those is more informative than how they are alike.
You do explain later that the C abstract machine is a compile-time construct, but many people read selectively and react immediately, as evidenced by several posts on this page.
No, you should learn one or more assembly languages and read some arch reference manuals and their supporting glue chip reference manuals if you want to learn "how the computer works" from the perspective of programming after reading an academic book or two on the subject of computer architecture.
C is useful for participating in commercial application of these things, but it is possible to be a very accomplished C developer and have no idea how hardware interfacing works and I'd wager this category vastly outnumbers those that understand hardware interfacing.
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.
I don't think he is correct. The underlying representation of a pointer is not defined by the C standard. You could have a C implementation that works on segmented, non-flat architectures. Look at the C compilers from the DOS days, for example...
I think we're talking past each other, and in some ways, this is what the post is about.
The C abstract machine presents a flat, uniform, byte-addressed address space.[1] The reason that it does not define what a pointer's representation is is because it needs to map that to what the hardware actually does, which is your point.
1: Actually, my impression is that it does, but this is actually an area of the spec in which I'm less sure. I'm going to do some digging. Regardless, the point is that the memory model != the machine model, which is your point.
Yep, these common assumptions are not always true if you read deep enough into the spec. Even though they may be true in practice, only as a side effect in most implementations...
I taught myself C when I was a teenager (on an Amiga, back in the 80's.) It is amazing that almost 30 years later, I'm still learning new things about it.
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.
The memory model you describe is overly simplistic, and is not actually mandated by the C standard. Too many assumptions in that area will lead to undefined behavior.
>B is typeless, or more precisely has one data type: the computer word.
I had read the Martin Richards (inventor of the language) book about BCPL (predecessor of B) early in my career, although I could not work on it, since there was no machine available to me that could run it. (It was already outdated then.) Interesting language though, and even the systems software examples shown in the book (written using BCPL) were cool.
You're right about why C was created, byte addressability.
>The original PDP-11 version of Unix was developed in assembly language. The developers were considering rewriting the system using the B language, Thompson's simplified version of BCPL.[11] However B's inability to take advantage of some of the PDP-11's features, notably byte addressability, led to C.
The part that's closer to how the computer works is the part that lets you write an allocator.
Witness any discussion of a pointer bug at any level of the stack. No matter what the piece, someone will jump in and say, "that should have been bounds checked!" A lot of times it's true. But what they miss is that the bounds check needs to come from somewhere, which means there is a layer of the system where it doesn't apply. Somewhere you have a larger piece of memory, and it gets divided into smaller chunks, and the boundaries are fiction, meaningful only to a higher level abstraction. This is the way it needs to work.
Reducing the code in which that's a concern is likely legitimate. But then you enter into "that's not really how it works".
You should learn C to learn what every language is loosely based on and what unrestricted memory access looks like. It's the programming equivalent of learning Latin. It isn't required, but you will be better at pretty much everything you do involving modern English, Spanish, French, etc., as you will understand where things came from. It's even more useful though, as in the programming language world pretty much everything evolved out of C, whereas in linguistics you also have the Asian languages, Greek, etc.,
This is a genuine question -- are there non-C-family systems languages from that period (as in languages that allow low level memory manipulation and assembly embedding)? I have never heard of or seen any.
Burroughs designed ESPOL in 1961, improved into NEWP, still being sold by Unisys as ClearPath MCP.
IBM did all their RISC research with PL/8, before creating Aix for their RISC systems thus adopting C instead.
IBM i and z mainframes made use of PL/S, C and C++ only came later into the picture as the languages got industry adoption.
Xerox PARC initially used BCPL, but quickly followed up with Mesa, then Mesa/Cedar.
Wirth was inspired by Mesa to create Modula-2 and then by Mesa/Cedar to create Oberon.
Mesa/Cedar designers went to Olivetti and created Modula-2+ and Modula-3.
Apple wrote Lisa and initial versions of MacOS in a mix of Pascal and Assembly.
VAX used BLISS to develop VMS.
PL/I was used by multiple companies, not only by MIT to write Multics.
This is just a very brief overview.
As for Assembly embedding, it is a language extension not part of ISO C, and was quite common in many languages during the 70 and 80's even some BASIC interpreters had it, like on Acorn computers.
When you ask what portable assembler is, there's actually three different things you could mean:
1. C is portable assembler because every statement maps pretty directly to assembly. Obviously, compiler optimizations tend to make this completely not true (and most of the rants directed towards compiler developers are precisely because they're eschewing naive mappings).
2. You can represent every (reasonable) assembly listing using C code. Well, except that C has no notion of SIMD value (yes, there's extensions to add vector support). Until C11, it couldn't describe memory ordering. Even with compiler extensions, C still doesn't describe traps very well--any trap, in fact, is undefined behavior.
3. Every assembly instruction can have its semantics described using C code more or less natively. Again, here C has an abstract machine that doesn't correspond very well to hardware. There's no notion of things such as flag registers, and control registers are minimal (largely limited to floating-point control state). Vectors and traps are completely ignored in the model. Even more noticeably, C assigns types to values, whereas processor definitions assigns types to operations instead of values.
Note here that I didn't need to invoke undefined behavior to show how C fares poorly as portable assembler. The problem isn't that C has undefined behavior; it's that a lot of machine semantics just don't correspond well to the abstract semantics of C (or indeed most languages).
I definitely would not consider a CS education complete without C. If you don't know C, that means you don't know how how parts of operating systems work. It definitely makes you a less useful engineer.
I don't think people need to be able to code in C at the drop of a hat. But it should not be a scary thing for good engineers.
When I started my CS degree most home OS were still mostly written in Assembly, and on my geography Turbo Pascal was the language to go when Assembly wasn't required.
My university introductory classes were Pascal and C++.
Related article by Joel Spolsky. "The Perils of Javaschool" [1]
C really will test you and make you a better programmer than any high level language ever could.
Someone who is a good C programmer will right better code in any language than someone who is just focused on high level languages.
The same could not be said for python, java, or js.
380 comments
[ 3.4 ms ] story [ 397 ms ] threadBut, pointers yes definitely. Even some assembly. You really should understand how things like .size or lengh() aren’t “free” and how they work.
That said, I 10000% agree that pointers are a thing that is great to learn.
> You really should understand how things like .size or lengh() aren’t “free” and how they work.
You're talking about strings here, right? This is not true in all languages, but certainly is true that these are not free in C :)
It costs O(1) in memory to delimit strings with a null terminator and O(n) in time to execute strnlen(), right? It's not free. Though, if you're lucky your string is in rodata and the compiler can calculate the sizeof() in advance, this is very-nearly-free.
EDIT: misunderstanding, disregard
> You're talking about strings here, right? This is not true in all languages, but certainly is for C :)
I realize now that I misread this. It sounded as if you were saying '...but it is [free] for C', and on re-read I now understand that's not what you said at all.
At some point, some O(n) work was done somewhere to construct the n-element structure we're getting size on, but I don't think I've ever encountered a core library that implements .size as anything other than "Look up the cached length value that I computed the last time my length changed."
This is one of their largest weaknesses, which is why many other languages do not use C strings.
I think I just gave away the game on how long it's been since I programmed in C itself. Even C++ has "free" length() in std::string (in the sense that it's specified that it must be a constant-time operation).
... that's actually a good example of the trap of thinking of C as "what's really going on." If you assume C's treatment of char* is how strings have to be done, you're out of alignment with basically all other programming languages and you might be writing unnecessarily slow code (or forcing developers using your code to juggle a homegrown "length" abstraction that the underlying language should be juggling for them).
Another revelation much later on, was, as discussed here, the realisation that C is indeed defined over an abstract machine. I think much of those realisations were because of reading about how crazy compiler optimizations can be and how UB can _actually_ do anything.
>When GCC identified “bad” C++ code, it tried to start NetHack, Rogue, or Towers of Hanoi. Failing all three, it would just print out a nice, cryptic error message.
https://feross.org/gcc-ownage/
[1] https://savannah.nongnu.org/projects/pgubook/
[1] http://www.wrox.com/WileyCDA/WroxTitle/Professional-Assembly...
I will say, waiting until he was capable and willing to read the subbed version was probably the right choice. Dubbed shows of any genre drive me nuts, and I'm not sure he would have the patience for the series if he was younger (the Alabasta arc was still taxing...). I do take a perverse pleasure in hinting about how crazy stuff becomes later, while also convincing him to not ruin it for himself by looking it up. ;)
Do you need to bake bread to eat it? No. Should you learn to bake it? Yes.
There are lots of things you should learn to do because they're useful and teach you about how the world works. The miracle of society is that you don't have to learn most of them to enjoy using them.
>A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyse a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -- Robert Heinlein
For one, it misses the fact that learning how to bake it doesn't benefit the eating process. Whereas, learning how to code in C benefits (but is not required) in general programming.
I understand that analogies are always compromises because there is always going to be something that differs from the original motif. Also, analogies should be used when the motif is complicated with many layers of abstraction and using one adds something - whether it is clarity, succicicty or reduction of abstraction. In the case of parent comment, it is not too difficult to understand the original motif. So, the bread analogy adds virtually nothing to it.
Maybe it works differently for bread, but with whisky, learning how it has made has certainly enhanced my consumption, if only to give me the language needed to describe flavors and compare and contrast.
Also, Stevens Advanced Programming in the Unix Environment is a great book to work through.
I think that these terms are some of the most confusing our discipline has.
In typical use of a C compiler, you get code for the target processor, i.e. x86. In theory, you don't have to worry about the underlying hardware, so you could say you are programming for some abstract machine that runs C code, but it is much less meaningful than saying java has a virtual machine.
Learning an assembler would be more helpful in this regard, but in my opinion one might want to start with a very well-written article by Mark Smotherman: https://people.cs.clemson.edu/~mark/uprog.html
If you want to see how a CPU works, I highly recommend visiting http://www.visual6502.org/
Novice unity programmers struggle to understand why using classes (reference type in c#) in a game loop causes performance issues, but structs (value type in c#) are not as costly. For someone who has called malloc before, this isn't too hard to grasp, but before someone who sticks to garbage collected languages, it seems bizarre and arbitrary.
Of course memory allocation is an OS function, so this isn't "understanding the hardware," but it is a much deeper understanding of computers than not knowing what happens when you create an object.
It is a great example of how to use the C language as a teaching tool.
Learning assembly and/or microarchitecture is another great way to get "knowing how the computer works," and is part of what I was hinting at at the end of the post when I said that C isn't fundamental here.
It was probably the hardest course of my entire degree, and I ended up taking it twice, but at the end of the second go-round, computers were no longer a magic black box.
Interesting. Did you study at a US univ.? I have not heard of being able to take the same course twice (except via, say, failing a year of the degree and having to repeat the whole year). I did hear that US universities are more flexible in some ways than, say, Indian ones, whose rules are probably based on British ones (maybe ones from much before); e.g. being able to mix and match courses, take longer than the standard 4 years for a degree, etc. I have American friends and relatives who told me that. But didn't know one could repeat a course. Seems like a useful feature.
US colleges are all over the map with regards to how flexible they are about course order, and even between different degree programs at the same school. My alma mater had a somewhat weird trimester schedule and was relatively flexible about offering sections of courses year round - they had a bit of a housing shortage that made it impossible to house all the undergrads on campus at the same time.
>You may have heard another slogan when talking about C: “C is portable assembler.” If you think about this slogan for a minute, you’ll also find that if it’s true, C cannot be how the computer works: there are many kinds of different computers, with different architectures
As with many things, this phrase is an approximation. C is a portable implementation of many useful behaviors which map reasonably closely to tasks commonly done on most instruction sets. C programmers rarely write assembly to optimize (usually to capture those arch-specific features which are unrepresentable in C), but programmers in other languages often reach for C to write the high-performance parts of their code. The same reason C programmers in the early days would reach for assembly is now the reason higher-level programmers reach for C.
Modern languages solve problems created developing in legacy languages (primarily C). The issue is that knowing a solution without knowing the prior problem which the solution addresses, doesn't really lend itself to clarity.
Point is that out of context, a lot of the things modern languages provide seem superfluous. Why have objects? Why have templates, closures, or lambdas? For a novice programmer, these are many answers for questions yet to be asked.
When you come from a heavy C background and you encounter something like templates, you know EXACTLY what this is for and wish you had it years ago.
I'm as hardcore as they get C programmer and I'm having a ball with C# for this very reason.
Yet we often see passionate arguments in its favor, as for instance from Sústrik (http://250bpm.com/blog:56) and Tatham (https://www.chiark.greenend.org.uk/~sgtatham/mp/) and a person on the internet who recommends replacing LAPACK with preprocessor macros (http://wordsandbuttons.online/outperforming_lapack_with_c_me...). Would you care to comment on its enduring popularity?
C does have a lot of it, and it can be anywhere. In many languages, you can cause undefined behavior through its FFI. Some languages, like Rust, have UB, but only in well-defined places (a module containing unsafe code, in its case).
I do take your point about Rust, but I'd see that as deriving from LLVM's undefined behaviour which in turn descends from C; I'm not aware of any pre-C languages having C-style exploding undefined behaviour or of any subsequent languages inventing it independently.
That is fair, however, I don't think it's inherently due to C. Yes, most languages use the C ABI for FFI, but that doesn't mean they have to; it's a more general problem when combining two systems, they cannot track statically the guarantees of the other system.
With Rust, it has nothing to do with LLVM; it has to do with the fact that we cannot track things, that's why it's unsafe! Even if an implementation of the language does not use LLVM, we will still have UB.
I can see that any implementation of unsafe Rust would always have assembly-like unsafeness (e.g. reading an arbitrary memory address might result in an arbitrary value, or segfault). But I don't see why you would need C-style "arbitrary lines before and after the line that will not execute, reads from unrelated memory addresses will return arbitrary values" UB?
The reason to have it is the exact same reason that the distinction between "implementation defined" and "undefined" exists in the first place: UB allows compilers to assume that it will never happen, and optimized based on it. That is a useful property, but it's a tradeoff, of course.
> I don't see why you would need C-style "arbitrary lines before and after the line that will not execute, reads from unrelated memory addresses will return arbitrary values" UB
This reason this happens is because we don't compile things down to obvious assembly, they get optimized. Each of those optimizations requires assumptions to be made about the the code. If you break those assumptions, then the optimizations can result in arbitrary results happening. Those assumptions determine what is and isn't UB.
Most languages just don't give the programmer any way to break those assumptions, but languages like C and Rust do. Thus, Rust will always have this 'problem' because it can/will make even more aggressive optimizations then C will, meaning badly written `unsafe` code will have arbitrary behavior and results from the optimizer if the compiler doesn't understand what you're doing.
FFI isn't into "C", it's into your operating system's binary format. And since no two systems behave the same, it's UB however you look at it.
Most people call that format "the C ABI," and "FFI into C" is short for "FFI via the C ABI."
> And since no two systems behave the same, it's UB however you look at it.
That's not what UB means. It would be implementation defined, not undefined.
The reason that a spec is taking so long is that we're interested in making an ironclad, really good spec. Formal methods take time. C and C++ did not have specs for much, much longer than the three years that Rust has existed. We'll get there.
You are right that we are far, but that’s because it’s a monumental task, and it’s fundamentally unfair to expect equivalence from a young language. It is fair to say that it is a drawback.
It doesn't have to be a monumental task. Rust is simply too big, and getting bigger.
Specs are always a monumental task. The first C spec took six years to make in the first place!
And C pretends there's a distinction between the stack & heap that doesn't actually exist. There is no significant difference there.
In fact C teaches a model of a semi-standard virtual architecture - loosely based on the DEC PDP7 and/or PDP11 - which is long gone from real hardware.
Real hardware today has multiple abstraction layers under the assembly code, and all but the top layer is inaccessible.
So there's no single definitive model of "How computers work."
They work at whatever level of abstraction you need them to work. You should definitely be familiar with a good selection of levels - and unless you're doing chip design, they're all equally real.
There are significant performance and strategy differences between the stack and the heap. On the stack, allocation is cheap, deallocation is free and automatic, fragmentation is impossible, the resource is limited, and the lifetime is lexically scoped.
On the heap, allocation might be cheap or it might be expensive, deallocation might be cheap or it might be expensive, fragmentation is a risk, the resource is 'unlimited', and the lifetime is unscoped.
Your statement is equivalent to saying "there's no difference between pointers and integers" - technically, they are both just numbers that live in registers or somewhere in memory. In reality, that approach will not get you far in computer science.
By all means it's certainly a valuable abstraction, one that most high-level languages support. But that's like how functions are a valuable abstraction, or objects, or key-value stores, or Berkeley sockets. Learning those abstractions is absolutely important and also completely irrelevant to understanding "the computer".
(As Dijkstra once said, computer science is no more about computers than astronomy is about telescopes. Learning C is valuable for computer science, but that doesn't mean it gives you a deep understanding of the computer itself.)
In other words it might behave just like "the stack"; the differences between different kinds of "heaps" are as large or larger than the difference between "the stack" and "the heap".
> fragmentation is a risk, the resource is 'unlimited', and the lifetime is unscoped.
None of these is true in all implementations and circumstances.
Understanding the details of memory management performance is important for particular kinds of programming. But learning C's version of "the stack" and "the heap" will not help you with that.
True enough; however sometimes access to "the heap" (in C terms) will use those instructions, and sometimes access to "the stack" will not. Learning one or two assembly languages is well worth doing, since they offer a coherent abstraction that is genuinely relevant to the implementation of higher-level languages. Not so C.
No, because in reality those are handled by different computational units. Integers are handled by the ALU, and pointers are handled by the loader. They are distinct things to the CPU.
Stack & heap have no such distinction. There isn't even a heap in the first place. There's as many heaps of as many sizes as you want, as the "heap" concept is an abstraction over memory (strictly speaking over virtual address space - another concept C won't teach you, yet is very important for things like mmap). It's not a tangible thing to the computer.
Same with the stack. It's why green-threads work, because the stack is simply an abstraction over memory.
I strongly disagree. Yes some execution units are more let's say "dedicated" to pointers than other, and obviously ultimately you will dereference your pointers, so you will load/store, but compilers happily emit lea to do e.g. Ax9+B and in the other direction, add or sub on pointers. Some ISA even have almost no pointer "oriented" register (and even x64 has very few)
Although, it sounds like you're agreeing with me that there is in fact a difference between the stack and the heap because to your point one exists supported at the hardware level with instructions and registers, and one doesn't exist or can exist many times over. Hence, different.
[1] https://c9x.me/articles/gthreads/code0.html
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?
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.
Without being able to refer to fundamental structures and concepts, I usually just exclusively teach students non-mutable patterns (e.g. list.sorted vs list.sort), while pushing them to become much proactive at inspecting and debugging.
(I kept this post vague but can offer concrete examples of you'd like)
Go does that too. C teaches manual memory allocation, de-allocation and pointer arithmetic as well.
For convenience, many architectures have a single assembly instruction for taking one register (called the "stack pointer"), adjusting it by a word, and moving a register to the address at that word, and a corresponding instruction to move data back to a register and adjust it in the other direction. That's the extent of the abstraction. You can implement it with two instructions instead of one, and then you get as many stack pointers as you want. Zero, if you want.
There is no "heap" on modern OSes. There used to be a thing called the program break, beyond which was the heap. It's almost meaningless now. You ask for an area of virtual memory via mmap or equivalent; it is now one of several heaps you have.
And you can pass around pointers from all your stacks and all your heaps in the same ways, as long as they remain valid.
You need to understand this in order to understand how thread stacks work (you typically allocate them via mmap or from "the heap"); how sigaltstack works and why you need it to catch SIGSEGV from stack oveflows; how segmented stacks (as previously used in Go and Rust) work; how Stackless Python works; how to share data structures between processes; etc.
Since this is a distinction that is very important both for performance in high-level languages and for correctness in C, and one C forces you to think about and makes plain without having to reason through escape analysis and closures, I think the previous comment's point is well taken.
Consider, say, shadow stacks- local variables might end up living on a totally separate "stack" from the one "call" pushes onto and "ret" pops from, and one which the ISA has no idea about.
PUSH/POP are more obviously "hey store your locals on the stack, kids", but on, say, x64, how often do you actually see a push instead of bp/sp-relative addressing? Most compilers seem to be much happier representing each stack frame as "a bunch of slots, some for things where the address is taken so it needs to be in memory, and others where I spill things into as needed".
On ARMv7 (i don't know enough about v8 / AARCH64), "push"/"pop" are just stores/loads with postdecrement / postincrement.
Is this lawyer-y? Sure. But I think it's still correct, and this being HN...
It's much more optimal to use a series of push/pops for smaller operations like saving registers before a call than to manually adjust and store onto the stack.
While technically this is still incrementing/decrementing a register and storing, the amount of isa/hardware support for such things clearly demonstrates that the x86 isa and modern x86 hardware gives special treatment to the stack.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
There are no occurrences of the words "stack" or "heap" in this document.
What the spec actually discusses is "storage durations". Now, in many cases you can say, well, "automatic storage duration" means it's on the stack, but that's not something C has any opinions about.
If you want to know about the stack and the heap, saying "learn C, and then learn how these abstract C concepts map onto the stack and the heap" might not actually be the best way to figure this stuff out.
What actually ends up happening, in my experience, is that to figure C out you have to get a decent mental model of how the stack and heap work, and then, from that, say "automatic storage duration and malloc/free are basically just the stack and the heap".
I learned calculus as a kid because I needed it for an online electronics class I was taking. But I'm not going to recommend that folks take electronics classes so they learn calculus! (that said- having a motivation to learn something, having an application in mind, a problem you want to solve... certainly seems to make learning easier.)
[1] https://arcanesentiment.blogspot.com/2014/12/customary-seman...
Oddly you seem to recognize this, so I’m not sure what your point is.
's funny, I am certainly aware of having, at some point, at least skimmed over the C99 standard encountered the concept of a storage duration. But, aside from that brief few hours, virtually the entirety of my C-knowing career has been spent thinking and talking in terms of stacks and heaps.
Meanwhile, in my .NET career, I really did (and, I guess, still do) feel like it was important to keep track of how .NET's distinction is between reference types and value types, and whether or not they were stack or heap allocated was an implementation detail.
The semantics of automatic storage necessarily imply #1, but they do not require #2. Indeed, there are widely used implementations which implement #1 using linked lists (e.g. IBM mainframes, and GCC's split stacks or clang's segmented stacks).
Similarly, function recursion semantics necessarily imply #1 for restoring execution flow, but not #2. In addition to the examples above, so-called shadow stacks are on the horizon which maintain two separate stacks, one for function return addresses and another for data.[1] In the near future a single contiguous stack may be atypical.
[1] Some variations might mix data and return addresses if the compiler can prove safe object access. Or the shadow stack may simply contain checksums or other auxiliary information that can be optionally used, preserving ABI compatibility.
I'm not even sure the C memory model depends on the code/stack/heap separation.
are there ? how many laptops, desktops, smartphones, tablets, use anything else than the von neumann architecture ?
In my domain, we reach for the CUDA libraries to write the high-performance parts of our code. ;)
(and worth noting: if I pull out the special hardware you're thinking of from that box, my particular thousand-dollar-box is no longer able to run software I need because the GUI requires a graphics accelerator card. The OS authors have already reached for a subset of CUDA to optimize the parts of the GUI that needed optimization).
C is fundamentally a scalar language. In 2018, the only code for which "classic" C is the fastest is code that exhibits a low level of data parallelism and depends on dynamic superscalar scheduling. Fundamentally sequential algorithms like LZ data compression, or very branchy code like HTTP servers, are examples. This kind of code is becoming increasingly less prevalent as hardware fills in the gaps. Whereas we used to have C matrix multiplies, now we have TPUs and Neural Engines. We used to have H.264 video codecs, but now we have huge video decoding blocks on every x86 CPU Intel ships. Software implementations of AES used to be the go-to solution, but now we have AES-NI. Etc.
As an example, I'm playing around with high-performance fluid dynamics simulations in my spare time. Twenty years ago, C++ would have been the only game in town. But I went with TypeScript. Why? Because the performance-sensitive parts are GLSL anyway--if you're writing scalar code in any language, you've lost--and the edit/run/debug cycle of the browser is hard to beat.
I'd argue that GPUs and SIMD instructions have so many restrictions that they're useless for general purpose computing. Yeah, they have niche spaces, but in terms of all the different kinds of programs we write, I think those spaces are going to remain niche.
GPUs and other specialized hardware aren't good at everything, and I acknowledged as much upthread, but the set of problems they're good at is large and growing.
Doing fused SIMD-vectorised operations will likely bring the advantages of both, with relatively small downsides. This is a relatively common technique for libraries like Eigen (in C++), that batch a series of operations via "Expression Templates" and then execute them all in as a single sequence, using SIMD when appropriate. (Other examples are C++ ranges and Rust iterators, although these are focused on ensuring loop fusion and any vectorisation is compiler autovectorisation... but they are written with that in mind: effort is put into helping the building blocks vectorise.)
This I agree with and also I'd call the most important reason for Rust programmers to learn C. The C ABI is a lingua franca, not because it's good or pure but (as with spoken linguas franca) happened to be in the right place at the right time. It defines certain conventions and assumptions that didn't have to be assumed (implicit stack growth without declared bounds, single return value, NUL-terminated strings, etc.) and a lot of software is written to it, to the point that if you want your (e.g.) Python code and Rust code to interoperate, the easiest way is to get them to both speak C-compatible interfaces, even though you're not writing any actual C code.
ABI = Application Binary Interface
https://en.wikipedia.org/wiki/Application_binary_interface
https://upload.wikimedia.org/wikipedia/commons/b/bb/Linux_AP...
C and libc have been ABI-stable on most platforms for decades. C++ on some platforms (e.g., GNU) is stable with occasional ABI breakages in the standard library; on others (e.g., MS Visual C++) it breaks with new compiler versions. Rust isn't ABI-stable at all and has no clear plans for it, despite a strong commitment to API stability (i.e., old code will compile on new compiler versions). Swift 5 is targeting ABI stability.
this is the key. If you want a real-world view into how the kernel is written (i.e. more of the computer), then C is the only practical choice. Sure, you can write an OS in Java, Haskell, OCaml, etc. But it's roundabout. So, I think the statement, "learn how a computer works more by leveraging C" is valid.
Also, C is learn once, write anywhere. If there is some kind of computer, then there is probably a C compiler for it. That's not true of any other language to the same extent. Know C and you can program anything.
The C model is relatively close, I’ve heard, to the hardware of a PDP-11. But there have been tons of abstractions and adaptations on both sides of that coin ever since; not only can a C program provide a language runtime that behaves quite differently from a PDP-11, but the C program itself is compiled to machine code that is sometimes quite different than the code for a PDP-11, and even the low level behavior of the CPU often differs from what’s implied by the ISA. And while all of these models of computation are Turing equivalent, the transformations to and from C are very well known.
But I think it's a good suggestion; I certainly learned a bit from learning Apple's assembly on the ][c that I hadn't encountered elsewhere.
https://www.nand2tetris.org/
Is still one of the best resources if you want to go from the ground up.
I'd argue you should know how that works.
Cache-misses, pipelining and all these subtle performance intricacies that seem to have no rhyme or reason just fall out out understanding exactly how you get shorter clock cycles, different types of memory and the tradeoffs that they present.
One of the best things I ever did was go build a couple projects on an FPGA, when you get down to that level all of these leaky (performance) abstractions are clear as day.
The primary reason for dropping down to native is to get better performance. If you're going to do that you'll leave 10x-50x performance on the table if you don't understand cache misses, prefetching and the other things that manual memory placement open up.
I'm not saying that you can't do performance work without having done that. Just that you'll be at a disadvantage since you're at the mercy of whatever your HW vendor decides to disclose to you.
If you know this stuff you can work back from from first principals. With a high level memory architecture of a system(say tiled vs direct rendering GPU) you can reason about how certain operations will be fast and will be slow.
And your response was absurd. You don't rebuild a transmission in order to run a shop. You don't even rebuild a transmission as an engineer creating cars, you shop that out to an organization specializing in the extremely difficult task of designing and building transmissions. I wanted to avoid this waste of time, but here we are.
As for the rest of your comment about reasoning about performance, none of that requires the work you did. Again, neat project (for you), but completely unnecessary in general.
EDIT: I was going to update my comment a bit now that I thought more about it and that I'm on a computer rather than a mobile phone, but in the meantime jerf posted a very good reply to the parent comment so just read that ^^.
You can get to them from C, but via extensions. They're often very thin and will let you learn a lot about how the computer works, but it's reasonable to say that it's not really "C" at that point.
C also has more runtime that most people realize since it often functions as a de facto runtime for the whole system. It has particular concepts about how the stack works, how the heap works, how function calls work, and so on. It's thicker than you realize because you swim through it's abstractions like a fish through water, but, technically, they are not fundamental to how a computer works. A computer does not need to implement a stack and a heap and have copy-based functions and so on. There's a lot more accidental history in C than a casual programmer may realize. If nothing else compare CPU programming to GPU programming. Even when the latter uses "something rather C-ish", the resemblance to C only goes so deep.
There's also some self-fulfilling prophecy in the "C is how the computer works", too. Why do none of our languages have first-class understanding of the cache hierarchy? Well, we have a flat memory model in C, and that's how we all think about it. We spend a lot of silicon forcing our computers to "work like C does" (the specification for how registers work may as well read "we need to run C code very quickly no matter how much register renaming costs us in silicon"), and every year, that is becoming a slightly worse idea than last year as the divergence continues.
What general purpose computer exists that doesn't have a stack? Push/pop have been fundamental to all the architectures I've used.
ARM's pop is really a generic ldmia with update. You can use the same instruction in a memcpy.
MIPS, PowerPC, and Alpha don't have anything like push and pop, splitting load/stores and SP increment/decrement into separate instructions.
AArch64 has a dedicated stack pointer, but no explicit push pop.
In general the RISC style is to allocate a stack frame and use regular loads and stores off of SP rather than push and pop.
https://people.cs.clemson.edu/~mark/subroutines/s360.html
XPLINK, a different linkage convention, also for MVS, does have use a stack-based convention:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/...
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.
If a time traveler from a century in the future came back and told me that their programming languages aren't anywhere as fundamentally based on stacks as ours are, I wouldn't be that surprised. I'm not sure any current AI technology (deep learning, etc.) is stack-based.
From the perspective of "stack" as in "stack vs. heap", there's a lot of existing languages where at the language level, there is no such distinction. The dynamic scripting language interpreters put everything in the heap. The underlying C-based VM may be stack based, but the language itself is not. The specification of Go actually never mentions stack vs. heap; all the values just exist. There is a stack and a heap like C, but what goes where is an implementation detail handled by the compiler, not like in C where it is explicit.
To some extent, I think the replies to my post actually demonstrate my point to a great degree. People's conceptions of "how a computer works" are really bent around the C model... but that is not "how a computer works". Computers do not care if you allocate all variables globally and use "goto" to jump between various bits of code. Thousands if not millions of programs have been written that way, and continue to be written in the embedded arena. In fact, at the very bottom-most level (machines with single-digit kilobytes), this is not just an option, but best practice. Computers do not care if you hop around like crazy as you unwind a lazy evaluation. Computers do not care if all the CPU does is ship a program to the GPU and its radically different paradigm. Computers do not care if they are evaluating a neural net or some other AI paradigm that has no recognizable equivalent to any human programming language. If you put an opcode or specialized hardware into something that really does directly evaluate a neural net without any C code in sight, the electronics do not explode. FPGAs do not explode if you do not implement a stack.
C is not how computers work.
It is a particular useful local optimum, but nowadays a lot of that use isn't because "it's how everything works" but because it's a highly supported and polished paradigm used for decades that has a lot of tooling and utility behind it. But understanding C won't give you much insight into a modern processor, a GPU, modern AI, FPGAs, Haskell, Rust, and numerous other things. Because learning languages is generally good regardless, yes, learning C and then Rust will mean you learn Rust faster than just starting from Rust. Learn lots of languages. But there's a lot of ways in which you could equally start from Javascript and learn Rust; many of the concepts may shock the JS developer, but many of the concepts in Rust that the JS programmer just goes "Oh, good, that feature is different but still there" will shock the C developer.
Can you elaborate? I thought I knew what register renaming was supposed to do, but I don't see the tight connection between register renaming and C.
The UltraSPARC processor is a stereotypical example, a RISC processor designed to cater to a C compiler as much as possible: with register renaming, it has 256 virtual registers!
Another related issue is dealing with user/kernel mode transitions and context switches. User/kernel transitions can be made cheaper by compiling the kernel to target a small subset of the architectural registers, but a user mode to user mode context switch would generally require a full save and restore of the massive register file.
And there's also an issue with instruction encoding efficiency. For example, in a typical three-operand RISC instruction format with 32-bit instructions, with 8-bit register operand fields you only have 8 bits remaining for the opcode in an RRR instruction (versus 17 bits for 5-bit operand fields), and 16 bits remaining for both the immediate and opcode in an RRI instruction (versus 22 bits for 5-bit operand fields). You can reduce the average-case instruction size with various encoding tricks, cf. RVC and Thumb, but you cannot make full use of the architectural registers without incurring significant instruction size bloat.
To make the comparison fair, it should be noted that register renaming cannot resolve all dependency hazards that would be possible to resolve with explicit registers. You can still only have as many live values as there are architectural registers. (That's a partial truth because of memory.)
There are of course alternatives to register renaming that can address some of these issues (but as you say register renaming isn't just about this). Register windows (which come in many flavors), valid/dirty bit tracking per register, segregated register types (like data vs address registers in MC68000), swappable register banks, etc.
I think a major reason register renaming is usually married to superscalar and/or deeply pipelined execution is that when you have a lot of physical registers you run into a von Neumann bottleneck unless you have a commensurate amount of execution parallellism. As an extreme case, imagine a 3-stage in-order RISC pipeline with 256 registers. All of the data except for at most 2 registers is sitting at rest at any given time. You'd be better served with a smaller register file and a fast local memory (1-cycle latency, pipelined loads/stores) that can exploit more powerful addressing modes.
On MOS 6502 we used self-modifying code rather than the stack because it was more efficient and that CPU has no instruction and data caches, so they couldn't be corrupted or invalidated.
C doesnt "have", or require, a stack, either. It has automatic variables, and I think I looked once and it doesn't even explitly require support for recursive functions.
That means static allocation is insufficient for an implementation of automatic variables in a conformant C compiler. Nevertheless I still like to think of it as a valid implementation sometimes. In contemporary practice many stack variables are basically global variables, in the sense that they are valid during most of the program. And they are degraded to stack variables only as a by-product of a (technically, unnessary) splitting of the program into very fine-grained function calls.
AFAIK intel cpus have a hardware stack pointer
As you point out, modern architectures are actually designed to run C efficiently, so I'd say that's a good argument in favor of learning C to learn how (modern) computers work. Pascal is at the same level as C, but no one says "learn Pascal to learn how computers work" because architectures weren't adapted according to that language.
They used to say it though, before UNIX derived OSes took over the computing world.
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 malloc/free, so it's not like that's an underlying building block. It's simply a different building block.
So what are you trying to teach people, and is C really the way to get that concept across? Is the concept even _useful_ to know?
If you want to write fast code, which is what you'll commonly drop to C/C++ to do, then just learning C won't get you any closer to doing that. It won't teach you branch predictors, cache locality, cache lines, prefetching, etc... that are all super critical to going fast. It won't teach you data-oriented design, which is a hugely major thing for things like game engines. It won't teach you anything that matters about modern CPUs. You can _learn_ all that stuff in C, but simply learning C won't get you that knowledge at all. It'll just teach you about pointers and about malloc & free. And about heap corruption. And stack corruption.
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.
Care to elaborate?
The realization that malloc is really just kind of a crappier heavy-manual-hinting-mandatory garbage collector was a real eye-opener in my college's "implement malloc" project unit.
(To clarify: the malloc lib is doing a ton of housekeeping behind the scenes to act as a glue layer between the paging architecture the OS provides and high-resolution, fine-grained byte-range alloction within a program. There's a lot of meat on the bones of questions like sorting memory allocations to make free block reunification possible, when to try reunification vs. keeping a lot of small blocks handy for fast handout on tight loops that have a malloc() call inside of them, how much of the OS-requested memory you reserve for the library itself as memory-bookkeeping overhead [the pointer you get back is probably to the middle of a data structure malloc itself maintains!], minimization of cache misses, etc. That can all be thought of as "garbage collection," in the sense that it prepares used memory for repurposing; Java et. al. just add an additional feature that they keep track of used memory for you without heavy hinting via explicit calls to malloc() and free() about when you're done with a given region and it can be garbage-collected).
It occupies the same L1/L2 cache as any other memory. There's no decreased access times or fetches other than the fact that it just happens to be more consistently in L1 due to access patterns. And this is a very critical aspect of the system, as it also means it page faults like regular memory, allowing the OS to do all sorts of things (grow on demand, various stack protections, etc...)
There's a reason why SP was promoted to a first class citizen in AArch64 when they were otherwise removing features like conditional execution.
That's also the reason why using RSP as a GPR on x86 gives you terrible perf compared to the other registers, it flips back and forth between the stack engine and the rest of the core and has to manually synchronize in ucode.
EDIT: Also, the stack is different to the OS generally too. On Linux you throw in the flags MAP_GROWSDOWN | MAP_STACK when building a new stack.
He addresses all of that in the subsequent bullet points of his summary, and elaborates on it in the body of the article (your criticism stops at his first sentence of the summary). It goes into a nuanced discussion; it doesn't just make a blanket statement. I don't find it disingenuous at all.
What's really needed are languages that make it easier to express what you want to accomplish - this is still a huge problem, as evidenced by the fact that even a simple data munging task can be easily explained to people in a few dozen words, but may require hundreds of LOC to convey to the machine...
(BTW, it's time for us to be able to assume that the computer and/or language can do base-10 arithmetic either directly or via emulation. The reasons for exposing binary in our programming languages became irrelevant decades ago - ordinary programmers should never have to care about how FP operations screw up their math, it should just work.)
You'll learn what code looks like to the CPU, you'll get a feeling for how OOP works inside that box (things like the "this" pointer, vtables), what structures look like in memory, how dynamic linking works vs static linking by actually looking at what that code looks like in an executable. And you'll have something to show for it - something to prove you've acquired enough knowledge to achieve goals.
Concepts of structured programming arise from noting patterns commonly used -- you start using GOSUB instead of GOTO; you tend to make your loops very strictly nested because otherwise the code becomes unmaintainable, you find yourself writing data structures to manage related records, etc. From there, the transition to structured programming becomes very natural -- just formalizing some concepts that you've already internalized.
Is the author confusing virtual memory with virtual machine? Perhaps they're referring to the way a high level language abstracts away the details of the H/W. I didn't care enough to read on.
That said, I learned the most about "how a computer works" in a class that taught Intel 8080 assembler on a system running CP/M. (Technically it was MP/M but there was only a single console.) The instructor spent a lot of time explaining what registers were, accumulators, stack pointer, addressing RAM and so on. That's why I learned about H/W details, not because I focused on a particular language.
I thought the entire reason for C was to avoid having to deal directly with the H/W (though it can be done.)
The first reason that this is useful is that there are a lot of people out there who believe that C is somehow fundamental to computing. You and I both know that this is false, but I run into a ton of people who don't understand this. So, this first post is setting that stage: everything is always an abstraction, in the big picture sense. That's bullet point one.
That said, interpreting people literally isn't a good way to have a conversation, you need to know what they are saying, which may or may not connect to the exact words they used. I think when people are saying this phrase, they don't mean it in a literal sense. Part of the reason why is that there are some differences that matter when you zoom in from the big picture. I speculate a bit as to why, but regardless, knowing that it may not be literal is point two.
I've heard "all models are wrong; some models are useful" attributed to several people, but it's sort of the counter argument to bullet point one, and so makes up bullet point three. Drawing a distinction between the C abstract machine and the JVM can be a useful mental model, even if it's incorrect in some sense. The C abstract machine is closer to hardware than the JVM is, and even if it's not a perfect mapping, you'll be exposed to stuff that's closer than your high level language. As long as you know you're still working with an abstraction, learning C can be a great way to be exposed to this stuff. Just keep in mind that it's not magic, or particularly inherently special.
I do think that this is useful on its own. If you reduce it down to a soundbyte, sure, that's not interesting, but the interesting thing is in the details. In some sense, this is kind of the fundamental point of the article. You may find that boring, but that's okay; this stuff isn't really for you, both in a literal and figurative (experienced C developers generally) sense.
------------------------------------
Part two is going to discuss what happens if you take this to an extreme. I have two small bits of sample code that fundamentally do the same number of operations, and have the same computational complexity, but one runs much, much faster. This is due to how it interacts with caching, which is not part of the C spec, but is the reality of x86 (at least) hardware. This exposes a sort of fundamental tension when thinking about how the abstract machine relates to the physical machine. This is where C is really interesting, because it's low level enough to allow you to control memory allocation and access, which higher-level language users aren't really exposed to. This is the "why is this useful," really. The task is to know what behaviors you can rely on and which ones you can't, and how it relates to the hardware you actually want to support.
------------------------------------
Part three is going to show what happens if you make a mistake with the ideas from part two. If you incorrectly assume that C's abstract model maps directly to hardware, you can make mistakes. This is where UB gets dangerous. While you can take advantages of some properties of the machine you're relying on, you have to know which ones fit within C's model and which ones don't.
------------------------------------
I split this into three parts because it's an MVP, in a sense. Ship the first part so that I don't continue to revise the beginning over and over and over again. They're all related to each other, and could be one whole work, but it's true that this one is less directly useful than the others, as it's really setting the stage.
...
I guess my issue, even with the whole outline laid out (thanks!), is that while C "isn't how the computer works" in sort of the same sense as a SPICE model isn't really how a circuit design works and ns isn't really how a network works, it's close enough to be illuminating in ways most other languages aren't (and has the virtue of most mainstream hardware being explicitly designed to make it, and particularly it, faster).
I think more developers should know C (though I think almost nobody should write in it anymore).
The very next section, beginning on the very next line, begins to explain what the author means.
Then you missed my actual explanation and description, which is described in the rest of the post. Since others are also apparently confused, I'll re-state it here.
The C language is not defined in terms of hardware. The C language is defined in terms of an "abstract machine." This machine, being abstract, does not exist. "Virtual" and "abstract" are terms that are broadly speaking synonyms in general usage.
The spec even defines this in terms of an "execution environment" which can be "freestanding" or "hosted", and most C programs are, in the spec's language, running in the execution environment of C's hosted, abstract machine.
The rest of the post is exploring how this is conceptually the same, but different in details, than something like the JVM, which is what many people think of when they hear "virtual machine." As mentioned elsewhere in the thread, the sense of "virtual machine" that C uses is where LLVM gets its name from, yet people found that confusing enough that they changed the name.
This comment is also a re-statement of my point, maybe it helps: https://news.ycombinator.com/item?id=18123642
You may also argue that the abstract machine is practically insignificant. I disagree, but that's what my follow-up posts are about, so this post doesn't address this question directly at all.
Does that help?
Virtual has shifted meaning and using that word in this context confuses everyone.
Abstract is a perfectly cromulent word in this case.
I think the confusion stems from using the word "operates", which suggests a VM that exists at runtime:
> There’s just one problem with this: C also operates inside of a virtual machine.
I agree with the sibling comment that in this context the term abstract machine would be better. Also, saying "C is defined in terms of an abstract machine" instead of "operates" might be better.
Additionally, and this is something I really didn’t get into, languages aren’t inherently compiled or interpreted. You could have a C interpreter.
Of course; I was only addressing the confusion that other posters mentioned. While one could have a C interpreter (or any interpreter), for the purposes of the article this seems to be only a marginal point. In practice, C is (almost) never run that way, but your choice of words could suggest a parallel between the C abstract machine and the Ruby or Java VMs, and I think the way usual C implementations differ from those is more informative than how they are alike.
You do explain later that the C abstract machine is a compile-time construct, but many people read selectively and react immediately, as evidenced by several posts on this page.
C is useful for participating in commercial application of these things, but it is possible to be a very accomplished C developer and have no idea how hardware interfacing works and I'd wager this category vastly outnumbers those that understand hardware interfacing.
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.
The “byte addressable” thing is exactly why C was created over B, even, right? That was one of the crucial features not supported.
The C abstract machine presents a flat, uniform, byte-addressed address space.[1] The reason that it does not define what a pointer's representation is is because it needs to map that to what the hardware actually does, which is your point.
1: Actually, my impression is that it does, but this is actually an area of the spec in which I'm less sure. I'm going to do some digging. Regardless, the point is that the memory model != the machine model, which is your point.
EDIT: For example, https://en.cppreference.com/w/c/language/memory_model
> The data storage (memory) available to a C program is one or more contiguous sequences of bytes. Each byte in memory has a unique address.
Though cppreference is not the spec itself, of course. It is the conceptual model that's often presented.
LAST EDIT: I happened to run into someone who seemed knowledgeable on this topic on Reddit: https://www.reddit.com/r/programming/comments/9kruju/should_...
TL;DR no! This is another misconception. Tricky!
I taught myself C when I was a teenager (on an Amiga, back in the 80's.) It is amazing that almost 30 years later, I'm still learning new things about it.
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.
Example: conversions between function pointers and regular pointers... https://stackoverflow.com/questions/32437069/c-void-function...
https://en.wikipedia.org/wiki/B_(programming_language)
From the above article:
>B is typeless, or more precisely has one data type: the computer word.
I had read the Martin Richards (inventor of the language) book about BCPL (predecessor of B) early in my career, although I could not work on it, since there was no machine available to me that could run it. (It was already outdated then.) Interesting language though, and even the systems software examples shown in the book (written using BCPL) were cool.
You're right about why C was created, byte addressability.
From the article about C:
https://en.wikipedia.org/wiki/C_(programming_language)
>The original PDP-11 version of Unix was developed in assembly language. The developers were considering rewriting the system using the B language, Thompson's simplified version of BCPL.[11] However B's inability to take advantage of some of the PDP-11's features, notably byte addressability, led to C.
Witness any discussion of a pointer bug at any level of the stack. No matter what the piece, someone will jump in and say, "that should have been bounds checked!" A lot of times it's true. But what they miss is that the bounds check needs to come from somewhere, which means there is a layer of the system where it doesn't apply. Somewhere you have a larger piece of memory, and it gets divided into smaller chunks, and the boundaries are fiction, meaningful only to a higher level abstraction. This is the way it needs to work.
Reducing the code in which that's a concern is likely legitimate. But then you enter into "that's not really how it works".
Not really, there was a world of computing outside AT&T walls.
Lots of papers and computing manuals are available online for those that care about the actual history of computing.
Burroughs designed ESPOL in 1961, improved into NEWP, still being sold by Unisys as ClearPath MCP.
IBM did all their RISC research with PL/8, before creating Aix for their RISC systems thus adopting C instead.
IBM i and z mainframes made use of PL/S, C and C++ only came later into the picture as the languages got industry adoption.
Xerox PARC initially used BCPL, but quickly followed up with Mesa, then Mesa/Cedar.
Wirth was inspired by Mesa to create Modula-2 and then by Mesa/Cedar to create Oberon.
Mesa/Cedar designers went to Olivetti and created Modula-2+ and Modula-3.
Apple wrote Lisa and initial versions of MacOS in a mix of Pascal and Assembly.
VAX used BLISS to develop VMS.
PL/I was used by multiple companies, not only by MIT to write Multics.
This is just a very brief overview.
As for Assembly embedding, it is a language extension not part of ISO C, and was quite common in many languages during the 70 and 80's even some BASIC interpreters had it, like on Acorn computers.
When you ask what portable assembler is, there's actually three different things you could mean:
1. C is portable assembler because every statement maps pretty directly to assembly. Obviously, compiler optimizations tend to make this completely not true (and most of the rants directed towards compiler developers are precisely because they're eschewing naive mappings).
2. You can represent every (reasonable) assembly listing using C code. Well, except that C has no notion of SIMD value (yes, there's extensions to add vector support). Until C11, it couldn't describe memory ordering. Even with compiler extensions, C still doesn't describe traps very well--any trap, in fact, is undefined behavior.
3. Every assembly instruction can have its semantics described using C code more or less natively. Again, here C has an abstract machine that doesn't correspond very well to hardware. There's no notion of things such as flag registers, and control registers are minimal (largely limited to floating-point control state). Vectors and traps are completely ignored in the model. Even more noticeably, C assigns types to values, whereas processor definitions assigns types to operations instead of values.
Note here that I didn't need to invoke undefined behavior to show how C fares poorly as portable assembler. The problem isn't that C has undefined behavior; it's that a lot of machine semantics just don't correspond well to the abstract semantics of C (or indeed most languages).
I don't think people need to be able to code in C at the drop of a hat. But it should not be a scary thing for good engineers.
My university introductory classes were Pascal and C++.
How so? It's not like you can't write operating systems in other, more readable and understandable, languages.
C really will test you and make you a better programmer than any high level language ever could. Someone who is a good C programmer will right better code in any language than someone who is just focused on high level languages. The same could not be said for python, java, or js.
1. https://www.joelonsoftware.com/2005/12/29/the-perils-of-java...