论坛徽章:: 3

1楼 [报告]

发表于 2013-01-25 18:27 |显示全部楼层

很显然，LZ你文笔太差。别说写小说了。LZ的技术文章也是烂的一坨(嗯，。。。)，我保证没人读。
哈哈。写技术文章也要求文笔的，不骗你啊。譬如上次你写的那个关于mmap的。上下文全无，什么读啊写啊，私有啊共享啊，全不指明操作对象。于是我鉴定为烂文。。。

为了告诉LZ怎么写技术文章，我决定把我写的一篇[还没写完，用来教我的学生的]就上传在这里，占下LZ的楼。。。

captivated

小富即安

论坛徽章:: 3

2楼 [报告]

发表于 2013-01-25 18:28 |显示全部楼层

=========================================================
1. about programming language

we use natural language to communicate each other. we express
our thoughts by natural language, like English, Chinese,
French, Japanese, etc.
programming language is different from natural language. for briefness,
we use programming language to communicate with computer.

computer can only understand binary, or machine code.
so obviously we can not use natural language to communicate with computer.
anyway, we should express our intention to computer. machine code is not
a good choice, because it's not human readable.

the intension issued to computer should be unambiguous. and we must give
a good form to express our intension, the form should be human readable.

so the first thing is, to specify the form, or to formulate a form -- or,
to specify the syntax of the language.
and the second thing is, to specify the semantics of the specified form.
when the form and the semantics of specified form is stipulated, we say,
we designed a language, the language is a formal language,
it's different from natural language, because the form is specified,
the semantics on specified form is specified, and they must be unambiguous.

but actually, computer don't understand the formal language too,
so we need a translator to translate the formal language to machine code
or computer instructions.
so a set of tools should be developed, to translate the formal language
to machine readable language.

we say, the specification of those form and semantics and how they be mapped
is the language standard, like C89, C99 is the standard of C.

we say, the set of tools which play a role of translator is the language
implementation, like gcc.

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？

captivated

小富即安

论坛徽章:: 3

3楼 [报告]

发表于 2013-01-25 18:29 |显示全部楼层

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

2. tool chain and runtime environment

we don't need to design and implement a computer language ourself, it's
a hard work. and fortunately, there're good lanuages designed very well we can use.
C is a good choice.

so we learn C language, learn the syntax, learn the semantics related to the
specified syntax, and then use it to express our intension to computer.
for programming as a expert, many things should be known:

1). the way how the "translator" work -- in fact we don't need to care excessively,
except you want design and implement a lanaguage for yourself, or you want
to maintain those tools, or you just like it. to design and implement
a programming language is often an area of expertise, known as compilation principle,
you can study it if you like.
the translator is not just a tool. it's a set of tools. maybe the compiler is the
most important tool, it's the "real" translator; but it doesn't work if we just have
a compiler. GCC stands for "GNU Compiler Collections", it's a wrapper of many
compilers, C/C++, Fotran, Objective C, and so on.

2). the environment the program run on. we say the environment of the program running on
is runtime environment.

we've known that, the process to translate C to a executable program has four steps, each
step correspond a tool.
1) Preprocessor. the cpp.
2) Compiler. the cc1.
3) Assembler. the as(gas, GNU as).
4) Linker. the ld.

they collectively called tool chain.

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？

captivated

小富即安

论坛徽章:: 3

4楼 [报告]

发表于 2013-01-25 18:31 |显示全部楼层

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

4. the translation steps

pretend there's a program composed of obj.c and main.c.
the example is in the attachment, lies in the dir compile.

we can invoke gcc on commandline like the following:
#gcc main.c obj.c

then an executable program named a.out will be yield.
gcc hide the process how it be made.
in fact, the 2 source files are preprocessed, compiled, and assembled independently, each source
file yield an object file, then the 2 object files is linked.

obj.c
\
\ preprocesser. substitute the macro string, and do header files include, etc.
\ #cpp obj.c > obj.i
\ or
\ #gcc -E obj.c -o obj.i
\
\------> obj.i
      \
      \ compiler, to compile C source file to assembly source file.
      \ the compiler is cc1. the compiler is wrapped by gcc,
      \ we can manually invoke it on commandline:
      \ (this command depend on platform, 4.4.3 is the gcc version on my system)
      \ #/usr/lib/gcc/x86_64-linux-gnu/4.4.3/cc1 obj.c -o obj.s
      \ or
      \ #gcc -S obj.c -o obj.s
      \
      \------> obj.s
               \
               \ assembler, to assemble the assembly source file to binary object file.
               \ #as obj.s -o obj.o
               \ or
               \ #gcc -c obj.s -o obj.o
               \
               \------> obj.o

main.c
\
\ #gcc -c main.c -o main.o
\
\------> main.o

-------------------------------------------------------------------------------------
then, we link these 2 object files:
#gcc main.o obj.o

the program named a.out is yield.
in fact we can manually invoke ld on commandline to complete the link step.
but many details, at this occasion, are very complex. these details should be cared by gcc
but not us.
why? because in fact the C library should be linked with our object files -- we used printf in
our program. and printf is a routine lies in the standard C library. we know, libraries on
our system lies in dir /lib or /usr/lib, so the standard C library is /usr/lib/libc.a(static library)
or /lib/libc.so.*(shared object, or dynamic linked library). in most cases, if we just invoke
gcc like the above command, the .so library is linked; and some cases the static .a library is
used, so, the standard C library just supplied itself by .a and .so form.
and, the crt1.o, crti.o, crtn.o should be linked with our object files too. -- now just never mind
what these crt*.o are...
not over yet.

in fact, you can see the details what's gcc do at the link step. just add a --verbose or -v option:
#gcc main.o obj.o --verbose

see it?
so, if you really want to invoke ld manually, you can use the following command[it work on my platform,
ubuntu 10.04 LTS, x86_64. your environment is the about the same with me, so you can try it]:
#ld main.o obj.o /usr/lib/crt*.o -lc --dynamic-linker /lib/ld-linux-x86-64.so.2 -o main

the above ld invocation will yield the executable program main.
1) main.o obj.o /usr/lib/crt*.o should be linked.
2) -lc: -l is a option means to link a library; c is the .so library libc.so.6, -lc means to link the
standard C library.
3) --dynamic-linker option specify the dynamic linker we need: /lib/ld-linux-x86-64.so.2

more complete command:
#ld main.o obj.o -dynamic-linker /lib/ld-linux-x86-64.so.2 /usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.4.3
-lgcc  -lgcc_eh  -lc /usr/lib/gcc/i686-linux-gnu/4.4.5/crtend.o /usr/lib/crtn.o -o main

1) -L/usr/lib/gcc/x86_64-linux-gnu/4.4.3 specify the dir in addition to the default path
in which the ld search libraries.
2) you can ls these dirs in the above command.

tips: the above commands may be changed depend on different platform & system.
by the way, the ld's true colors is the program collect2.

so now you see why invoke ld manually on commandline is not a good idea.
-------------------------------------------------------------------------------------

a question:
why does compiler just translate C source language to assembly language?
why doesn't compiler translate C source language to object file directly?
a good question, isn't it?
let's shelve this question temporarily.