Hi Guy,
I liked the tutorial a lot.
Here are my comments on it. The comments range from mere typos (most of
them) to (IMO) some more advanced ones. Unfortunately they are all messed
up together in this large message.
I really thought quite a bit whether to send the comment in private or on
the lists. However I think that sending to the lists will be better
because other people might be interested in them and also might correct me
if I was wrong. For those of you who are not interested in the comments,
the delete command is always there.
Once again, I want to congratulate you for the great job!
Emil
Subsection: Machine Architectures - Memory, Cache, Registers, 2nd
paragraph:
Usually, the cache is hidden from our our programs
^^^--repeated
Subsection: Machine Architectures - Memory, Cache, Registers
A suggestion: Maybe it would be a good idea to mention the fact that many
machines require that at least one of the operands should reside in a
register. More generally I think that it should be stressed that unlike
cache, registers are not transparent at the assembly language level.
(OUTCH, I already introduced `assembly language' without defining
what that is. I'm sure, you will do a better job ;-))
Subsection: Virtual Memory. Virtual memory works by the operating
system Though the idea is clear, I think the wording is a little bit
weird and should the sentence should be somehow rephrased.
Subsection: Memory Protection. In addition to preventing from one program
from corrupting the memory of other programs, the memory protection
mechanism makes sure that no program can corrupt the operating
system itself.
Subsection: Run-time Management Of Virtual Memory. the CPU identifies a
page fault. Replacing `identifies' with `generates' is better IMO (even
though the idea might not be the same).
Subsection: SIGSEGV This! SIGBUS That!
The message displayed during a segmentation violation depends on the
operating system and even the shell. I remember that some version of sh
(on Solaris) would display `Memory error'. Hmmm...;-)
IIRC, FreeBSD generates SIGBUS on protection errors.
Also, most Linux kernels do not turn on the Aligmnent Check flag on ix86,
meaning that it won't generate bus errors due to pointer misalignments.
In short, it's worth mentioning that various flavors of UNIX behave
differently under these conditions.
NULL on *all* machines is defined as '0'. It is the compiler's job to
translate the constant '0' into the appropriate bit pattern for the
address corresponding to the null pointer. Indeed, on most machines that
bit pattern is also all-bits zero, but not on all. Why should there be
non-all-zero bit patterns for null pointers? Because on those machines
those non-zero bits were supposed to trigger some access exceptions. But
indeed, due to the sheer amounts of bugs, most hardware manufacturers to
give in and use all-zero bit patterns for null pointers. The C language
faq gives an excellent explanation of all these issues.
Subsection: Load On Demand. Another solution to the problem of overwriting
the executable while it is running is locking the executable file for
writing. This is the solution adopted by Windows NT. I think that there
are also some UNIX versions which use this strategy.
Subsection: Read-Only Memory. As I said before, IIRC, FreeBSD sends SIGBUS
for protection errors. In addition to mmap(), you could also directo the
readers to the man page of mprotect().
Section: Memory managers (introductory paragraph). Therefor,..
typo repl. with Therefore^^^
Subsubsection: Allocating A Chunk, 2nd paragraph:
Thus, Assuming
^lower case
Subsubsecrion: Freeing A Chunk
4th paragraph:
is adjucent
^--typo, repl. with adjacent
last paragraph:
in actuall
^-typo, repl. with actual
Subsection: Interaction With Unix's Memory Management
end of 1st paragraph:
this ammount
^typo, repl. with amount (also at the end of the phrase)
Note that the memory used for storing data whose size is not known in
advance is the dynamically allocated memory. The size of the statically
allocated variables is known in advance and the appropriate memory is
allocated by the OS during process startup.
3d and last paragraph: amount mistyped as ammount.
Subsection: Specialized Memory Managers
general memry managers are
^-typo, repl. with memory
Subsection: Memory Manager's Interaction With Program's Code
End of 1st paragraph: memery manager's functions
^--typo, repl. with memory
Section: C Runtime Memory Management
introductory paragraph: being a language that works on a low level
^repl with `at'
Subsection: The Stack And Local Variables
End of 1st paragraph: fucntion 'main'
^-typo,
