micropython

TO_DO.txt

450:5382a26943ca
2011-08-21 Paul Boddie Changed the nature of RSVP instructions so that they have explicit working, target and source register inputs and no longer consume simple instructions as direct inputs. This changes the nature of the generated code and of certain optimisations, as well as making some previous optimisations redundant and necessitating additional optimisations.
     1 Low-Level Instructions and Macro Instructions
     2 =============================================
     3 
     4 Instructions manipulated through the temporary infrastructure are reused and can be
     5 corrupted by set_source and set_target operations. It might be better if such operations
     6 cloned the instructions or if new instructions were explicitly created.
     7 
     8 Have contexts and values stored separately in memory. This involves eliminating DataValue
     9 and storing attributes using two words.
    10 
    11 Migrate macro instructions such as the *Index instructions to library code implemented
    12 using low-level instructions.
    13 
    14 Consider introducing classic machine level instructions (word addition, subtraction, and
    15 so on) in order to implement all current RSVP instructions.
    16 
    17 Move common code sequences to a library routine, such as the context checking that occurs
    18 in functions and methods.
    19 
    20 Return Value Optimisations
    21 ==========================
    22 
    23 Attempt to use result data directly instead of transferring it explicitly to the working
    24 registers and then using it.
    25 
    26 Perhaps store resultant working values on Block instances in order to better track active
    27 values.
    28 
    29 Class and Module Attribute Assignment
    30 =====================================
    31 
    32 Verify that the context information is correctly set, particularly for the unoptimised
    33 cases.
    34 
    35   Update docs/assignment.txt.
    36 
    37 Prevent assignments within classes, such as method aliasing, from causing the source of an
    38 assignment from being automatically generated. Instead, only external references should be
    39 registered.
    40 
    41 Prevent "from <module> import ..." statements from registering references to such local
    42 aliases such that they cause the source of each alias to be automatically generated.
    43 
    44 Consider attribute assignment observations, along with the possibility of class and module
    45 attribute assignment.
    46 
    47   (Note direct assignments as usual, indirect assignments via the attribute usage
    48   mechanism. During attribute collection and inference, add assigned values to all
    49   inferred targets.)
    50 
    51   (Since class attributes can be assigned, StoreAttrIndex would no longer need to reject
    52   static attributes, although this might still be necessary where attribute usage analysis
    53   has not been performed.)
    54 
    55   Potentially consider changing static attribute details to use object-relative offsets in
    56   order to simplify the instruction implementations. This might allow us to eliminate the
    57   static attribute flag for attributes in the object table, at least at run-time.
    58 
    59 Dynamic Attribute Access
    60 ========================
    61 
    62 Consider explicit accessor initialisation:
    63 
    64   attr = accessor("attr")
    65   getattr(C, attr)
    66 
    67 Attribute Usage
    68 ===============
    69 
    70 Loop entry points and other places where usage becomes more specific might be used as
    71 places to impose guards. See tests/attribute_access_type_restriction_loop_list.py for an
    72 example.
    73 
    74 Consider attribute usage observations being suspended inside blocks where AttributeError
    75 may be caught (although this doesn't anticipate such exceptions being caught outside a
    76 function altogether).
    77 
    78 Consider type deduction and its consequences where types belong to the same hierarchy
    79 and where a guard could be generated for the most general type.
    80 
    81 Consider permitting multiple class alternatives where the attributes are all identical.
    82 
    83 Support class attribute positioning similar to instance attribute positioning, potentially
    84 (for both) based on usage observations. For example, if __iter__ is used on two classes,
    85 the class attribute could be exposed at a similar relative position to the class (and
    86 potentially accessible using a LoadAttr-style instruction).
    87 
    88 **** Constant attribute users need not maintain usage since they are already resolved. ****
    89 
    90 Consider handling CallFunc in micropython.inspect in order to produce instances of specific classes.
    91 Then, consider adding support for guard removal/verification where known instances are involved.
    92 Consider handling branches of values within namespaces in order to support more precise value usage.
    93 
    94 Frame Optimisations
    95 ===================
    96 
    97 Stack frame replacement where a local frame is unused after a call, such as in a tail call
    98 situation.
    99 
   100 Local assignment detection plus frame re-use. Example: slice.__init__ calls
   101 xrange.__init__ with the same arguments which are unchanged in xrange.__init__. There is
   102 therefore no need to build a new frame for this call, although in some cases the locals
   103 frame might need expanding.
   104 
   105 Inlining
   106 ========
   107 
   108 Where a function or method call can always be determined, the body of the target could be
   109 inlined - copied into place - within the caller. If the target is only ever called by a
   110 single caller it could be moved into place.
   111 
   112 Function Specialisation
   113 =======================
   114 
   115 Specialisation of certain functions, such as isinstance(x, cls) where cls is a known
   116 constant.
   117 
   118 Structure and Object Table Optimisations
   119 ========================================
   120 
   121 Fix object table entries for attributes not provided by any known object, or provide an
   122 error, potentially overridden by options. For example, the augmented assignment methods
   123 are not supported by the built-in objects and thus the operator module functions cause
   124 the compilation to fail. Alternatively, just supply the methods since something has to do
   125 so in the builtins.
   126 
   127 Consider attribute merging where many attributes are just aliases for the same underlying
   128 definition.
   129 
   130 Consider references to defaults as occurring only within the context of a particular
   131 function, thus eliminating default value classes if such functions are not themselves
   132 invoked.
   133 
   134 Scope Handling
   135 ==============
   136 
   137 Consider merging the InspectedModule.store tests with the scope conflict handling.
   138 
   139 Consider labelling _scope on assignments and dealing with the assignment of removed
   140 attributes, possibly removing the entire assignment, and distinguishing between such cases
   141 and unknown names.
   142 
   143 Check name origin where multiple branches could yield multiple scope interpretations:
   144 
   145 ----
   146 try:
   147     set # built-in name
   148 except NameError:
   149     from sets import Set as set # local definition of name
   150 
   151 set # could be confused by the local definition at run-time
   152 ----
   153 
   154 Object Coverage
   155 ===============
   156 
   157 Support __init__ traversal (and other implicit names) more effectively.
   158 
   159 Other
   160 =====
   161 
   162 Support self attribute visualisation in the reports and/or provide a function or
   163 annotations which can provide the eventual optimisation directly to such components.
   164 
   165 Check context_value initialisation (avoiding or handling None effectively).
   166 
   167 Consider better "macro" support where new expressions need to be generated and processed.
   168 
   169 Detect TestIdentity results involving constants, potentially optimising status-affected
   170 instructions:
   171 
   172   TestIdentity(x, y) # where x is always y
   173   JumpIfFalse(...)   # would be removed (never false)
   174   JumpIfTrue(...)    # changed to Jump(...)
   175 
   176 Status-affected blocks could be optimised away for such constant-related results.