WWW-www.enlightenment.org pushed a commit to branch master.

http://git.enlightenment.org/website/www-content.git/commit/?id=9809d441a74ab40da351a2e065fb4d71bbe4cee8

commit 9809d441a74ab40da351a2e065fb4d71bbe4cee8
Author: Raster <ras...@rasterman.com>
Date:   Thu Apr 30 03:15:28 2015 -0700

    Wiki page start changed with summary [] by Raster
---
 pages/docs/c/start.txt | 100 ++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 98 insertions(+), 2 deletions(-)

diff --git a/pages/docs/c/start.txt b/pages/docs/c/start.txt
index 0aaa79a..8bdfd03 100644
--- a/pages/docs/c/start.txt
+++ b/pages/docs/c/start.txt
@@ -1,9 +1,105 @@
 ~~Title: C Primer~~
 ~~CODE-c~~
 
-{{page>index}}
+==== Preface ====
 
-==== Also See ====
+//This is not a theoretical C language specifications document. It is a 
practical primer for the vast majority of real life cases of C usage that are 
relevant to EFL. It covers application executables and shared library concepts 
and is written from a Linux/UNIX perspective where you would have your code 
running with an OS doing memory mappings and probably protection for you. It 
really is fundamentally not much different on Android, iOS, OSX or even 
Windows.//
+
+//It won't cover esoteric details of "strange architectures" which may, in 
theory exist, but in real life are long dead, never existed, or are so rare 
that you won't need to know. It pretty much thinks of C as a high level 
assembly language that is portable across a range of modern architectures.//
+
+//Keep this in mind when reading, and know that some facets of C have been 
adapted to take this view of things. It simply makes everything easier and more 
practical to learn, along with actually being relevant day-to-day in usage of 
C.//
+
+==== The machine ====
+
+Reality is that you are dealing with a machine. It's real. It has its 
personality and ways of working thanks to the people who designed the CPU and 
its components. Most machines are fairly similar these days, of course with 
their variations on personality, size etc.
+
+All machines have at least a single processor to execute a series of 
instructions. If you write an application (a common case) this is the model you 
will see right in front of you. An applications begins by executing a list of 
instructions at the CPU level.
+
+The C compiler takes the C code files you write and converts them into 
"machine code" (which is really just a series of numbers that end up stored in 
memory, and these numbers have meanings like "0" is "do nothing", "1" is "add 
the next 2 numbers together and store the result". "2" is "compare result with 
next number, store comparison in result", "3" is "if result is 'equal to' then 
start executing instructions at the memory location in the next number" etc.). 
Somewhere these numbers are [...]
+
+CPUs will do arithmetic, logic operations, change what it is they execute, and 
read from or write to memory to deal with data. In the end, everything to a CPU 
is effectively a number, and some operation you do to it.
+
+To computers, numbers are a string of "bits". A bit can be on or off. Just 
like you may be used to numbers, with each digit having 10 values (0 through to 
9), A computer sees numbers more simply. It is 0, or it is 1. Just like you can 
have a bigger number by adding a digit (1 digit can encode 10 values, 2 digits 
can encode 100 values, 3 can encode 1000 values etc.), So too with the binary 
(0 or 1) numbering system computers use. Every binary digit you add doubles the 
number of values you [...]
+
+Numbers to a computer normally come in sizes that indicate how many bits they 
use. The sizes that really matter are bytes (8 bits), shorts (16 bits), 
integers (32 bits), long integers (32 or 64 bits), long long integers (64 
bits), floats (32 bits) doubles (64 bits) and pointers (32 or 64 bits).  The 
terms here are those similar to what C uses for clarity and ease of 
explanation. The sizes here are the **COMMON SIZES** found across real life 
architectures today. //(This does gloss over so [...]
+
+Bytes (chars) can encode numbers from 0 through to 255. Shorts can do 0 
through to 65535, integers can do 0 through to about 4 billion, long integers 
if 64 bit or long long integers can encode values up to about 18 qunitillion (a 
very big number). Pointers are also just integers. Either 32 or 64 bits. Floats 
and doubles can encode numbers with "a decimal place". Like  3.14159. Thus both 
floats and doubles consist of a mantissa and exponent. The mantissa determines 
the digits of the numbe [...]
+
+When we want signed numbers, we center our ranges AROUND 0. So bytes (chars) 
can go from -128 to 127, shorts from -32768 to 32767, integers from around -2 
billion to 2 billion, and the long long integers and 64 bit versions of 
integers can go from about -9 quintillion to about 9 quinitillion. By default 
all of the types are signed (except pointers) UNLESS you put an "unsigned" in 
front of them. You can also place "signed" in front to explicitly say you want 
the type to be signed. //A cat [...]
+
+Memory to a machine is just a big "spreadsheed" of numbers. Imagine it as a 
spreadsheet with only 1 column and a lot of rows. Every cell can store 8 bits 
(a byte). If you "merge" rows (2, 4, 8) you can store more values as above. But 
when you merge rows, the next row number doesn't change. You also could still 
address the "parts" of the merged cell as bytes or smaller units. In the end 
pointers are nothing more than a number saying "go to memory row 2943298 and 
get me the integer (4 byte [...]
+
+This level of indirection can nest. You can have a pointer to pointers. so 
de-reference a pointer to pointers to get the place in memory where the actual 
data is then de-reference that again. Since pointers are numbers, you can do 
math on them like any other. you can advance through memory just by adding 1, 
2, 4 or 8 to your pointer to point to the "next thing along". 
+
+In general machines like to store these numbers memory at a place that is 
aligned to their size. That means that bytes (chars) can be stored anywhere as 
the smallest unit when addressing memory is a byte (in general). Shorts want to 
be aligned to 16 bits - that means 2 bytes (chars). So you should (ideally) 
never find a short at an ODD byte in memory. Integers want to be stored on 4 
byte boundaries, Long integers may align to either 4 or 8 bytes depending, and 
long long integers on 8 byt [...]
+
+Note that in addition to memory, CPUs will have "temporary local registers" 
that are directly inside the CPU. They do not have addresses. The compiler will 
use them as temporary scratch space to store data from memory so the CPU can 
work on it. Different CPU types have different numbers and naming of such 
registers. ARM CPUs tend to have more registers than x86 for example.
+
+==== Variables ====
+
+C provides you with a handy "abstraction" to store data in memory. These are 
normally variables. When you first see some C code, you likely see some 
variables and these are stored on the stack. This is a special place in memory 
for such temporary variables and data. It grows and shrinks as needed and has a 
specific order to store data.
+
+Other data is likely on the "heap" and you will explicitly ask it to be there. 
The heap is basically a "big mess of data" where you likely have more permanent 
data or the larger bits of data. C provides some basic methods to ask for this 
storage, where the stack allocation space is generally implicit when you call a 
function.
+
+Variables will live within this memory, and normally the C compiler will deal 
with alignment (especially the stack). You simply say "I want a variable called 
"bob", that is of the type "integer". The type of a variable tells the compiler 
how much memory it should use. The name is how to refer to it in your code.
+
+<code c>
+int bob;
+</code>
+
+You can even tell the compiler to make sure it has an initial value. If you 
don't it's value may be random garbage that was there before in memory.
+
+<code c>
+int bob = 42;
+</code>
+
+Once you have declared a variable, you can now use it. In C the types 
available to you are as follows. Note that 1 byte *IS* 8 bits in size. In real 
life.
+
+^Type      ^Size (bytes) ^Stores                                           ^
+|char      |1            |Integers -128 => 127                             |
+|short     |2            |Integers -32768 => 32767                         |
+|int       |4            |Integers -2 billion => 2 billion (about)         |
+|long      |4 or 8       |Integers -2 billion => 2 billion OR -9 quintillion 
=> 9 quintillion (about) |
+|long long |8            |Integers -9 quintillion => 9 quintillion (about) |
+|float     |4            |Floating point (large range)                     |
+|double    |8            |Floating point (huge range)                      |
+|* **X**   |4 or 8       |Pointer to type **X**                            |
+
+You can group values together in repeating sequences using arrays or in mixed 
groups called "structs".
+
+<code c>
+int bobs[100];
+double things[200];
+</code>
+
+<code c>
+struct mydata
+  {
+     int count;
+     double items[100]
+  };
+
+struct mydata bob;
+</code>
+
+==== Functions ====
+==== Types ====
+==== Arithmetic ====
+==== Logic ====
+==== Loops ====
+----
+==== Memory ====
+==== Libraries ====
+==== API calls ====
+==== System calls ====
+----
+==== Alignment ====
+==== Endianess ====
+==== Function pointers ====
+==== Callbacks ====
+==== Threads ====
+
+=== Also See ===
 
 Now you have read our less-than-perfect primer on C for those wanting to get 
into developing on EFL or using it from the C APIs we have, you may also want 
to look at the following list of pages and pick up some more information or 
fill in the gaps we do not cover here.
 

-- 


Reply via email to