There are options in Rust, depending on circumstances and requirements:

Nightly only:

• use of experimental alloc features on nightly Rust
  • access the global allocator https://doc.rust-lang.org/nightly/alloc/alloc/struct.Global.html
  • allows specifying block alignment
  • cross-platform

Stable:

• libc::posix_memalign() (and equivalent on other platforms that I'm not familiar with)
  • https://github.com/jonas-schievink/aligned_alloc.rs
  • allows specifying block alignment
  • platform-specific solutions
• using a Vec as a *mut u8
  • https://github.com/reem/rust-memalloc
  • no way to specify block alignment

First of all, great work on the book, I've been really enjoying reading through it!

I noticed that the implementation of TaggedPtr represents nil as a pointer with a tag of 0. I've also noticed that integers are represented with a tag of 0.

Would this not make a literal 0 be equal to nil, and mean that a zero integer would always be converted to a nil FatPtr (due to this code here )? Not sure if this is an intentional part of the design or not :)

We need a chapter on allocating memory. I'm specifically thinking of bump allocation because:

1. It's super easy to implement
2. It delivers good performance
3. It can support concurrent and atomic operations, though you may still need locking in certain cases (e.g. when requesting a new arena to allocate into)

Book rendering updated on each push: https://pliniker.github.io/book/

What this is:

• a work in progress draft of an online book "Writing Interpreters in Rust: a Guide"
• accompanying source code for an allocator and an interpreter (compiler and virtual machine)
• lots of rough edges:
  • compiler warnings (mostly function X is never called)
  • missing features (mostly language completeness and garbage collection itself)
  • TODOs in the source code
  • likely lots of unidiomatic Rust (I stopped trying to keep up with what is idiomatic and focused on getting something done)
  • very likely a few soundness bugs
  • lots of unoptimized code
  • under-documented code
  • probably some wheel-reinventing that crates out there already solved
  • book is in progress

This is obviously an absurdly large pull request. The history of that is that in the early days there was a lot of churn in my code design (implying a long period where I lacked confidence in my choices) and so by the time the architecture had stabilized there was already quite a lot of code.

Proceeding

My intention is to focus on the book until it is caught up with the source code.

PRs and contributions

If this looks at all interesting to anybody, some questions should be discussed:

1. book license
   • I think this should be some form of Creative Commons but which one?
2. source code license
   • I initially picked MPLv2 because I have some sympathy to copyleft
   • I also recognize that this is a rare choice and there are arguments in favor of more copyleft but possibly even more arguments toward the commonly used MIT/Apache2 in the Rust community. MPLv2 is a middle-way IMO but :man_shrugging:
3. This PR is too big to be sanely reviewed. Options:
   • just accept it, ugly parts and all as something to start from: merge it to base/master and create issues and PRs from there on
   • don't accept it as is, fork this fork and make PRs to it until it's acceptable quality. This could take a long time.

What should this become?

What should the book and code cover, going forward?

• priorites: some roadmap https://github.com/rust-hosted-langs/book/issues
• consider: language and architectural design ideas https://github.com/rust-hosted-langs/runtimes-WG/issues

What I'd like this to be is a repository that somebody can fork and design their own language from, where the builiding blocks are provided. A language design kit, almost. That's a way off though.

See https://github.com/crate-ci/cargo-ghp-upload for more about the ghp-upload tool.

Build will end up at https://rust-hosted-langs.github.io/book/master/.

This requires Travis to have write-access to your repository. The simplest (and reasonably secure) way to achieve this is to create a Persional API Access Token with public_repoo scope. Then on Travis, define the secure environment variable GH_TOKEN with the value being the new token.

If you want to provide more scoped access, you can use a deploy key for repo-specific access. If no token is provided, the script will use SSH to clone from and write to the repository. Travis Pro handles the deploy key automatically, and free users can use Travis encrypt-file plus a script to move the private key into the correct location.

This also means that cargo ghp-upload works locally so long as you have ssh set up for your account. Branch and origin context are collected from Git instead of the CI environment. This means that cargo ghp-upload will work on CI other than Travis, but you currently have to manually prevent it from running on PR builds if you don't wan't it to.

Bob Nystrom's Crafting Interpreters does a great job of explaining concepts with diagrams. Maybe we can do similarly in this book but at this point I'd consider Bob's book as leading into this book.

Included:

• fully functional travis build of docs (thanks @CAD97 !)
• most of #9 with Windows allocation yet to do
• a short section on alignment
• a short section on the type of allocation in Rust terms

https://pliniker.github.io/book/master/index.html https://github.com/pliniker/book/blob/master/blockalloc/src/lib.rs

Hi, thanks for the book It is very helpful.

I don't get the rationale for having a custom allocator though, shouldn't it be explained at the start? Wouldn't default rust allocator be good for this?

See interpreter/src/bytecode.rs:293 - multiple dereferences required to fetch a single opcode.

Ideal state: an instruction pointer that is a pointer to the next opcode.

Realistically: that might not be sensible, given that we probably want to retain bounds checking; what about extending Array with a RefCell-style ArrayOpcode slice borrow? That's as close to bare pointer in safe Rust as we can get.

Files:

• interpreter/src/bytecode.rs:293
• booksrc/chapter-interp-bytecode.md

Originally, Array didn't have runtime-borrow capability and I made the (hasty) decision to base the Array struct on using Cell<RawArray<T>>.

It is clear that it makes far more sense to use RefCell now, both from a semantic and performance basis. The explicit borrowflag can also be removed.

Source: interpreter/src/array.rs:42 Book: booksrc/chapter-interp-arrays.md

This seems wrong. Since these types are just storing word-sized pointers and the behavior we want is to be able to copy them optimally, there should be no other reason why they can't be Copy.

There must be a crate out there that provides Cell mechanics while also being Copy, maybe we need to define our own.