Recommend a text that explains the physical implementation of C

I saw some truths in the popular thread below "why new programming students aren't fairing well." I am currently in an online MSCS program, but my undergrad is in Aero Eng and not CS. Because of my different BS, in order to get into the MS program, I had to illustrate a very basic understanding of C, Java, and data structures. Of the 3 of those, I am definitely the weakest on C. Most of the rest of my MS program focuses on much higher level things (Databases, AI, etc), and although I passed the entrance requirements for C, I certainly do not feel like I understand it well enough for my own satisfaction. I feel as though I will never get a better education on the lower level stuff unless I chase it down on my own (since my MS just keeps focusing "higher"). I have had friends who are software developers say I can build a whole career on high level stuff only, and even if that is true, I am somebody who likes to understand things from the ground up, and right now my questions about C make me feel inadequate as a software-developer-to-be.

I'm almost finished with my 2nd run through the K&R and am getting very good at the syntax for even the typical "difficult issues" such as pointers. However, one thing I've learned in all my frustration is that understanding pointers and the other tough parts of C requires understanding the physical side of what the code is actually doing. Memory allocation, stack, heap, memory leaks, etc... to me they all seem very important, and I only have a very vague understanding of how it all works... and K&R doesn't really touch on any of that. One question that always sticks out in my mind is why, historically, did programming evolve to use stack and heap in the way that it does? Surely it's not the only implementation that would work, but it is the one that has stuck. What little I do know about these issues, I've picked up from forum threads here, stackoverflow, and random tutorial websites. I'd like to read some kind of text though that presents a much more comprehensive look at the physical side of C, if that makes any sense. Can anybody point me in a good direction?

Thanks!

For your reading request ... CLICK ... be warned there is a LOT of information there.

As for some of the basic questions...
Why the stack instead of the heap ... at one time it was a performance issue as most CPUs have registers built in for handling the stack directly. It's a lot faster to push a register to the stack than it is to use OS APIs to allocate memory for it. It's also a lot easier, for the same reasons.

Memory allocation is actually a system API call... For Windows, check THIS It is definately slower than stack allocations but considerably more flexible.

Yes there were other ways it could have been done. Pascal for example reserved heap space for variables but used it's own mapping scheme to make it almost as fast as stack allocations.

Also keep in mind that C started out on single threading, single user systems and has stalwartly maintained reverse compatibility, for reasons I'll never understand. If it was up to me C would have gotten a string type on it's first revision; its such an obvious oversight.

Quote:

---

Originally Posted by CommonTater

Also keep in mind that C started out on single threading, single user systems and has stalwartly maintained reverse compatibility, for reasons I'll never understand. If it was up to me C would have gotten a string type on it's first revision; its such an obvious oversight.

---

Err.. Do you really think that Unix was single threading, single user system ? .. :D

