ruby-x/rubyx
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

update readme

Browse Source
This commit is contained in:
Torsten Ruger 2018-07-07 17:34:08 +03:00
parent 2f07cc34f3
commit f2af763f14
3 changed files with 57 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
CNAME
View File

@ -1 +0,0 @@
ruby-x.org

56
README.md
View File

@ -7,14 +7,16 @@
RubyX is about native code generation in and of ruby. RubyX is about native code generation in and of ruby.
In other words, compiling ruby to binary, in ruby. In other words, compiling ruby to binary, in ruby.
X can be read as 10 times faster, or a decade away, depending on mindset. X can be read as X times faster, or a decade away, depending on mindset.
The current (fourth) rewrite adds aims at clarifying the roles of the different layers The last rewrite clarified the roles of the different layers
of the system, see below. The overhaul is almost done. of the system, see below. The overhaul is done and rubyx produces working binaries.
Processing goes through layers: Ruby --> Vool --> Mom --> Risc --> Arm --> binary . Processing goes through layers: Ruby --> Vool --> Mom --> Risc --> Arm --> binary .
Currently most functional constructs work to some (usable) degree, ie if, while,
assignment, ivars, calling and dynamic dispatch all work. Work continues
on blocks currently, see below.
## Layers ## Layers
@ -31,9 +33,8 @@ it has semantics, and those are substantially simpler than ruby.
Vool is Ruby without the fluff. No unless, no reverse if/while, no splats. Just simple Vool is Ruby without the fluff. No unless, no reverse if/while, no splats. Just simple
oo. (Without this level the step down to the next layer was just too big) oo. (Without this level the step down to the next layer was just too big)
Also Vool has a typed syntax tree, unlike the AST from the parser gem. This is easier when Also Vool has a typed syntax tree, unlike the AST from the parser gem. This is easier when writing conversion code: the code goes with the specific class
writing conversion code: the code goes with the specific class (more oo than the visitor (more oo than the visitor pattern, imho)
pattern, imho)
### Mom ### Mom
@ -78,10 +79,28 @@ Generating code (by descending above layers) is only half the story in an oo sys
The other half is classes, types, constant objects and a minimal run-time. This is The other half is classes, types, constant objects and a minimal run-time. This is
what is Parfait is. what is Parfait is.
Parfait has basic clases like string/array/hash, and also anything that is really needed
to express code, ie Class/Type/Method/Block.
Parfait is used at compile time, and the objects get serialised into the executable to
make up, or make up the executable, and are thus available at run time. Currently the
methods are not parsed yet, so do not exist at runtime yet.
### Builtin
There are a small number of methods that can not be coded in ruby. For example an
integer addition, or a instance variable access. These methods exists in any compiler,
and are called builtin here.
Builtin methods are coded at the risc level with a dsl. Even though basically assembler,
they are through the ruby magic quite readable
([see init](https://github.com/ruby-x/rubyx/blob/2f07cc34f3f56c72d05c7d822f40fa6c15fd6a08/lib/risc/builtin/object.rb#L48))
## Types and classes, static vs dynamic ## Types and classes, static vs dynamic
Classes in dynamic languages are open. They can change at any time, meaning you can add/remove Classes in dynamic languages are open. They can change at any time, meaning you can
methods and use any instance variable. This is the reason dynamic languages are interpreted. add/remove methods and use any instance variable. This is the reason dynamic
languages are interpreted.
For Types to make any sense, they have to be static, immutable. For Types to make any sense, they have to be static, immutable.
@ -95,8 +114,7 @@ When a class changes, say a new method is added that uses a new instance variabl
**new** Type is generated to describe the class at that point. **New** code is generated **new** Type is generated to describe the class at that point. **New** code is generated
for this new Type. for this new Type.
In essence the Class always **has a** current Type and **many** Types implement (different In essence the Class always **has a** current Type and **many** Types implement (different versions of) a Class.
versions of) a Class.
All Objects have a Type, as their first member (also integers!). The Type points to the All Objects have a Type, as their first member (also integers!). The Type points to the
Class that the object has in oo terms. Class that the object has in oo terms.
@ -119,7 +137,21 @@ out what is going on, and in finding bugs.
## Status ## Status
Just finishing the rewrite (above architecture) and about to get to binaries again. The above architecture is implemented. At the top level the RubyXCompiler works
pretty much as you'd expect, by falling down the layers. And when it get's
to the Risc layer it slots the builtin in there as if is were just normal code.
Specifically here is a list of what works:
- if (with or without else)
- while
- return
- assignment (local/args/ivar)
- static calling (where method is determined at compile time)
- dynamic dispatch with caching
Current work is on implicit blocks, which are surprisingly like static method calls
and lambdas like dynamic dispatch.
### Stary sky ### Stary sky

28
test/README.md
View File

@ -1,10 +1,10 @@
# Testing # Testing
Testing is off course great, and well practised in the ruby community. Tdd, Bdd , Xdd, whatever you call it, i have come to the point where it
Good tests exists in the parts where functionality is clear: Parsing and binary generation. is a way not only to write software, but to think about software. Ie:
- if it's not tested, we don't know it works
- test first makes me think about the software from the outside. (good perspective)
But it is difficult to write tests when you don't know what the functionality is.
Also TDD does not really help as it assumes you know what you're doing.
I used minitest as the framework, just because it is lighter and thus when the I used minitest as the framework, just because it is lighter and thus when the
time comes to move to rubyx, less work. time comes to move to rubyx, less work.
@ -15,20 +15,18 @@ time comes to move to rubyx, less work.
ruby test/test_all.rb ruby test/test_all.rb
'''' ''''
### Parfait ### Parfait, Risc , Arm , Mom
Well, test Parfait. Not perfect, but growing as bugs appear. Basics are ok though. Follow the directory structure of the source and may be called unit tests
### Compiler ### Risc/Interpreter
Different kinds of quite minimal tests that ensure we can go from parsed to code. Contains many system tests that rely on everything else working.
Should be hoisted i guess.
### Fragments ### Main
Much more elaborate tests of the compling functionality. All code constructs and their output Much like the Interpreter test, but for Arm. This is where the currently few
in terms of instructions are tested. executables are generated and there is an automatic way of running them remotely.
### vm The plan is to integrate this with the interpreter directory
Mostly tests about the Parfait compatibility layer and padding (for assmenbly).
Slightly bad name ... wip