micropython

TO_DO.txt

738:87db7d860e4e
2013-11-15 Paul Boddie Added a module to verify that an appropriate compiler module is being used. syspython-as-target
     1 Name usage types: as parameters, as base classes, as callables. This potentially restricts
     2 attribute usage effects because names mentioned as base classes are not propagated and
     3 made freely available for use in attribute accesses.
     4 
     5 Low-Level Instructions and Macro Instructions
     6 =============================================
     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 Dataflow Optimisations
    21 ======================
    22 
    23 Assignments, particularly now that no result register exists, may cause StoreTemp/LoadTemp
    24 instruction pairs to be produced and these could be eliminated.
    25 
    26 Ambiguous/Multiple Class/Function Definitions
    27 =============================================
    28 
    29 Classes and functions are not supposed to have multiple definitions, where one code path
    30 may define one form of a class or function with a given name and another code path may
    31 define another form with that name. Currently, such multiple definitions are treated like
    32 "unions" in the object table.
    33 
    34   Consider functions as well as classes which are supported using "shadow" names for the
    35   second and subsequent definitions of classes in the same namespace.
    36 
    37 Class and Module Attribute Assignment
    38 =====================================
    39 
    40 Allow unrestricted class and module assignment (but not new external binding of
    41 attributes), eliminating run-time checks on object types in instructions like
    42 StoreAttrIndex. This may involve less specific objects being identified during inspection.
    43 
    44   Potentially re-evaluate class bases in order to see if they are non-constant.
    45 
    46 Verify that the context information is correctly set, particularly for the unoptimised
    47 cases.
    48 
    49   Update docs/assignment.txt.
    50 
    51 Prevent assignments within classes, such as method aliasing, from causing the source of an
    52 assignment from being automatically generated. Instead, only external references should be
    53 registered.
    54 
    55 Prevent "from <module> import ..." statements from registering references to such local
    56 aliases such that they cause the source of each alias to be automatically generated.
    57 
    58 Consider attribute assignment observations, along with the possibility of class and module
    59 attribute assignment.
    60 
    61   (Note direct assignments as usual, indirect assignments via the attribute usage
    62   mechanism. During attribute collection and inference, add assigned values to all
    63   inferred targets.)
    64 
    65   (Since class attributes can be assigned, StoreAttrIndex would no longer need to reject
    66   static attributes, although this might still be necessary where attribute usage analysis
    67   has not been performed.)
    68 
    69   Potentially consider changing static attribute details to use object-relative offsets in
    70   order to simplify the instruction implementations. This might allow us to eliminate the
    71   static attribute flag for attributes in the object table, at least at run-time.
    72 
    73 Dynamic Attribute Access
    74 ========================
    75 
    76 Consider explicit accessor initialisation:
    77 
    78   attr = accessor("attr")
    79   getattr(C, attr)
    80 
    81 Attribute Usage
    82 ===============
    83 
    84 To consider: is it useful to distinguish between attribute name sets when the same names
    85 are mentioned, but where one path through the code sets different values on attributes
    86 than another? The _attrtypes collapses observations in order to make a list of object
    87 types for a name, and the final set of names leading to such type deductions might be a
    88 useful annotation to be added alongside _attrcombined.
    89 
    90   (Update the reports to group identical sets of attribute names.)
    91 
    92 Attribute usage on attributes might be possible if one can show that the expression of an
    93 attribute access is constant and that the attribute target is also constant or only refers
    94 to a single type. For example, in the sys module:
    95 
    96   stderr = file()
    97 
    98 If no work is done to associate the result of the invocation with the stderr name, then
    99 one could instead at least attempt to determine whether stderr is assigned only once. If
   100 so, it might be possible to record attribute usage on references to the name. For example:
   101 
   102   sys.stderr.write(...) # sys.stderr supports write -> {file, ...}
   103 
   104 Interface/Type Generalisation
   105 -----------------------------
   106 
   107 Consolidate interface observations by taking all cached table accesses and determining
   108 which usage patterns lead to the same types. For example, if full usage of {a, b} and
   109 {a, b, c} leads to A and B in both cases, either {a, b} can be considered as partial usage
   110 of the complete interface {a, b, c}, or the latter can be considered as an
   111 overspecification of the former.
   112 
   113 Consider type deduction and its consequences where types belong to the same hierarchy
   114 and where a guard could be generated for the most general type.
   115 
   116 Consider permitting multiple class alternatives where the attributes are all identical.
   117 
   118 Support class attribute positioning similar to instance attribute positioning, potentially
   119 (for both) based on usage observations. For example, if __iter__ is used on two classes,
   120 the class attribute could be exposed at a similar relative position to the class (and
   121 potentially accessible using a LoadAttr-style instruction).
   122 
   123 **** Constant attribute users need not maintain usage since they are already resolved. ****
   124 
   125 Self-Related Usage
   126 ------------------
   127 
   128 Perform attribute usage on attributes of self as names, potentially combining observations
   129 across methods.
   130 
   131 Additional Guards
   132 -----------------
   133 
   134 Consider handling branches of values within namespaces in order to support more precise
   135 value usage.
   136 
   137 Loop entry points and other places where usage becomes more specific might be used as
   138 places to impose guards. See tests/attribute_access_type_restriction_loop_list.py for an
   139 example. (Such information is already shown in the reports.)
   140 
   141 Strict Interfaces/Types
   142 -----------------------
   143 
   144 Make the gathering of usage parameterisable according to the optimisation level so that a
   145 choice can be made between control-flow-dependent observations and the simple collection
   146 of all attributes used with a name (producing a more static interface observation).
   147 
   148 AttributeError
   149 --------------
   150 
   151 Consider attribute usage observations being suspended or optional inside blocks where
   152 AttributeError may be caught (although this doesn't anticipate such exceptions being
   153 caught outside a function altogether). For example:
   154 
   155   y = a.y
   156   try:
   157       z = a.z # z is an optional attribute
   158   except AttributeError:
   159       z = None
   160 
   161 Frame Optimisations
   162 ===================
   163 
   164 Stack frame replacement where a local frame is unused after a call, such as in a tail call
   165 situation.
   166 
   167 Local assignment detection plus frame re-use. Example: slice.__init__ calls
   168 xrange.__init__ with the same arguments which are unchanged in xrange.__init__. There is
   169 therefore no need to build a new frame for this call, although in some cases the locals
   170 frame might need expanding.
   171 
   172 Reference tracking where objects associated with names are assigned to attributes of other
   173 objects may assist in allocation optimisations. Recording whether an object referenced by
   174 a name is assigned to an attribute, propagated to another name and assigned to an
   175 attribute, or passed to another function or method might, if such observations were
   176 combined, allow frame-based or temporary allocation to occur.
   177 
   178 Instantiation Deduction
   179 =======================
   180 
   181 Consider handling Const, List and Tuple in micropython.inspect in order to produce
   182 instances of specific classes. Then, consider adding support for guard
   183 removal/verification where known instances are involved. For example:
   184 
   185   l = []
   186   l.append(123) # type deductions are filtered using instantiation knowledge
   187 
   188 Currently, this is done only for Const values in the context of attribute accesses during
   189 inspection.
   190 
   191 Handling CallFunc in a similar way is more challenging. Consider the definitions in the
   192 sys module:
   193 
   194   stderr = file()
   195 
   196 It must first be established that file only ever refers to the built-in file class, and
   197 only then can the assumption be made that stderr in this case refers to instances of file.
   198 If file can also refer to other objects, potential filtering operations are more severely
   199 limited.
   200 
   201 Propagation of type information can also occur. For example:
   202 
   203   DeducedSource(module, program).deduce()
   204 
   205 The DeducedSource invocation, if yielding an instance of the DeducedSource class, can then
   206 supply the attribute access operation with type information.
   207 
   208 A more advanced example involves accesses then invocations:
   209 
   210   x = self.__class__()
   211 
   212 Here, the effect should be the inference that x may refer to an instance of one of a
   213 number of eligible types of which self is also an instance.
   214 
   215 Invocation-Related Deduction
   216 ============================
   217 
   218 Where an attribute access (either in conjunction with usage observations or independently)
   219 could refer to a number of different targets, but where the resulting attribute is then
   220 used in an invocation, filtering of the targets could be done to eliminate any targets
   221 that are not callable. Guards would need introducing to prevent inappropriate operations
   222 from occurring at run-time.
   223 
   224 Inlining
   225 ========
   226 
   227 Where a function or method call can always be determined, the body of the target could be
   228 inlined - copied into place - within the caller. If the target is only ever called by a
   229 single caller it could be moved into place. This could enhance deductions based on
   230 attribute usage since observations from the inlined function would be merged into the
   231 caller.
   232 
   233 Distinguish between frame sharing and inlining: where a called function does not rebind
   234 its names, and where the frame of the caller is compatible, the frame of the caller might
   235 be shared with the called function even if a branch and return is still involved.
   236 
   237 Suitable candidates for inlining, frame sharing or enhanced analysis might be lambdas and
   238 functions containing a single statement.
   239 
   240 Function Specialisation
   241 =======================
   242 
   243 Specialisation of certain functions, such as isinstance(x, cls) where cls is a known
   244 constant.
   245 
   246 Structure and Object Table Optimisations
   247 ========================================
   248 
   249 Fix object table entries for attributes not provided by any known object, or provide an
   250 error, potentially overridden by options. For example, the augmented assignment methods
   251 are not supported by the built-in objects and thus the operator module functions cause
   252 the compilation to fail. Alternatively, just supply the methods since something has to do
   253 so in the builtins.
   254 
   255 Consider attribute merging where many attributes are just aliases for the same underlying
   256 definition.
   257 
   258 Consider references to defaults as occurring only within the context of a particular
   259 function, thus eliminating default value classes if such functions are not themselves
   260 invoked.
   261 
   262 Scope Handling
   263 ==============
   264 
   265 Consider merging the InspectedModule.store tests with the scope conflict handling.
   266 
   267 Consider labelling _scope on assignments and dealing with the assignment of removed
   268 attributes, possibly removing the entire assignment, and distinguishing between such cases
   269 and unknown names.
   270 
   271 Check name origin where multiple branches could yield multiple scope interpretations:
   272 
   273   try:
   274       set # built-in name
   275   except NameError:
   276       from sets import Set as set # local definition of name
   277 
   278   set # could be confused by the local definition at run-time
   279 
   280 Object Coverage
   281 ===============
   282 
   283 Support __init__ traversal (and other implicit names) more effectively.
   284 
   285 Importing Modules
   286 =================
   287 
   288 (Explicit relative imports are now supported.) Consider supporting relative imports, even
   289 though this is arguably a misfeature.
   290 
   291 Other
   292 =====
   293 
   294 Check context_value initialisation (avoiding or handling None effectively).
   295 
   296 Consider better "macro" support where new expressions need to be generated and processed.
   297 
   298 Detect TestIdentity results involving constants, potentially optimising status-affected
   299 instructions:
   300 
   301   TestIdentity(x, y) # where x is always y
   302   JumpIfFalse(...)   # would be removed (never false)
   303   JumpIfTrue(...)    # changed to Jump(...)
   304 
   305 Status-affected blocks could be optimised away for such constant-related results.
   306 
   307 Caching of structure and attribute usage information for incremental compilation.