went over the various readmes

This commit is contained in:
Torsten Ruger 2015-10-07 11:32:48 +03:00
parent 88fc4c0e47
commit e669489419
7 changed files with 57 additions and 42 deletions

View File

@ -6,6 +6,7 @@ standard blah applies (ie RoboCop stuff).
## Formatting
### Line Length
While the days of 80 are over, too big steps seems difficult. I've settled on 100 (ish)
### Hash
@ -17,7 +18,7 @@ I still prefer 1.9 => style , it makes the association more obvious.
### Module functions are global
Often one thinks so much in classes that classes get what are basically global functions.
Global functions are usually meant for a module, so mmodule scope is fitting.
Global functions are usually meant for a module, so module scope is fitting.
A perfect example are singleton accessors. These are often found clumsily on the classes but
the code reads much nicer when they are on the module.
@ -33,4 +34,4 @@ out of the Instructions classes. In such cases Module functions are again quite
Instead of GetSlot.new( register, index , register) we use Register.get_slot( name , name , name).
All names are resolved to registers, or index via Layout. More readable code less repetition.
As the exmple shows, in this case the module function name should be the instruction class name.
As the example shows, in this case the module function name should be the instruction class name.

View File

@ -9,13 +9,25 @@ Salama is about native code generation in and of ruby.
It is probably best to read the [The Book](http://dancinglightning.gitbooks.io/the-object-machine/content/) first.
Currently the work is to get the system to bootstrap, ie produce and executable that does what the ruby code says.
The current third rewrite adds a system language, with the idea of compiling ruby to that language, bosl.
The original ruby parser has been remodelled to parse bosl and later we will use whitequarks
parser to parse ruby. Then it will be ruby --> bosl --> assembler --> binary .
Later that executable needs to extend itself, but to do so it will be able to use the same code.
## Done
Some things that are finished (for *a* definition of finished, ie started)
Some things that are finished (for *a* definition of finished, ie started)
### Interpreter
After doing some debugging on the generated binaries i opted to write an interpreter for the
register layer. That way test runs on the interpreter reveal most issues.
### Debugger
And after the interpreter was done, i wrote a [visual debugger](https://github.com/salama/salama-debugger).
It is a simple opal application that nevertheless has proven great help both in figuring out
what is going on, and in finding bugs.
### Assembly
@ -57,15 +69,16 @@ As said, "Hello world" comes out and does use syscall 4.
Also the program stops by syscall exit.
The full list is on the net and involves mostly just work.
### Parse ruby
### Parse Bosl
Parse simple code, using Parslet. This has been separated out as it's own gem, [salama-reader](https://github.com/salama/salama-reader).
Parse bosl, using Parslet. This has been separated out as it's own gem, [salama-reader](https://github.com/salama/salama-reader).
Parsing is a surprisingly fiddly process, very space and order sensitive. But Parslet is great and
simple expressions (including function definitions and calls) are starting to work.
Bosl is now fully typed (all variables, arguments and return). Also it has statements, unlike ruby
where everything is an expressions. Statements have no value. Otherwise it is quite basic, and
it's main purpose is to have an oo system language to compile to.
I spent some time on the parse testing framework, so it is safe to fiddle and add.
In fact it is very modular and so ot is easy to add.
In fact it is very modular and easy to add to.
### Virtual: Compile the Ast
@ -75,11 +88,6 @@ For the parsed subset that's almost done.
It took me a while to come up with a decent but simple machine model. I had tried to map straight to hardware
but failed. The current Virtual directory represent a machine with basic oo features.
Instead of having more Layers to go from virtual to arm, i opted to have passes that go over the data structure
and modify it.
This allows optimization after every pass as we have a data structure at every point in time.
### Parfait - the runtime
After an initial phase where i aimed for a **really** really small run-time, i have now started to
@ -92,30 +100,19 @@ inlining, but i have at least an idea.
### Sof
**S**alama **O**bject **F**ile format is a yaml like format to look at code dumps and help testing.
Salama Object File format is a yaml like format to look at code dumps and help testing.
The dumper is ok and does produce (as intended) considerably denser dumps than yaml
When a reader is done (not started) the idea is to use sof as pre-compiled, language independent
exchange format, have the core read that, and use the mechanism to achieve language independence.
## Status - Dynmaic function lookup
## Status
It proved to be quite a big step to go from static function calling to oo method lookup.
Also ruby is very introspective and that means much of the compiled code needs to be accessible
in the runtime (not just present, accessible).
Currently all the work is on the bosl front. Also documenting the *small* change of a new language.
This has taken me the better part of a year, but is starting to come around.
I'll do some simple string and fibo examples in bosl next.
So the current status is that i can
- parse a usable subset of ruby
- compile that to my vm model
- generate assembler for all higher level constructs in the vm model
- assemble and link the code and objects (strings/arrays/hashes) into an executable
- run the executable and debug :-(
PS: the current current status (05/15) is that even that is broken as i am reworking the run-time.
But i am hopefull.
Next will be the multiple return feature and then to try to compile ruby to bosl.
## Future

View File

@ -67,12 +67,12 @@ Messages contain return addresses (yes, plural) and arguments.
The important thing here is that Messages and Frames are normal objects.
### Distinclty future proof
### Distinctly future proof
Bosl is designed to be used as an implementation language for a higher oo language. Some, or
even many, features may not make sense on their own. But these features, like several return
addresses are important to implement the higher language.
addresses, are important to implement the higher language.
In fact, Bosl main purpose is not even to be written. The main purpose is to have a language to
In fact, Bosl's main purpose is not even to be written. The main purpose is to have a language to
compile ruby to. In the same way that the assembler layer in salama is not designed to be written,
we just need it to create our layers.

View File

@ -11,9 +11,9 @@ I was close to going the wilson way, ie assmble, load into memory and jump
But it is nice to produce executables. Also easier to test, what with segfaults and such.
Executalbe files are not supported (yet?), but object files work. So the only thing that remains is to
Executable files are not supported (yet?), but object files work. So the only thing that remains is to
call the linker on the produced object file. The resulting file is an executable that actually works!!
Thanks to Mikko for starting this arm/elf project in the first place: https://github.com/cyndis/as
This part definately needs tlc, so anyone who is interested, dig in!
This part definitely needs tlc, so anyone who is interested, dig in!

View File

@ -1,7 +1,7 @@
### Parfait: a thin layer
Parfait is the run-time of the **vm**.
To be more precise, it is that part of the run-time that can be expressed in ruby.
To be more precise, it is that part of the run-time needed to boot ruby.
The run-time needs to contain quite a lot of functionality for a dynamic system.
And a large part of that functionality must actually be used at compile time too.
@ -53,7 +53,7 @@ Parfait is not the language (ie ruby) core library. Core library functionality d
languages and so the language core lib must be on top of the vm parfait.
To make this point clear, i have started using different names for the core classes. Hopefully
more sensible ones, ie List instead of Array, Dictionary instead of Hash.
more sensible ones, ie List instead of Array, Dictionary instead of Hash.
Also Parfait is meant to be as thin as humanly possibly, so extra (nice to have) functionality
will be in future modules.

View File

@ -16,3 +16,9 @@ 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)
The Builtin module is scattered into several files, but that is just so the file doesn't get too long.
Note: This is about to change slightly with the arrival of Bosl. Bosl is a lower level function,
and as such there is not much that we need that can not be expressed in it. My current thinking
is that i can code anything in bosl and will only need the bosl instruction set.
So this whole Builtin approach may blow over in the next months. It had already become clear that
mostly this was going to be about memory access, which in bosl is part of the language.

View File

@ -15,9 +15,20 @@ time comes to move to salama, less work.
ruby test/test_all.rb
''''
### Parfait
Well, test Parfait. Not perfect, but growing as bugs appear. Basics are ok though.
### Compiler
Different kinds of quite minimal tests that ensure we can go from parsed to code.
### Fragments
Much more elaborate tests of the compling functionality. All code constructs and their output
in terms of instructions are tested.
### vm
As this is all quite new, i tend to test only when i know that the functionality will stay that way.
Otherwise it's just too much effort to rewrite and rewrite the tests.
There used to be better tests, but rewrites bring fluctuation, so poke around and make suggestion :-)
Mostly tests about the Parfait compatibility layer and padding (for assmenbly).
Slightly bad name ... wip