In case you ever wonder what the compiler and bytecode optimizer does
to your code, mzc now supports a `--decompile' mode to convert a ".zo"
file back into Scheme (sort of).
For example, if "ex.ss" contains
#lang scheme
(define x (+ 1 2))
then
laptop% mzc ex.ss
mzc v4.1.0.1 [3m], Copyright (c) 2004-2008 PLT Scheme Inc.
"ex.ss":
making "/private/tmp/ex.ss"
[output to "./compiled/ex_ss.zo"]
laptop% mzc --decompile compiled/ex_ss.zo
mzc v4.1.0.1 [3m], Copyright (c) 2004-2008 PLT Scheme Inc.
(begin (module ex .... (define-values (_x) '3)))
confirms that the compiler knows how to fold `(+ 1 2)' to `3'.
Since the decompiler is intended to help explain performance, its
output includes annotations like `#%sfs-clear' and `#%checked'. Those
annotations are no-ops if you read the code as Scheme, but they reflect
specific steps taken in the JITted form of the bytecode. Similarly,
`lambda' forms are annotated as `#%closed' when they are implemented as
constant closures; otherwise, they're annotated with captured
variables. Primitive operations that will be inlined by the JIT are
annotated with `#%in'. See the mzc documentation for details:
http://docs.plt-scheme.org/mzc/decompile.html
Currently, the decompiler doesn't reconstruct syntax objects, though it
shows a partially-decoded form that can give you a sense of what the
syntax objects contain and how much space they consume. For that and
other reasons, the decompiler's output currently cannot be fed back
into the evaluator.
Matthew