From 9d8c22b202c0b22c6d5d30ac459dd2a04a75e169 Mon Sep 17 00:00:00 2001 From: Frank Kotler Date: Thu, 10 Mar 2005 02:03:11 +0000 Subject: [PATCH] add John Coffman's optimizer documentation --- doc/opt_var.txt | 114 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 doc/opt_var.txt diff --git a/doc/opt_var.txt b/doc/opt_var.txt new file mode 100644 index 00000000..4482e5d8 --- /dev/null +++ b/doc/opt_var.txt @@ -0,0 +1,114 @@ + NASM Optimizer Usage of + Certain Variables to Control Assembly + + prepared by: John R Coffman + date: 07-Mar-2005 + + +GLOBAL variables: + optimizing -1 flags nasm 0.98 compatible operation; + offsets usually are explicit (short/near) + no optimization passes + 0 flags non-optimized assembly; forward + references generate long offsets; always + assembles + no optimization passes + 2 or more specifies optmization passes. 5 is + the actual recommended minimum setting + optimization passes (2 or more, plus + passes 1 and 2 will be required) + + + pass0 0 flags an optimizer pass (multiple passes) + 1 flags pass1 (define labels) + 2 flags pass2 (spit out code) + + +LOCAL variables: local to 'assemble_file' (nasm.c) + + pass_max 2 for non-optimized assembly + 4 or more for optimized assembly + + pass index of the FOR loop (1..pass_max) + with optimized assembly, this variable is + advanced to 'pass_max - 1' in the logic + at the end of the loop to terminate + an optimized assembly before all passes + are used; i.e., when convergence has + occurred + + + pass1 flag for making parts of the assembler do + pass 1 behaviors on optimizer passes + + pass2 flag for making parts of the assembler do + pass 2 behaviors on optimizer passes + + pass_cnt benign counter for counting the actual + number of passes taken. Since 'pass' + may be jerked upward early on optimized + assembly, it does not accurately reflect + the number of passes taken. + always ends at 2 for non-optimized assembly + + + + How the variables sequence: + + +NON-OPTIMIZED assembly: + + + pass0 1 2 all indicate, pass 1 and pass 2 + pass1 1 2 + pass2 1 2 + + pass 1 2 + ---------------------------------------- + + pass_max pre-set to 2 + pass_cnt ends at 2 + + +OPTIMIZED assembly: + + optimizing set to 2 or greater + + pass0 0 0 0 0 0 ... 0 0 1 2 + pass1 1 1 1 1 1 ... 1 1 1 2 + pass2 1 2 2 2 2 ... 2 2 2 2 + + pass 1 2 3 4 5 ... 7 8 9 12 + + pass_max pre-set to, say, 12 + pass_cnt ends at 10 for this assembly + +>From pass_cnt, the reported number of passes will be 1+8+1, meaning +8 optimization passes, plus pass 1, plus pass 2. + +Subroutines may check 'pass0' to see if an optimizer pass is in +progress (pass0==0). Many have arguments to tell what pass is in +progress. But these variables are passed in as 'pass1' or 'pass2'. + +>From the sequences above, 'pass' bears no relation to the desired +pass 1 or pass 2 behavior of the assembler. 'pass1' is used to tell +parts of the assembler, on multiple occasions, that pass 1 is in +progress, and only once that pass 2 is being performed. Other parts +of the assembler need to be told only once that pass 1 is being +performed, but may be told multiple times that pass 2 is being done. + +For instance, the preprocessor reset operation looks at pass1, and it +thinks many pass 1 resets are being done, but only one pass 2 reset +is done. Also, certain errors are non-fatal on pass 1, but fatal on +pass 2; hence, they are tied to the 'pass1' variable to determine the +assembler pass number. + +Further, segment definitions look at the 'pass2' variable, since they +do some initialization on pass 1, but are pretty much no-ops on pass +2. Hence, they should see pass 1 only once, but may see pass 2 +multiple times. + + + +[end] +