Source

emacs / lispref / compile.texi

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
@c -*-texinfo-*-
@c This is part of the GNU Emacs Lisp Reference Manual.
@c Copyright (C) 1990, 1991, 1992, 1993, 1994 Free Software Foundation, Inc. 
@c See the file elisp.texi for copying conditions.
@setfilename ../info/compile
@node Byte Compilation, Advising Functions, Loading, Top
@chapter Byte Compilation
@cindex byte-code
@cindex compilation

  Emacs Lisp has a @dfn{compiler} that translates functions written
in Lisp into a special representation called @dfn{byte-code} that can be
executed more efficiently.  The compiler replaces Lisp function
definitions with byte-code.  When a byte-code function is called, its
definition is evaluated by the @dfn{byte-code interpreter}.

  Because the byte-compiled code is evaluated by the byte-code
interpreter, instead of being executed directly by the machine's
hardware (as true compiled code is), byte-code is completely
transportable from machine to machine without recompilation.  It is not,
however, as fast as true compiled code.

  Compiling a Lisp file with the Emacs byte compiler always reads the
file as multibyte text, even if Emacs was started with @samp{--unibyte},
unless the file specifies otherwise.  This is so that compilation gives
results compatible with running the same file without compilation.
@xref{Loading Non-ASCII}.

  In general, any version of Emacs can run byte-compiled code produced
by recent earlier versions of Emacs, but the reverse is not true.  A
major incompatible change was introduced in Emacs version 19.29, and
files compiled with versions since that one will definitely not run
in earlier versions unless you specify a special option.
@iftex
@xref{Docs and Compilation}.
@end iftex
In addition, the modifier bits in keyboard characters were renumbered in
Emacs 19.29; as a result, files compiled in versions before 19.29 will
not work in subsequent versions if they contain character constants with
modifier bits.

  @xref{Compilation Errors}, for how to investigate errors occurring in
byte compilation.

@menu
* Speed of Byte-Code::          An example of speedup from byte compilation.
* Compilation Functions::       Byte compilation functions.
* Docs and Compilation::        Dynamic loading of documentation strings.
* Dynamic Loading::             Dynamic loading of individual functions.
* Eval During Compile::  	Code to be evaluated when you compile.
* Byte-Code Objects::		The data type used for byte-compiled functions.
* Disassembly::                 Disassembling byte-code; how to read byte-code.
@end menu

@node Speed of Byte-Code
@section Performance of Byte-Compiled Code

  A byte-compiled function is not as efficient as a primitive function
written in C, but runs much faster than the version written in Lisp.
Here is an example:

@example
@group
(defun silly-loop (n)
  "Return time before and after N iterations of a loop."
  (let ((t1 (current-time-string)))
    (while (> (setq n (1- n)) 
              0))
    (list t1 (current-time-string))))
@result{} silly-loop
@end group

@group
(silly-loop 100000)
@result{} ("Fri Mar 18 17:25:57 1994"
    "Fri Mar 18 17:26:28 1994")  ; @r{31 seconds}
@end group

