fix spelling

lib/ast/README.md

@@ -54,12 +54,12 @@ The objects the machine works on are:
 
 and working on means, these are the only objects which the machine accesses. Ie all others would have to be moved first.
  
-When a Method needs to make a call, or send a message, it creates a new Message object. 
-Messages contain return addresses and arguemnts.
+When a Method needs to make a call, or send a Message, it creates a NewMessage object. 
+Messages contain return addresses and arguments.
 
-Then the machine must find the method to call. This is a function of the virtual machine an is implemented in ruby.
+Then the machine must find the method to call. This is a function of the virtual machine and is implemented in ruby.
 
-Then a new Method receives the message, creates a Frame for local and temporary variables and continues execution.
+Then a new Method receives the Message, creates a Frame for local and temporary variables and continues execution.
 
 The important thing here is that Messages and Frames are normal objects.
 
@@ -67,8 +67,9 @@ And interestingly we can partly use ruby to find the method, so in a way it is n
 Instead the sending goes back up and then down again.
 
 The Message object is the second parameter to the compile method, the run-time part as it were. Why? Since it only
-exists at runtime: to make compile time analysis possible. Especially for those times when we can resolve the method
-at compile time. (Which is for all vm code)
+exists at runtime: to make compile time analysis possible (it is after all the Virtual version, not Parfait. ie
+compile-time, not run-time). Especially for those times when we can resolve the method
+at compile time.
 
 
 * 

lib/builtin/README.md

@@ -9,7 +9,7 @@ These functions return their code, ie a Virtual::CompiledMethod object, which ca
 as if it were a "normal"  function.
 
 A normal ruby function is one that is parsed and transformed to code. But not all functionality can be written in ruby, 
-one of those chicken and egg things. C uses Assembler in this situation, we use Kernel function.
+one of those chicken and egg things. C uses Assembler in this situation, we use Builtin functions.
 
 Slightly more here : http://salama.github.io/2014/06/10/more-clarity.html (then still called Kernel)
 

lib/elf/README.md

@@ -1,7 +1,8 @@
 Minimal elf support
 ===================
 
-This is really minnimal and works only for our current use case
+This is really minimal and works only for our current use case
+
 - no external functions (all syscalls)
 - only position independant code (no relocation)
 - embedded data (into text), no data section

lib/parfait/README.md

@@ -1,4 +1,6 @@
-### A thin layer
+### Parfait: a thin layer
+
+(not everbody likes onion)
 
 Here we have a placeholder for things i am currently developing. 
 
@@ -15,7 +17,8 @@ not
 
 compile - time
 
-always mixing those up: As such it is not loaded at compile time.
+always mixing those up: As such it is not loaded at compile time. On the other hand, we need to create data
+at compile time that matches the expectation of the code we create..
 
 A step back:  the code (program) we compile runs at run - time. 
 And so does parfait. So all we have to do is compile it with the program.

lib/register/README.md

@@ -3,7 +3,7 @@ Register Machine
 
 This is the logic that uses the compiled virtual object space to produce code and an executable binary.
 
-There is a mechanism for an actual machine (derived class) to generate machine specific instructions (as the 
+There is a mechanism for an actual machine (derived class) to generate harware specific instructions (as the 
 plain ones in this directory don't assemble to binary). Currently there is only the Arm module to actually do
 that.
 
@@ -23,7 +23,7 @@ There are four virtual objects that are accessible (we can access their variable
 - Frame (local and tmp variables)
 - NewMessage ( to build the next message sent)
 
-These are pretty much the first four registers. When the code goes from virtual to register, we use register instrucitons
+These are pretty much the first four registers. When the code goes from virtual to register, we use register instructions
 to replace virtual ones.
 
 Eg: A Virtual::Set can move data around inside those objects. And since in Arm this can not be done in one instruciton,
@@ -31,7 +31,7 @@ we use two, one to move to an unused register and then into the destination. And
 to shift the type info.
 
 Another simple example is a Call. A simple case of a Class function call resolves the class object, and with the
-method name the function to be called at compile-time. And so this results in a Register::Call, which is an Arm 
+method name the function to be found at compile-time. And so this results in a Register::Call, which is an Arm 
 instruction. 
 
 A C call 

lib/virtual/README.md

@@ -5,13 +5,14 @@ This is really an OV (object value) not object oriented machine.
 Integers and References are Values. We make them look like objects, sure, but they are not.
 Symbols have similar properties and those are:
 
-- eqality means identity
-- no chhange over lifetime
+- equality means identity
+- no change over lifetime
 
 It's like with Atoms: they used to be the smallest possible physical unit. Now we have electrons, proton and neutrons.
 And so objects are made up of Values (not objects), integers, floats , references and possibly more.
 
-Values have type in the same way objects have a class. We keep track of the type at runtime.
+Values have type in the same way objects have a class. We keep track of the type of a value at runtime, also in an 
+similar way that objects have their classes at runtime.
 
 ### Layers 
 
@@ -21,12 +22,15 @@ comile the ast layer into Virtual:: objects
 The main objects are BootSpace (lots of objects), BootClass (represents a class), 
 CompiledMethod (with Blocks and Instruction).
 
-*Virtual* Instructions get further transformed into *register* instructions. This is done by an abstractly defined
+**Virtual** Instructions get further transformed into **register** instructions. This is done by an abstractly defined
 Register Machine with basic Intructions. A concrete implementation (like Arm) derives and creates derived
 Instructions.
 
+The transformation is implemented as **passes** to make it easier to understand what is going on. Also this makes it
+easier to add functionality and optimisations from external (to the gem) sources. 
+
 The final transformation assigns Positions to all boot objects (Linker) and assembles them into a binary representation.
-The data- part is then a representation of classes in the *parfait* runtime. And the instrucions make up the 
+The data- part is then a representation of classes in the **parfait** runtime. And the instrucions make up the 
 funtions.
 
 ### Accessible Objects
@@ -46,9 +50,10 @@ The micro-kernel idea is well stated by: If you can leave it out, do.
 
 
 As such we are aiming for integer and reference (type) support, and a minimal class system 
-(object/class/aray/hash/string).
+(object/class/aray/hash/string). It is possible to add types to the system in a similar way as we add classes,
+and also implement very machine dependent functionality which nevertheless is fully wrapped as OO.
 
-*Parfait* is that part of the runtime that can be coded in ruby. It is parsed, like any other code and always included 
-in the resulting binary. Builtin is the part of the runtime that can not be coded in ruby (but is still needed). This
-is coded y construction CompiledMethods in code and neccesarily machine dependant.
+**Parfait** is that part of the runtime that can be coded in ruby. It is parsed, like any other code and always included 
+in the resulting binary. **Builtin** is the part of the runtime that can not be coded in ruby (but is still needed). This
+is coded by construction CompiledMethods in code and neccesarily machine dependant.