Browse files

updates readme file

  • Loading branch information...
1 parent 50f5bc8 commit a0f3dbdcb16bba74df692dcc034dbcfe4bebb6d5 @jeremytregunna committed Jan 22, 2012
Showing with 28 additions and 36 deletions.
  1. +28 −11 README.mdown
  2. +0 −25 bootstrap/README.mdown
39 README.mdown
@@ -19,12 +19,34 @@ priority at this stage of development.
## Phases
-Acute will be (but presently is not) self hosting. A small bootstrap is being built which will provide a basic object model, some basic
-types and of course, emit LLVM IR so we can produce a binary. We do this, so we can build our full vm, which will, in turn, compile
-itself and emit LLVM IR to replace the bootstrap. So long as this version is able to compile itself, and we can generate the LLVM IR,
-then we have all we need to produce an executable. Of course, the final vm will have to be able to compile itself first.
+Acute is bootstrapped so that we can write the language in ourself. While it's true, we could just use (Steve Dekorte's IoVM](
+that was seen as less than ideal (dependent on another Io implementation is not a good starting point IMO).
+Acute is built in stages, the bootstrap lives at the bottom of the stack, for now. I'll discuss the different parts below.
+### Caribou
+Caribou is the virtual machine that presently does not exist. However, when it does, its job will be to handle providing critical subsystems, such as
+the garbage collector, object space, the low level object model itself, and the JIT primitive operations.
+### Wee
+Wee is the bootstrap interpreter. All of acute is executed through it at some level. While this is not optimal long term, the long term plans involve
+separating wee out strictly for compilation help, and adding a virtual machine below it.
+Wee is responsible for interpreting code, building an AST, exposing an API through which further layers can deal with, and basically allowing us to
+write the whole system in itself.
+### Platform
+The platform subsystem provides platform agnostic APIs around the low level primitives where appropriate. It will also be responsible at some point
+in the future, for providing a foreign function interface to Acute.
+### stdlib
+This subsystem, as its name suggests is responsible for loading the standard library. These are the APIs that programs should execute. By the time
+this subsystem is loaded, it is ready for evaluating programs.
-More information about the bootstrap can be found in the bootstrap directory, including source code.
## License
@@ -58,9 +80,4 @@ There are a few things we'd like you to respect though:
1. Develop your feature in a separate branch that I can pull into my repo. Don't clobber the `master` branch. It's the stable branch;
2. We want to keep a uniform license. As such, by contributing code to us, you are granting us license to distribute your changes under
-the terms of the MIT license, as found above; and
-3. If your code isn't completely done yet, it's ok to open a pull request. Just be sure to clearly note that it is incomplete and
-shouldn't be merged into the mainline. I test these things out beforehand, but still; be respectful of others who may want your feature
-4. Please include tests. Included is [a fork]( of [Jonathan Wright's iospec2](
-It's not the most complete BDD tool out there, but I'll make it better as needed, please do the same.
+the terms of the MIT license, as found above; and
25 bootstrap/README.mdown
@@ -1,25 +0,0 @@
-# Bootstrap compiler
-Acute is bootstrapped so that we can write the language in ourself. While it's true, we could just use (Steve Dekorte's IoVM](
-that was seen as less than ideal. No LLVM bindings exist presently, and while I did start writing some, it just seemed silly.
-The truth of the matter is we can build an IoVM fairly easily, and as such, the cost/benefit of using someone elses VM versus building
-our own, is high. As such, the choice is clear. As an example, the core bootstrap written in Ruby is 150 lines of code. Yes, one hundred and fifty. That supports the entire object model including messages, closures, slots and objects.
-We build the Ruby version to build the full IoVM. The full IoVM will be a binary which can be used to build another full IoVM which
-should generate the same code as the previous version. Thus, we can visualize this as a flow chart:
-Ruby bootstrap -> Full IoVM
- |
- ---> Full IoVM
- |
- ---> Full IoVM
-and so on. We need to make sure that we build a binary that is executable on your system so that we don't need another interpreter to
-run the full IoVM with.
-So those are the goals of our bootstrapping process.
-The result of the full vm compiling itself will be LLVM IR which will replace the bootstrap. You can find this generated code (if it
-exists at the time you read this) in the **llvm** subdirectory. For historical purposes, we'll leave the Ruby bootstrap kicking around in
-the **rb** directory.

0 comments on commit a0f3dbd

Please sign in to comment.