|
John Nunley
d326dc9e99
All checks were successful
ci/woodpecker/pr/test/1 Pipeline was successful
ci/woodpecker/pr/test/2 Pipeline was successful
ci/woodpecker/pr/test/3 Pipeline was successful
ci/woodpecker/pr/test/4 Pipeline was successful
ci/woodpecker/push/test/1 Pipeline was successful
ci/woodpecker/push/test/2 Pipeline was successful
ci/woodpecker/push/test/3 Pipeline was successful
ci/woodpecker/push/test/4 Pipeline was successful
Previously we were using the U_Array structure to handle flexible arrays, which had a number of issues. Namely, the fact that it encodes no type information and is very easy to misuse. This commit replaces it with a new flexible array type. It is represented by "T*", which aims to make it easier to index and iterate through. Signed-off-by: John Nunley <dev@notgull.net> |
||
|---|---|---|
| .woodpecker | ci: Use Dockerfile to pre-install deps | |
| ci | Fix ci/test.sh outputting mega diffs | |
| src | m: Change strategy for flexible arrays | |
| tests | Fix test paths in blocklist | |
| .gitignore | m: Replace typemap with symbol table | |
| .gitmodules | Add and test files in dozer-rustc-1.0.0 submodule | |
| ARCHITECTURE.md | Move byteops/map/util into util/ | |
| build.sh | Do not move libdozerrt.a output | |
| clean.sh | Update build/clean scripts and add CMakeLists.txt ( #28 ) | |
| CMakeLists.txt | Move byteops/map/util into util/ | |
| compile.sh | Update build/clean scripts and add CMakeLists.txt ( #28 ) | |
| LICENSE-APACHE | m: Initial commit | |
| LICENSE-MIT | m: Initial commit | |
| README.md | fix typo | |
dozer
WIP Rust compiler, written in C
Motivation
The goal is to be able to compile an early version of the Rust compiler, without needing to go through the following:
- C++; this is the current canonical bootstrap strategy via
mrustc. This way Rust can be used as a viable bootstrap language for C++.- Note that this means we can't use the LLVM backend, as LLVM is written in C++.
- The entire Rust bootstrap chain starting from OCaml in
rustcv0.7 and going forwards from there. This takes a significant amount of time and we would like to avoid this.
See my blogpost announcing Dozer for more information.
Goals
As part of this goal dozer should be able to be compiled with very simple C
compilers, like TinyCC and cproc. Care should be taken to avoid more
complicated GNU extensions.
Eventually I would like the compiler to be able to compile an earlier version of
rustc. I hope that it is possible to compile a version of rustc that
supports the Cranelift backend, but this may be infeasible with a simple
compiler. So for now we are targeting rustc v1.0.
Build
The build process for dozer aims to be very simple. We don't even use a
Makefile, just to open the door to the possibility that make could be
implemented in Rust. We only assume that we have a C compiler (which depends on
an assembler, archiver and linker) as well as a very basic scripting tool (at
the moment we are targeting kaem).
Thankfully kaem scripts are POSIX-shell compatible, so we can just use
bash to run the build script.
$ bash build.sh
This script builds three important targets:
dozer, the bootstrap compiler.dozer-qbe, the QBE backend for Dozer's intermediate language.libdozerrt.a, a small runtime that is linked into programs compiled with Dozer.
Running
Note: dozer is still in an early state so the command line interface is heavily subject to change.
To compile a Rust program, call Dozer with the path to the root Rust module and the path to the output file.
$ ./dozer hello.rs hello.nhad
The "nhad" file contains metadata and bytecode for the compiled program. Use
dozer-qbe to strip metadata and translate the bytecode to QBE IR.
$ ./dozer-qbe hello.nhad > hello.qbe
At this point QBE and the system C compiler can be used to translate the QBE
IR to an executable. Make sure that libdozerrt.a is linked into the final
executable.
$ qbe hello.qbe > hello.S
$ cc hello.S ./src/libdozerrt.a -o hello
Things left to do
- The parser is still incomplete. Expanding the parser is probably the lowest-hanging fruit for new contributors.
- We only support typechecking and emitting basic
i32operations. We need to be able to support more of Rust.- My current plan is to "eat the frog" and get trait resolution working as soon as possible, as most of Rust's language features require traits to work.
- The rest of the owl.
License
MIT/Apache2