@group
(byte-compile 'silly-loop)
@result{} @r{[Compiled code not shown]}
@end group

@group
(silly-loop 100000)
@result{} ("Fri Mar 18 17:26:52 1994"
    "Fri Mar 18 17:26:58 1994")  ; @r{6 seconds}
@end group
@end example

  In this example, the interpreted code required 31 seconds to run,
whereas the byte-compiled code required 6 seconds.  These results are
representative, but actual results will vary greatly.

@node Compilation Functions
@comment  node-name,  next,  previous,  up
@section The Compilation Functions
@cindex compilation functions

  You can byte-compile an individual function or macro definition with
the @code{byte-compile} function.  You can compile a whole file with
@code{byte-compile-file}, or several files with
@code{byte-recompile-directory} or @code{batch-byte-compile}.

  The byte compiler produces error messages and warnings about each file
in a buffer called @samp{*Compile-Log*}.  These report things in your
program that suggest a problem but are not necessarily erroneous.

@cindex macro compilation
  Be careful when writing macro calls in files that you may someday
byte-compile.  Macro calls are expanded when they are compiled, so the
macros must already be defined for proper compilation.  For more
details, see @ref{Compiling Macros}.

  Normally, compiling a file does not evaluate the file's contents or
load the file.  But it does execute any @code{require} calls at top
level in the file.  One way to ensure that necessary macro definitions
are available during compilation is to require the file that defines
them (@pxref{Named Features}).  To avoid loading the macro definition files
when someone @emph{runs} the compiled program, write
@code{eval-when-compile} around the @code{require} calls (@pxref{Eval
During Compile}).

@defun byte-compile symbol
This function byte-compiles the function definition of @var{symbol},
replacing the previous definition with the compiled one.  The function
definition of @var{symbol} must be the actual code for the function;
i.e., the compiler does not follow indirection to another symbol.
@code{byte-compile} returns the new, compiled definition of
@var{symbol}.

  If @var{symbol}'s definition is a byte-code function object,
@code{byte-compile} does nothing and returns @code{nil}.  Lisp records
only one function definition for any symbol, and if that is already
compiled, non-compiled code is not available anywhere.  So there is no
way to ``compile the same definition again.''

@example
@group
(defun factorial (integer)
  "Compute factorial of INTEGER."
  (if (= 1 integer) 1
    (* integer (factorial (1- integer)))))
@result{} factorial
@end group

@group
(byte-compile 'factorial)
@result{}
#[(integer)
  "^H\301U\203^H^@@\301\207\302^H\303^HS!\"\207"
  [integer 1 * factorial]
  4 "Compute factorial of INTEGER."]
@end group
@end example

@noindent
The result is a byte-code function object.  The string it contains is
the actual byte-code; each character in it is an instruction or an
operand of an instruction.  The vector contains all the constants,
variable names and function names used by the function, except for
certain primitives that are coded as special instructions.
@end defun

@deffn Command compile-defun
This command reads the defun containing point, compiles it, and
evaluates the result.  If you use this on a defun that is actually a
function definition, the effect is to install a compiled version of that
function.
@end deffn

@deffn Command byte-compile-file filename
This function compiles a file of Lisp code named @var{filename} into a
file of byte-code.  The output file's name is made by changing the
@samp{.el} suffix into @samp{.elc}; if @var{filename} does not end in
@samp{.el}, it adds @samp{.elc} to the end of @var{filename}.

Compilation works by reading the input file one form at a time.  If it
is a definition of a function or macro, the compiled function or macro
definition is written out.  Other forms are batched together, then each
batch is compiled, and written so that its compiled code will be
executed when the file is read.  All comments are discarded when the
input file is read.

This command returns @code{t}.  When called interactively, it prompts
for the file name.

@example
@group
% ls -l push*
-rw-r--r--  1 lewis     791 Oct  5 20:31 push.el
@end group

@group
(byte-compile-file "~/emacs/push.el")
     @result{} t
@end group

@group
% ls -l push*
-rw-r--r--  1 lewis     791 Oct  5 20:31 push.el
-rw-rw-rw-  1 lewis     638 Oct  8 20:25 push.elc
@end group
@end example
@end deffn

@deffn Command byte-recompile-directory directory flag
@cindex library compilation
This function recompiles every @samp{.el} file in @var{directory} that
needs recompilation.  A file needs recompilation if a @samp{.elc} file
exists but is older than the @samp{.el} file.

When a @samp{.el} file has no corresponding @samp{.elc} file, @var{flag}
says what to do.  If it is @code{nil}, these files are ignored.  If it
is non-@code{nil}, the user is asked whether to compile each such file.

The returned value of this command is unpredictable.
@end deffn

@defun batch-byte-compile
This function runs @code{byte-compile-file} on files specified on the
command line.  This function must be used only in a batch execution of
Emacs, as it kills Emacs on completion.  An error in one file does not
prevent processing of subsequent files, but no output file will be
generated for it, and the Emacs process will terminate with a nonzero
status code.

@example
% emacs -batch -f batch-byte-compile *.el
@end example
@end defun

@defun byte-code code-string data-vector max-stack
@cindex byte-code interpreter
This function actually interprets byte-code.  A byte-compiled function
is actually defined with a body that calls @code{byte-code}.  Don't call
this function yourself---only the byte compiler knows how to generate
valid calls to this function.

In Emacs version 18, byte-code was always executed by way of a call to
the function @code{byte-code}.  Nowadays, byte-code is usually executed
as part of a byte-code function object, and only rarely through an
explicit call to @code{byte-code}.
@end defun

@node Docs and Compilation
@section Documentation Strings and Compilation
@cindex dynamic loading of documentation

  Functions and variables loaded from a byte-compiled file access their
documentation strings dynamically from the file whenever needed.  This
saves space within Emacs, and makes loading faster because the
documentation strings themselves need not be processed while loading the
file.  Actual access to the documentation strings becomes slower as a
result, but this normally is not enough to bother users.

  Dynamic access to documentation strings does have drawbacks:

@itemize @bullet
@item
If you delete or move the compiled file after loading it, Emacs can no
longer access the documentation strings for the functions and variables
in the file.

@item
If you alter the compiled file (such as by compiling a new version),
then further access to documentation strings in this file will give
nonsense results.
@end itemize

  If your site installs Emacs following the usual procedures, these
problems will never normally occur.  Installing a new version uses a new
directory with a different name; as long as the old version remains
installed, its files will remain unmodified in the places where they are
expected to be.

  However, if you have built Emacs yourself and use it from the
directory where you built it, you will experience this problem
occasionally if you edit and recompile Lisp files.  When it happens, you
can cure the problem by reloading the file after recompiling it.

  Byte-compiled files made with recent versions of Emacs (since 19.29)
will not load into older versions because the older versions don't
support this feature.  You can turn off this feature at compile time by
setting @code{byte-compile-dynamic-docstrings} to @code{nil}; then you
can compile files that will load into older Emacs versions.  You can do
this globally, or for one source file by specifying a file-local binding
for the variable.  One way to do that is by adding this string to the
file's first line:

@example
-*-byte-compile-dynamic-docstrings: nil;-*-
@end example

@defvar byte-compile-dynamic-docstrings
If this is non-@code{nil}, the byte compiler generates compiled files
that are set up for dynamic loading of documentation strings.
@end defvar

@cindex @samp{#@@@var{count}}
@cindex @samp{#$}
  The dynamic documentation string feature writes compiled files that
use a special Lisp reader construct, @samp{#@@@var{count}}.  This
construct skips the next @var{count} characters.  It also uses the
@samp{#$} construct, which stands for ``the name of this file, as a
string.''  It is usually best not to use these constructs in Lisp source
files, since they are not designed to be clear to humans reading the
file.

@node Dynamic Loading
@section Dynamic Loading of Individual Functions

@cindex dynamic loading of functions
@cindex lazy loading
  When you compile a file, you can optionally enable the @dfn{dynamic
function loading} feature (also known as @dfn{lazy loading}).  With
dynamic function loading, loading the file doesn't fully read the
function definitions in the file.  Instead, each function definition
contains a place-holder which refers to the file.  The first time each
function is called, it reads the full definition from the file, to
replace the place-holder.

  The advantage of dynamic function loading is that loading the file
becomes much faster.  This is a good thing for a file which contains
many separate user-callable functions, if using one of them does not
imply you will probably also use the rest.  A specialized mode which
provides many keyboard commands often has that usage pattern: a user may
invoke the mode, but use only a few of the commands it provides.

  The dynamic loading feature has certain disadvantages:

@itemize @bullet
@item
If you delete or move the compiled file after loading it, Emacs can no
longer load the remaining function definitions not already loaded.

@item
If you alter the compiled file (such as by compiling a new version),
then trying to load any function not already loaded will yield nonsense
results.
@end itemize

  These problems will never happen in normal circumstances with
installed Emacs files.  But they are quite likely to happen with Lisp
files that you are changing.  The easiest way to prevent these problems
is to reload the new compiled file immediately after each recompilation.

  The byte compiler uses the dynamic function loading feature if the
variable @code{byte-compile-dynamic} is non-@code{nil} at compilation
time.  Do not set this variable globally, since dynamic loading is
desirable only for certain files.  Instead, enable the feature for
specific source files with file-local variable bindings.  For example,
you could do it by writing this text in the source file's first line:

@example
-*-byte-compile-dynamic: t;-*-
@end example

@defvar byte-compile-dynamic
If this is non-@code{nil}, the byte compiler generates compiled files
that are set up for dynamic function loading.
@end defvar

@defun fetch-bytecode function
This immediately finishes loading the definition of @var{function} from
its byte-compiled file, if it is not fully loaded already.  The argument
@var{function} may be a byte-code function object or a function name.
@end defun

@node Eval During Compile
@section Evaluation During Compilation

  These features permit you to write code to be evaluated during
compilation of a program.

@defspec eval-and-compile body
This form marks @var{body} to be evaluated both when you compile the
containing code and when you run it (whether compiled or not).

You can get a similar result by putting @var{body} in a separate file
and referring to that file with @code{require}.  That method is
preferable when @var{body} is large.
@end defspec

@defspec eval-when-compile body
This form marks @var{body} to be evaluated at compile time but not when
the compiled program is loaded.  The result of evaluation by the
compiler becomes a constant which appears in the compiled program.  If
you load the source file, rather than compiling it, @var{body} is
evaluated normally.

@strong{Common Lisp Note:} At top level, this is analogous to the Common
Lisp idiom @code{(eval-when (compile eval) @dots{})}.  Elsewhere, the
Common Lisp @samp{#.} reader macro (but not when interpreting) is closer
to what @code{eval-when-compile} does.
@end defspec

@node Byte-Code Objects
@section Byte-Code Function Objects
@cindex compiled function
@cindex byte-code function

  Byte-compiled functions have a special data type: they are
@dfn{byte-code function objects}.

  Internally, a byte-code function object is much like a vector;
however, the evaluator handles this data type specially when it appears
as a function to be called.  The printed representation for a byte-code
function object is like that for a vector, with an additional @samp{#}
before the opening @samp{[}.

  A byte-code function object must have at least four elements; there is
no maximum number, but only the first six elements have any normal use.
They are:

@table @var
@item arglist
The list of argument symbols.

@item byte-code
The string containing the byte-code instructions.

@item constants
The vector of Lisp objects referenced by the byte code.  These include
symbols used as function names and variable names.

@item stacksize
The maximum stack size this function needs.

@item docstring
The documentation string (if any); otherwise, @code{nil}.  The value may
be a number or a list, in case the documentation string is stored in a
file.  Use the function @code{documentation} to get the real
documentation string (@pxref{Accessing Documentation}).

@item interactive
The interactive spec (if any).  This can be a string or a Lisp
expression.  It is @code{nil} for a function that isn't interactive.
@end table

Here's an example of a byte-code function object, in printed
representation.  It is the definition of the command
@code{backward-sexp}.

@example
#[(&optional arg)
  "^H\204^F^@@\301^P\302^H[!\207"
  [arg 1 forward-sexp]
  2
  254435
  "p"]
@end example

  The primitive way to create a byte-code object is with
@code{make-byte-code}:

@defun make-byte-code &rest elements
This function constructs and returns a byte-code function object
with @var{elements} as its elements.
@end defun

  You should not try to come up with the elements for a byte-code
function yourself, because if they are inconsistent, Emacs may crash
when you call the function.  Always leave it to the byte compiler to
create these objects; it makes the elements consistent (we hope).

  You can access the elements of a byte-code object using @code{aref};
you can also use @code{vconcat} to create a vector with the same
elements.

@node Disassembly
@section Disassembled Byte-Code
@cindex disassembled byte-code

  People do not write byte-code; that job is left to the byte compiler.
But we provide a disassembler to satisfy a cat-like curiosity.  The
disassembler converts the byte-compiled code into humanly readable
form.

  The byte-code interpreter is implemented as a simple stack machine.
It pushes values onto a stack of its own, then pops them off to use them
in calculations whose results are themselves pushed back on the stack.
When a byte-code function returns, it pops a value off the stack and
returns it as the value of the function.

  In addition to the stack, byte-code functions can use, bind, and set
ordinary Lisp variables, by transferring values between variables and
the stack.

@deffn Command disassemble object &optional stream
This function prints the disassembled code for @var{object}.  If
@var{stream} is supplied, then output goes there.  Otherwise, the
disassembled code is printed to the stream @code{standard-output}.  The
argument @var{object} can be a function name or a lambda expression.

As a special exception, if this function is used interactively,
it outputs to a buffer named @samp{*Disassemble*}.
@end deffn

  Here are two examples of using the @code{disassemble} function.  We
have added explanatory comments to help you relate the byte-code to the
Lisp source; these do not appear in the output of @code{disassemble}.
These examples show unoptimized byte-code.  Nowadays byte-code is
usually optimized, but we did not want to rewrite these examples, since
they still serve their purpose.

@example
@group
(defun factorial (integer)
  "Compute factorial of an integer."
  (if (= 1 integer) 1
    (* integer (factorial (1- integer)))))
     @result{} factorial
@end group

@group
(factorial 4)
     @result{} 24
@end group

@group
(disassemble 'factorial)
     @print{} byte-code for factorial:
 doc: Compute factorial of an integer.
 args: (integer)
@end group

@group
0   constant 1              ; @r{Push 1 onto stack.}

1   varref   integer        ; @r{Get value of @code{integer}} 
                            ;   @r{from the environment}
                            ;   @r{and push the value}
                            ;   @r{onto the stack.}
@end group

@group
2   eqlsign                 ; @r{Pop top two values off stack,}
                            ;   @r{compare them,}
                            ;   @r{and push result onto stack.}
@end group

@group
3   goto-if-nil 10          ; @r{Pop and test top of stack;}
                            ;   @r{if @code{nil}, go to 10,}
                            ;   @r{else continue.}
@end group

@group
6   constant 1              ; @r{Push 1 onto top of stack.}

7   goto     17             ; @r{Go to 17 (in this case, 1 will be}
                            ;   @r{returned by the function).}
@end group

@group
10  constant *              ; @r{Push symbol @code{*} onto stack.}

11  varref   integer        ; @r{Push value of @code{integer} onto stack.}
@end group

@group
12  constant factorial      ; @r{Push @code{factorial} onto stack.}

13  varref   integer        ; @r{Push value of @code{integer} onto stack.}

14  sub1                    ; @r{Pop @code{integer}, decrement value,}
                            ;   @r{push new value onto stack.}
@end group

@group
                            ; @r{Stack now contains:}
                            ;   @minus{} @r{decremented value of @code{integer}}
                            ;   @minus{} @r{@code{factorial}} 
                            ;   @minus{} @r{value of @code{integer}}
                            ;   @minus{} @r{@code{*}}
@end group

@group
15  call     1              ; @r{Call function @code{factorial} using}
                            ;   @r{the first (i.e., the top) element}
                            ;   @r{of the stack as the argument;}
                            ;   @r{push returned value onto stack.}
@end group

@group
                            ; @r{Stack now contains:}
                            ;   @minus{} @r{result of recursive}
                            ;        @r{call to @code{factorial}}
                            ;   @minus{} @r{value of @code{integer}}
                            ;   @minus{} @r{@code{*}}
@end group

@group
16  call     2              ; @r{Using the first two}
                            ;   @r{(i.e., the top two)}
                            ;   @r{elements of the stack}
                            ;   @r{as arguments,}
                            ;   @r{call the function @code{*},}
                            ;   @r{pushing the result onto the stack.}
@end group

@group
17  return                  ; @r{Return the top element}
                            ;   @r{of the stack.}
     @result{} nil
@end group
@end example

The @code{silly-loop} function is somewhat more complex:

@example
@group
(defun silly-loop (n)
  "Return time before and after N iterations of a loop."
  (let ((t1 (current-time-string)))
    (while (> (setq n (1- n)) 
              0))
    (list t1 (current-time-string))))
     @result{} silly-loop
@end group

@group
(disassemble 'silly-loop)
     @print{} byte-code for silly-loop:
 doc: Return time before and after N iterations of a loop.
 args: (n)

0   constant current-time-string  ; @r{Push}
                                  ;   @r{@code{current-time-string}}
                                  ;   @r{onto top of stack.}
@end group

@group
1   call     0              ; @r{Call @code{current-time-string}}
                            ;   @r{ with no argument,}
                            ;   @r{ pushing result onto stack.}
@end group

@group
2   varbind  t1             ; @r{Pop stack and bind @code{t1}}
                            ;   @r{to popped value.}
@end group

@group
3   varref   n              ; @r{Get value of @code{n} from}
                            ;   @r{the environment and push}
                            ;   @r{the value onto the stack.}
@end group

@group
4   sub1                    ; @r{Subtract 1 from top of stack.}
@end group

@group
5   dup                     ; @r{Duplicate the top of the stack;}
                            ;   @r{i.e., copy the top of}
                            ;   @r{the stack and push the}
                            ;   @r{copy onto the stack.}
@end group

@group
6   varset   n              ; @r{Pop the top of the stack,}
                            ;   @r{and bind @code{n} to the value.}

                            ; @r{In effect, the sequence @code{dup varset}}
                            ;   @r{copies the top of the stack}
                            ;   @r{into the value of @code{n}}
                            ;   @r{without popping it.}
@end group

@group
7   constant 0              ; @r{Push 0 onto stack.}
@end group

@group
8   gtr                     ; @r{Pop top two values off stack,}
                            ;   @r{test if @var{n} is greater than 0}
                            ;   @r{and push result onto stack.}
@end group

@group
9   goto-if-nil-else-pop 17 ; @r{Goto 17 if @code{n} <= 0}
                            ;   @r{(this exits the while loop).}
                            ;   @r{else pop top of stack}
                            ;   @r{and continue}
@end group

@group
12  constant nil            ; @r{Push @code{nil} onto stack}
                            ;   @r{(this is the body of the loop).}
@end group

@group
13  discard                 ; @r{Discard result of the body}
                            ;   @r{of the loop (a while loop}
                            ;   @r{is always evaluated for}
                            ;   @r{its side effects).}
@end group

@group
14  goto     3              ; @r{Jump back to beginning}
                            ;   @r{of while loop.}
@end group

@group
17  discard                 ; @r{Discard result of while loop}
                            ;   @r{by popping top of stack.}
                            ;   @r{This result is the value @code{nil} that}
                            ;   @r{was not popped by the goto at 9.}
@end group

@group
18  varref   t1             ; @r{Push value of @code{t1} onto stack.}
@end group

@group
19  constant current-time-string  ; @r{Push} 
                                  ;   @r{@code{current-time-string}}
                                  ;   @r{onto top of stack.}
@end group

@group
20  call     0              ; @r{Call @code{current-time-string} again.}
@end group

@group
21  list2                   ; @r{Pop top two elements off stack,}
                            ;   @r{create a list of them,}
                            ;   @r{and push list onto stack.}
@end group

@group
22  unbind   1              ; @r{Unbind @code{t1} in local environment.}

23  return                  ; @r{Return value of the top of stack.}

     @result{} nil
@end group
@end example
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.