From 2c226859cfc911c4a1eea009897050a16714aeec Mon Sep 17 00:00:00 2001 From: Rob Landley Date: Thu, 15 Nov 2007 18:30:30 -0600 Subject: Remove trailing whitespace (thanks to Charlie Shepherd), and a couple comment tweaks. --- www/design.html | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'www') diff --git a/www/design.html b/www/design.html index 5380bd74..27e8af43 100644 --- a/www/design.html +++ b/www/design.html @@ -52,7 +52,7 @@ Technica: part three, plus this article on -cacheing, and this one on +cacheing, and this one on bandwidth and latency. And there's more where that came from.) @@ -72,7 +72,8 @@ memory returned by malloc() is only a virtual allocation, filled with lots of copy-on-write mappings of the zero page. Actual physical pages get allocated when the copy-on-write gets broken by writing to the virtual page. This is why checking the return value of malloc() isn't very useful anymore, it -only detects running out of virtual memory, not physical memory.)

+only detects running out of virtual memory, not physical memory. Unless +you're using a NOMMU system, where all bets are off.)

Don't think that just because you don't have a swap file the system can't start swap thrashing: any file backed page (ala mmap) can be evicted, and @@ -123,7 +124,7 @@ get a good bang for the byte.

Your binary is the executable file on disk, your heap is where malloc() memory lives, and your stack is where local variables (and function call return addresses) live. Optimizing for binary size is generally good: executing -fewer instructions makes your program run faster (and fits more of it in +fewer instructions makes your program run faster (and fits more of it in cache). On embedded systems, binary size is especially precious because flash is expensive (and its successor, MRAM, even more so). Small stack size is important for nommu systems because they have to preallocate their stack -- cgit v1.2.3