diff options
Diffstat (limited to 'doc/ref/compiler.texi')
-rw-r--r-- | doc/ref/compiler.texi | 80 |
1 files changed, 49 insertions, 31 deletions
diff --git a/doc/ref/compiler.texi b/doc/ref/compiler.texi index bfc633e57..0615ef78a 100644 --- a/doc/ref/compiler.texi +++ b/doc/ref/compiler.texi @@ -1,6 +1,6 @@ @c -*-texinfo-*- @c This is part of the GNU Guile Reference Manual. -@c Copyright (C) 2008, 2009, 2010, 2013 +@c Copyright (C) 2008, 2009, 2010, 2011, 2012, 2013 @c Free Software Foundation, Inc. @c See the file guile.texi for copying conditions. @@ -161,12 +161,11 @@ different worlds indefinitely, as shown by the following quine: @node The Scheme Compiler @subsection The Scheme Compiler -The job of the Scheme compiler is to expand all macros and all of -Scheme to its most primitive expressions. The definition of -``primitive'' is given by the inventory of constructs provided by -Tree-IL, the target language of the Scheme compiler: procedure -applications, conditionals, lexical references, etc. This is described -more fully in the next section. +The job of the Scheme compiler is to expand all macros and all of Scheme +to its most primitive expressions. The definition of ``primitive'' is +given by the inventory of constructs provided by Tree-IL, the target +language of the Scheme compiler: procedure calls, conditionals, lexical +references, etc. This is described more fully in the next section. The tricky and amusing thing about the Scheme-to-Tree-IL compiler is that it is completely implemented by the macro expander. Since the @@ -184,10 +183,10 @@ The Scheme-to-Tree-IL expander may be invoked using the generic @lisp (compile '(+ 1 2) #:from 'scheme #:to 'tree-il) @result{} - #<<application> src: #f - proc: #<<toplevel-ref> src: #f name: +> - args: (#<<const> src: #f exp: 1> - #<<const> src: #f exp: 2>)> + #<<call> src: #f + proc: #<<toplevel-ref> src: #f name: +> + args: (#<<const> src: #f exp: 1> + #<<const> src: #f exp: 2>)> @end lisp Or, since Tree-IL is so close to Scheme, it is often useful to expand @@ -342,9 +341,9 @@ instruction. Compilation of Tree-IL usually begins with a pass that resolves some @code{<module-ref>} and @code{<toplevel-ref>} expressions to -@code{<primitive-ref>} expressions. The actual compilation pass -has special cases for applications of certain primitives, like -@code{apply} or @code{cons}. +@code{<primitive-ref>} expressions. The actual compilation pass has +special cases for calls to certain primitives, like @code{apply} or +@code{cons}. @end deftp @deftp {Scheme Variable} <lexical-ref> src name gensym @deftpx {External Representation} (lexical @var{name} @var{gensym}) @@ -388,10 +387,19 @@ Defines a new top-level variable in the current procedure's module. @deftpx {External Representation} (if @var{test} @var{then} @var{else}) A conditional. Note that @var{else} is not optional. @end deftp -@deftp {Scheme Variable} <application> src proc args -@deftpx {External Representation} (apply @var{proc} . @var{args}) +@deftp {Scheme Variable} <call> src proc args +@deftpx {External Representation} (call @var{proc} . @var{args}) A procedure call. @end deftp +@deftp {Scheme Variable} <primcall> src name args +@deftpx {External Representation} (primcall @var{name} . @var{args}) +A call to a primitive. Equivalent to @code{(call (primitive @var{name}) +. @var{args})}. This construct is often more convenient to generate and +analyze than @code{<call>}. + +As part of the compilation process, instances of @code{(call (primitive +@var{name}) . @var{args})} are transformed into primcalls. +@end deftp @deftp {Scheme Variable} <sequence> src exps @deftpx {External Representation} (begin . @var{exps}) Like Scheme's @code{begin}. @@ -468,12 +476,15 @@ expression evaluating to a fluid. A dynamic variable set. @var{fluid}, a Tree-IL expression evaluating to a fluid, will be set to the result of evaluating @var{exp}. @end deftp -@deftp {Scheme Variable} <dynwind> winder body unwinder -@deftpx {External Representation} (dynwind @var{winder} @var{body} @var{unwinder}) +@deftp {Scheme Variable} <dynwind> winder pre body post unwinder +@deftpx {External Representation} (dynwind @var{winder} @var{pre} @var{body} @var{post} @var{unwinder}) A @code{dynamic-wind}. @var{winder} and @var{unwinder} should both -evaluate to thunks. Ensure that the winder and the unwinder are called -before entering and after leaving @var{body}. Note that @var{body} is -an expression, without a thunk wrapper. +evaluate to thunks. Ensure that the winder and the unwinder are called +before entering and after leaving @var{body}. Note that @var{body} is +an expression, without a thunk wrapper. Guile actually inlines the +bodies of @var{winder} and @var{unwinder} for the case of normal control +flow, compiling the expressions in @var{pre} and @var{post}, +respectively. @end deftp @deftp {Scheme Variable} <prompt> tag body handler @deftpx {External Representation} (prompt @var{tag} @var{body} @var{handler}) @@ -509,7 +520,7 @@ Like Scheme's @code{receive} -- binds the values returned by evaluating @code{exp} to the @code{lambda}-like bindings described by @var{gensyms}. That is to say, @var{gensyms} may be an improper list. -@code{<let-values>} is an optimization of @code{<application>} of the +@code{<let-values>} is an optimization of a @code{<call>} to the primitive, @code{call-with-values}. @end deftp @deftp {Scheme Variable} <fix> src names gensyms vals body @@ -792,29 +803,36 @@ objcode)} module. Returns @code{#f} if @var{obj} is object code, @code{#f} otherwise. @end deffn -@deffn {Scheme Procedure} bytecode->objcode bytecode +@deffn {Scheme Procedure} bytecode->objcode bytecode [endianness] @deffnx {C Function} scm_bytecode_to_objcode (bytecode) Makes a bytecode object from @var{bytecode}, which should be a -bytevector. @xref{Bytevectors}. +bytevector. @xref{Bytevectors}. By default, the embedded length fields +in the bytevector are interpreted in the native byte order. @end deffn -@deffn {Scheme Variable} load-objcode file -@deffnx {C Function} scm_load_objcode (file) +@deffn {Scheme Variable} load-thunk-from-file file +@deffnx {C Function} scm_load_thunk_from_file (file) Load object code from a file named @var{file}. The file will be mapped into memory via @code{mmap}, so this is a very fast operation. -On disk, object code has an sixteen-byte cookie prepended to it, to -prevent accidental loading of arbitrary garbage. +On disk, object code is embedded in ELF, a flexible container format +created for use in UNIX systems. Guile has its own ELF linker and +loader, so it uses the ELF format on all systems. @end deffn @deffn {Scheme Variable} write-objcode objcode file @deffnx {C Function} scm_write_objcode (objcode) -Write object code out to a file, prepending the sixteen-byte cookie. +Embed object code into an ELF container, and write it out to a file. + +This procedure is part of a separate module, @code{(language objcode +elf)}. @end deffn -@deffn {Scheme Variable} objcode->bytecode objcode +@deffn {Scheme Variable} objcode->bytecode objcode [endianness] @deffnx {C Function} scm_objcode_to_bytecode (objcode) -Copy object code out to a bytevector for analysis by Scheme. +Copy object code out to a bytevector for analysis by Scheme. By +default, the length fields in the @code{struct scm_objcode} are +interpreted in the native byte order. @end deffn The following procedure is actually in @code{(system vm program)}, but |