Looking for VM / bytecode docs

49 views
Skip to first unread message

Joshua Judson Rosen

unread,
Nov 7, 2019, 1:46:21 AM11/7/19
to d...@racket-lang.org
Hi,

I'm trying to learn about Racket's bytecode and VM (after skimming through the docs,
I guess I'm specifically interested in the "3m" VM and the "zo" bytecode?).

Trying to find answers to questions like "is it a stack-machine, a register-machine...,
something else?"; "what are the bytecode operators and their operands";
"what sort of verification is done while loading bytecode"....

I've been a longtime user of Guile and have recently started reading through
Guile's VM documentation, and ideally I'm trying to find something similar to this
but for Racket:

https://www.gnu.org/software/guile/manual/html_node/A-Virtual-Machine-for-Guile.html

Does such a thing exist?

If not, could someone perhaps give me some specific advice as to where in the code
I should look to find this info?


--
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."

Matthew Flatt

unread,
Nov 7, 2019, 8:08:35 AM11/7/19
to Joshua Judson Rosen, d...@racket-lang.org
This paper provides the only high-level description of bytecode and the
VM that I can remember:

https://plt.eecs.northwestern.edu/racket-machine/

The `compiler/zo-structs` library and its documentation in effect
describe the bytecode content (but not its encoding). "Bytecode" is
fairly close to expanded Racket --- so much that `compiler/decompile`
can reconstruct a good facsimile of bytecode in expanded form, and
looking at the implementation of `cmopiler/decompile` might be helpful.

The start of "eval.c" in the implementation provides an overview of
compiler passes, but that might not be quite what you're looking for.
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-dev+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-dev/c9b29384-df5e-72fc-5ff9-5bd64418b0
> 06%40geekspace.com.

Matthias Felleisen

unread,
Nov 7, 2019, 8:55:44 AM11/7/19
to Joshua Judson Rosen, dev, Matthew Flatt

Also consider using Ben’s package: 


— Matthias




Joshua Judson Rosen

unread,
Nov 7, 2019, 10:38:27 AM11/7/19
to Matthew Flatt, d...@racket-lang.org
On 11/7/19 8:08 AM, Matthew Flatt wrote:
> This paper provides the only high-level description of bytecode and the
> VM that I can remember:
>
> https://plt.eecs.northwestern.edu/racket-machine/
>
> The `compiler/zo-structs` library and its documentation in effect
> describe the bytecode content (but not its encoding). "Bytecode" is
> fairly close to expanded Racket --- so much that `compiler/decompile`
> can reconstruct a good facsimile of bytecode in expanded form, and
> looking at the implementation of `cmopiler/decompile` might be helpful.

A bit--that's where I started, actually; so that's confirmation that I'm looking
in the right place ;)

I also had found that "The Racket Virtual Machine and Randomized Testing" essay--
the big question there, after skimming and scanning, was basically to what extent
that depiction of Racket is still accurate (I didn't see a date in the paper itself,
but I gathered from that the accompanying README said "known to work with Racket v5.0.2",
and that the timestamps in the tarball were from 2010, that it's just shy of a decade old).

I'm reading your response as indicating that the only changes in the VM
over the last decade have basically been bugfixes and maybe performance-improvements--
that the type of bytecode and interpretation basically haven't changed since you worked
on that paper.

So, that's interesting.

> The start of "eval.c" in the implementation provides an overview of
> compiler passes, but that might not be quite what you're looking for.

It does look useful, thanks.

I'll have to finish reading that paper now.

At a glance though, it looks/sounds like the bytecode is largely just a sort
of `compact binary s-expression syntax', and the interpreter is a classic eval/apply tree-interpreter?
Is that a fair overview?

Philip McGrath

unread,
Nov 7, 2019, 5:23:26 PM11/7/19
to Joshua Judson Rosen, Matthew Flatt, d...@racket-lang.org
On Thu, Nov 7, 2019 at 10:38 AM Joshua Judson Rosen <rozzin...@hackerposse.com> wrote:
I also had found that "The Racket Virtual Machine and Randomized Testing" essay--
the big question there, after skimming and scanning, was basically to what extent
that depiction of Racket is still accurate (I didn't see a date in the paper itself,
but I gathered from that the accompanying README said "known to work with Racket v5.0.2",
and that the timestamps in the tarball were from 2010, that it's just shy of a decade old).

I'm reading your response as indicating that the only changes in the VM
over the last decade have basically been bugfixes and maybe performance-improvements--
that the type of bytecode and interpretation basically haven't changed since you worked
on that paper.

I don't know enough to comment on the bigger picture, but I remembered Matthew's announcement from 2018 (https://groups.google.com/d/topic/racket-dev/UTCAA_wPkc4/discussion) that the bytecode validator was being retired.

-Philip
Reply all
Reply to author
Forward
0 new messages