Showing posts with label under-the-hood. Show all posts
Showing posts with label under-the-hood. Show all posts

Thursday, July 28, 2011

Good Articles on Internals of C++ and Unix

A) C as a glorified assembler:

"C a glorified assembler" or "C a generalized assembler"

Actually I only really started understanding C when I understood 2 things about it.
1) Anything you code in C finally translates to assembly language.
2) How your compiler interacts with the O.S. loading/linking mechanism.

You can easily test this.
Use the 'gcc --save-temps ' feature of your gcc compiler to see the assembly language output.

C program to assembly code translation
>>>>>>>>
C program
>>>>>>>>
extern int printf(const char *, ...)
int main()
{
 printf( "Hello, World!\n");
 return 0;
}

#Retain temporary intermediate files generated during preproc, compiling, assembling etc.
gcc --save-temps test.c

>>>>>>>>
Pseudo-Assembly (see link for more accurate example)
>>>>>>>>
.data                              # data section starts at say 0x100
msg ds "Hello, World!\n"           # define string with label as msg and content as "Hello, World!\n"

.text
push sp                            # save the current stack pointer
push msg                           # push the function parameter onto stack
call _printf                       # make the library call
ret   0                            # essentially return 0 as errorvalue to bash/cmd.exe

>>>>>>>>

Since the C language is portable from one platform to another it kind-of acts like a virtual machine (without byte-code generation of-course).
The same C program will compile on different machine-compiler pairs to the specific assembly language and O.S. of the platform in question.

This makes for  chip/hardware specific assembly(Intel x86 or Motorola or ARM ...) portability.

Write Great Code :

What happens when you run your program?
The dynamics from Compilers to O.S. to Assembly language to Memory to CPU.
This book covers it all

You have 2 choices:
1) You can choose to spend years garnering small nuggets of internals of your Program and how it runs on your machine. You'd need a few books each on Operating System, Linker Loader, Assembly Language, Compiler Design, Hardware.
Next would be loads of patience to connect all this into a chimera/frankestein-of-sorts (horribly put together)
OR
2) You could read it all here - Integrated into a beautiful and coherent whole written by a master.

Write Great Code, Volume 1: Understanding the Machine
Write Great Code, Volume 2: Thinking Low-Level, Writing High-Level
The Art of Assembly Language


Refer:
  1. C to Assembly Translation Article from EventHelix
  2. Inside the C++ Object Model : http://techtalkies.blogspot.in/2007/07/stub-bookreview-c-object-model-by.html
  3. X86 Calling (and stack cleanup) conventions: http://en.wikipedia.org/wiki/X86_calling_conventions
    X86 Disassembly Wikibook (download as pdf): http://en.wikibooks.org/wiki/X86_Disassembly
==================================================================

B) Interaction with O.S. loader/linker/virtual-memory:

The specific C compiler would also link the O.S. specific C runtime properly.

So gcc which is a portable compiler would link in.
a) mingw C runtime on Win32
b) linux C runtime on Linux.

The same C program would also convert to correct assembly/runtime on
Watcom C++, Visual C++ compiler, AIX, HP/UX compilers etc.

Note:
a) printf() comes from the C Standard Library
b) C runtime library contains the startup code which executes before and after main

Refer:
1) C++ runtime environments on HP-UX
2) Internals of C/C++ compiler implementations
3) How to use debug C runtime to debug your application
4) How to write a minimal Kernel in C (a very simple Hello world program which also describes the libc C runtime library)
5) Understanding System Calls
Note:
The C standard library calls like open(), close(), putc(), getc() etc actually just forward the call to O.S. system calls in the linux kernel. The C runtime actually maps a stdlibrarycall to an interrupt vector i.e. system call index number in a lookup table. Then it uses a software interrupt to call the system call (transfers from user mode to kernel mode and back)

==================================================================

These are a set of articles that take a look at what happens inside C, C++, Unix internals as we compile and run our programs. The info here is invaluable to debug compile errors, runtime errors and memory issues. You can go through these in your spare time. Take a print out to read in your spare time and go through these articles.

  1. What Happens When You Compile and Link a Program
  2. What a Compiler Turns Your C Code Into
  3. Virtual Base Classes Implementation
  4. How the C++ compiler mangles/decorates function namesUnix And C-C++ Runtime Memory Management For Programmers
  5. Under The Hood Look At Operating Systems Internals with Windows and Linux : http://techtalkies.blogspot.in/2010/08/operating-systems-and-linux.html
  6. mmap is not the territory (Part 1): http://techtalkies.blogspot.com/2010/09/mmap-is-not-territory-or-mapfail-sigbus.html
  7. mmap is not the territory (Part 2): http://techtalkies.blogspot.com/2010/09/mmap-is-not-territory-part-2.html

==================================================================

Thursday, August 19, 2010

Under The Hood Look At Operating Systems Internals with Windows and Linux

[08-Sep-2010]

Extremely Recommended reading:
  • This blog has some simply delicious diagrams with 1-2 page explanations of Paging, Virtual Memory, Caching, Physical level RAM, Snapshot of a Process in Memory.
  • This is a simply superb blog. "A picture is worth a thousand words!!". The articles have some high quality illustrations which esp. for visual learners is a delight. Just working through the flow in the diagrams makes the text just an add-on (to explicitly elaborate on any point you might have missed).
  • This helps you get an "all-at-once" picture of the entire flow and inter-relationships between different parts (esp. if you're a visual/top-down learner).
  • I learned more in 30 minutes of analyzing these lovely diagrams than boring holes in all the below books for days on end.
Once you've gone through this blog the below books become so much more intelligible:
Good article on RSS and VSZ reporting by ps aux and pmap to determine memory footprint of your proces. 
See the comments for some good discussion of internals

Wednesday, July 11, 2007

BookReview: Inside the C++ Object Model by Stanley Lippman

One of the Best books on C++ internals/under-the-hood.

NOTE: The author was hired by Microsoft as Architect to clean up its extremely non-standard/buggy VC++ compiler to conform to the C++ Standard.

0) The original Cfront preprocessor/compiler converted C++ into C.
That means that almost every C++ code "could" be converted into C.
Note: Modern C++ compilers no longer convert to C, but it helps to make the compilation process more easy to understand. This book connects the dots.
1) Virtual tables/functions turn into simple function pointer table lookups.
Simple data structures show how this is implemented in different compilers.
2) Generated functions like default constructors etc. finally start to make sense.
3) Inheritance starts looking more like compiler controlled composition of objects.
4) Gives you X-Ray vision right from compiler data-structures to actual assembly code.

5) Watch out for the typos and the mismatch between some of the diagrams and the explanation.

You start seeing the source code "through the compiler's eyes". A lot of work from the compiler goes into making your Object-oriented code run.

A Must have book for any person wanting to really know how the compiler works with C++.