Also.. Character arrays and streams are somewhat like an Universal interface...and having a separate string type would only serve to add an extra layer of abstraction over that (that was the purpose why C++ was created ...but I won't mention that you again!).

Quote:

---

Originally Posted by manasij7479

Err.. Do you really think that Unix was single threading, single user system ? .. :D

Also.. Character arrays and streams are somewhat like an Universal interface...and having a separate string type would only serve to add an extra layer of abstraction over that (that was the purpose why C++ was created ...but I won't mention that you again!).

---

No I don't think unix was single anything... DOS was... as were early versions of Windows... and that's where C really got it's toe hold in programming.

Pascal had strings... real strings you could manipulate and test using = := < > etc. and I found it a whole lot more programmer friendly than C... It may be an extra abstration, but it's one I would happily welcome.

And FWIW... C++ doesn't have a native string type either. It's still a library function using operator overloading to produce strings that require conversion to use in C based API calls.

Quote:

---

DOS was... as were early versions of Windows...and that's where C really got it's toe hold in programming.

---

Are you out of your mind ? C was already nearly used for everything before DOS started walking !

Quote:

---

Originally Posted by wiki

In 1972, Unix was rewritten in the C programming language

---

Dos wasn't even written in C ! ...and didn't have any sort of (AFAIK) facilities for C programming at least a decade or so.
(Also..AFAIFbSTFW.. msdos was written in assembly..)

Quote:

---

And FWIW... C++ doesn't have a native string type either. It's still a library function using operator overloading to produce strings that require conversion to use in C based API calls.

---

Define native.
In OOP (And yes..I know your head does not work in that way..!), Class==Type ..and allow much more flexibility than if they were hard coded into the core language. (Also..even my debugger displays it like a native char array when queried during breaks .)
And of course it'd require conversions to be used...in fact you can't avoid that when switching between strings of two different languages.

Ok, I can see I've hit some kind of bizarre nerve here...

Conversation over.

Quote:

---

Originally Posted by CommonTater

Ok, I can see I've hit some kind of bizarre nerve here...

---

Yes..the most bizarre one..
It is called logic..btw!

C was made a commercially successful and widespread language outside of Unix, that's true. It's creation and first success however, was in and for Unix.

Quote:

---

Originally Posted by The111

One question that always sticks out in my mind is why, historically, did programming evolve to use stack and heap in the way that it does? Surely it's not the only implementation that would work, but it is the one that has stuck.

---

Stacks are used for function calls, where you want the program to do go off and do something and then come back to where it was and continue on. Any mechanism that will allow you to arbitraryily deep into function calls will do, e.g. linked-list. But no matter what the implementation, it is still a stack, because anything that is LIFO is a stack. A contiguous block of memory is the simplest and most efficient thing to use for a stack implementation. Stacks on some systems grow downwards and on other systems they grow upwards, either is fine.

A heap is at its core something where memory can be allocated in any order and deallocated in any order. Various heaps on different platforms work differently, but they all do essentially the same job.

CommonTater, let's just say the history you describe might have happened in a different universe, but not the one this forum exists in.

As to the distinction between heap and stack.... they predated C by a long way, but have hung around.

Historically, early computers have very limited memory resources, and (in software and hardware) the interaction with memory was colloquially via this thing referred to the stack (it was managed using a LIFO stack data structure with the help of some machine registers). It was not anticipated, at that time, there would ever be a need to build computers with more than a megabyte or so of memory. As hardware became more capable, and more memory installed, programmers wanted or needed to access that memory. Physically, the additional memory was distinct from what associated with the stack, so early operating systems managed this additional memory differently. So that additional memory had a range of names (depending on memory chips and how it was accessed via device drivers) including "high memory", "extended memory", "heap" and a few other names. The name "heap" eventually stuck.

Later on, with more advanced memory management units, the distinction between heap and stack became a bit more academic, at least from a hardware perspective. However the names stack and heap stuck around. From an operating system and application perspective, the stack is now basically a small chunk of memory used as scratch space for a thread of execution - when a function is called, some data is allocated at the "top" of the stack (which literally implements a LIFO stack, so all that is necessary to allocate or deallocate memory from the stack is changing value of a pointer) to hold state, and popped off again when the function returns, in order to restore caller context and other things. Conventionally, it happens that local variables in a function also make use of the stack. The heap is now the memory set aside for dynamic memory allocation (malloc(), etc in C). There are no constraints on when memory is dynamically allocated, or when it is released, so dynamic memory allocation tends to take more work than an allocation on the stack (an allocation or deallocation involves more than setting a pointer).

In modern operating systems, each application typically has its own stack, and the upper size limit is usually some relative small quota (usually allocated on a per-user or per-system basis by an administrator). The operating system allocates this memory while starting up the application and (hopefully) reclaims it when the application is terminated. With multi-threaded programs, each thread in an application is allocated its own stack when the thread is started (this often includes thread local storage). The heap, however, is generally directly managed by the operating system - applications dynamically request memory as they need it, and release it when done. Modern operating systems can reclaim heap when a program exits, but that takes a bit of work (and more primitive operating systems don't do it) which is why programmers are still encouraged to deallocate memory before terminating their program.

Good discussion on the heap and stack, Grumpy.

Thanks Grumpy, glad I got a couple good answers out of all the arguments I caused inadvertently!

Still no books recommended, but on my own searching today I found this one... looks like it might be a good place to start.
Amazon.com: Expert C Programming (9780131774292): Peter van der Linden: Books