micropython

Annotated TO_DO.txt

528:d486a4cf1730
515:20ea2e9b841d
504:3af81876ceae
2012-06-03 Paul Boddie file changeset files shortlog Restricted attribute assignments observed through usage analysis to instance attributes only.
paul@472 1 
Name usage types: as parameters, as base classes, as callables. This potentially restricts
paul@472 2 
attribute usage effects because names mentioned as base classes are not propagated and
paul@472 3 
made freely available for use in attribute accesses.
paul@472 4 
 
 paul@419      5 
Low-Level Instructions and Macro Instructions

 
 paul@419      6 
=============================================

 
 paul@419      7 
 
 paul@429      8 
Have contexts and values stored separately in memory. This involves eliminating DataValue

 
 paul@429      9 
and storing attributes using two words.

 
 paul@429     10 
 
 paul@419     11 
Migrate macro instructions such as the *Index instructions to library code implemented

 
 paul@419     12 
using low-level instructions.

 
 paul@419     13 
 
 paul@419     14 
Consider introducing classic machine level instructions (word addition, subtraction, and

 
 paul@419     15 
so on) in order to implement all current RSVP instructions.

 
 paul@419     16 
 
 paul@450     17 
Move common code sequences to a library routine, such as the context checking that occurs

 
 paul@450     18 
in functions and methods.

 
 paul@450     19 
 
 paul@464     20 
Dataflow Optimisations

 
 paul@464     21 
======================

 
 paul@450     22 
 
 paul@464     23 
Assignments, particularly now that no result register exists, may cause StoreTemp/LoadTemp

 
 paul@464     24 
instruction pairs to be produced and these could be eliminated.

 
 paul@450     25 
 
 paul@417     26 
Class and Module Attribute Assignment

 
 paul@417     27 
=====================================

 
 paul@417     28 
 
 paul@417     29 
Verify that the context information is correctly set, particularly for the unoptimised

 
 paul@417     30 
cases.

 
 paul@417     31 
 
 paul@417     32 
  Update docs/assignment.txt.

 
 paul@417     33 
 
 paul@431     34 
Prevent assignments within classes, such as method aliasing, from causing the source of an

 
 paul@431     35 
assignment from being automatically generated. Instead, only external references should be

 
 paul@431     36 
registered.

 
 paul@431     37 
 
 paul@431     38 
Prevent "from <module> import ..." statements from registering references to such local

 
 paul@431     39 
aliases such that they cause the source of each alias to be automatically generated.

 
 paul@431     40 
 
 paul@419     41 
Consider attribute assignment observations, along with the possibility of class and module

 
 paul@419     42 
attribute assignment.

 
 paul@419     43 
 
 paul@419     44 
  (Note direct assignments as usual, indirect assignments via the attribute usage

 
 paul@419     45 
  mechanism. During attribute collection and inference, add assigned values to all

 
 paul@419     46 
  inferred targets.)

 
 paul@419     47 
 
 paul@419     48 
  (Since class attributes can be assigned, StoreAttrIndex would no longer need to reject

 
 paul@419     49 
  static attributes, although this might still be necessary where attribute usage analysis

 
 paul@419     50 
  has not been performed.)

 
 paul@419     51 
 
 paul@419     52 
  Potentially consider changing static attribute details to use object-relative offsets in

 
 paul@419     53 
  order to simplify the instruction implementations. This might allow us to eliminate the

 
 paul@419     54 
  static attribute flag for attributes in the object table, at least at run-time.

 
 paul@419     55 
 
 paul@413     56 
Dynamic Attribute Access

 
 paul@413     57 
========================

 
 paul@413     58 
 
 paul@425     59 
Consider explicit accessor initialisation:

 
 paul@425     60 
 
 paul@425     61 
  attr = accessor("attr")

 
 paul@425     62 
  getattr(C, attr)

 
 paul@413     63 
 
 paul@394     64 
Attribute Usage

 
 paul@394     65 
===============

 
 paul@394     66 
 
 paul@498     67 
To consider: is it useful to distinguish between attribute name sets when the same names

 
 paul@498     68 
are mentioned, but where one path through the code sets different values on attributes

 
 paul@498     69 
than another? The _attrtypes collapses observations in order to make a list of object

 
 paul@498     70 
types for a name, and the final set of names leading to such type deductions might be a

 
 paul@498     71 
useful annotation to be added alongside _attrcombined.

 
 paul@498     72 
 
 paul@498     73 
Interface/Type Generalisation

 
 paul@498     74 
-----------------------------

 
 paul@498     75 
 
 paul@480     76 
Consolidate interface observations by taking all cached table accesses and determining

 
 paul@480     77 
which usage patterns lead to the same types. For example, if full usage of {a, b} and

 
 paul@480     78 
{a, b, c} leads to A and B in both cases, either {a, b} can be considered as partial usage

 
 paul@480     79 
of the complete interface {a, b, c}, or the latter can be considered as an

 
 paul@480     80 
overspecification of the former.

 
 paul@480     81 
 
 paul@364     82 
Consider type deduction and its consequences where types belong to the same hierarchy

 
 paul@364     83 
and where a guard could be generated for the most general type.

 
 paul@364     84 
 
 paul@364     85 
Consider permitting multiple class alternatives where the attributes are all identical.

 
 paul@364     86 
 
 paul@360     87 
Support class attribute positioning similar to instance attribute positioning, potentially

 
 paul@360     88 
(for both) based on usage observations. For example, if __iter__ is used on two classes,

 
 paul@360     89 
the class attribute could be exposed at a similar relative position to the class (and

 
 paul@360     90 
potentially accessible using a LoadAttr-style instruction).

 
 paul@360     91 
 
 paul@394     92 
**** Constant attribute users need not maintain usage since they are already resolved. ****

 
 paul@394     93 
 
 paul@498     94 
Self-related Usage

 
 paul@498     95 
------------------

 
 paul@498     96 
 
 paul@498     97 
Usage of self to restrict attribute usage observations and coverage.

 
 paul@498     98 
 
 paul@498     99 
Perform attribute usage on attributes of self as names, potentially combining observations

 
 paul@498    100 
across methods.

 
 paul@498    101 
 
 paul@498    102 
Additional Guards

 
 paul@498    103 
-----------------

 
 paul@498    104 
 
 paul@498    105 
Consider handling branches of values within namespaces in order to support more precise value usage.

 
 paul@498    106 
 
 paul@498    107 
Loop entry points and other places where usage becomes more specific might be used as

 
 paul@498    108 
places to impose guards. See tests/attribute_access_type_restriction_loop_list.py for an

 
 paul@498    109 
example. (Such information is already shown in the reports.)

 
 paul@498    110 
 
 paul@498    111 
Strict Interfaces/Types

 
 paul@498    112 
-----------------------

 
 paul@498    113 
 
 paul@498    114 
Make the gathering of usage parameterisable according to the optimisation level so that a

 
 paul@498    115 
choice can be made between control-flow-dependent observations and the simple collection

 
 paul@498    116 
of all attributes used with a name (producing a more static interface observation).

 
 paul@498    117 
 
 paul@498    118 
AttributeError

 
 paul@498    119 
--------------

 
 paul@498    120 
 
 paul@504    121 
Consider attribute usage observations being suspended or optional inside blocks where

 
 paul@504    122 
AttributeError may be caught (although this doesn't anticipate such exceptions being

 
 paul@504    123 
caught outside a function altogether). For example:

 
 paul@504    124 
 
 paul@504    125 
  y = a.y

 
 paul@504    126 
  try:

 
 paul@504    127 
      z = a.z # z is an optional attribute

 
 paul@504    128 
  except AttributeError:

 
 paul@504    129 
      z = None

 
 paul@498    130 
 
 paul@498    131 
Instantiation Deduction

 
 paul@498    132 
-----------------------

 
 paul@498    133 
 
 paul@394    134 
Consider handling CallFunc in micropython.inspect in order to produce instances of specific classes.

 
 paul@503    135 
Then, consider adding support for guard removal/verification where known instances are involved. For

 
 paul@503    136 
example:

 
 paul@503    137 
 
 paul@503    138 
  l = []

 
 paul@503    139 
  l.append(123) # type deductions are filtered using instantiation knowledge

 
 paul@394    140 
 
 paul@394    141 
Frame Optimisations

 
 paul@394    142 
===================

 
 paul@394    143 
 
 paul@394    144 
Stack frame replacement where a local frame is unused after a call, such as in a tail call

 
 paul@394    145 
situation.

 
 paul@394    146 
 
 paul@394    147 
Local assignment detection plus frame re-use. Example: slice.__init__ calls

 
 paul@394    148 
xrange.__init__ with the same arguments which are unchanged in xrange.__init__. There is

 
 paul@419    149 
therefore no need to build a new frame for this call, although in some cases the locals

 
 paul@419    150 
frame might need expanding.

 
 paul@419    151 
 
 paul@456    152 
Reference tracking where objects associated with names are assigned to attributes of other

 
 paul@456    153 
objects may assist in allocation optimisations. Recording whether an object referenced by

 
 paul@456    154 
a name is assigned to an attribute, propagated to another name and assigned to an

 
 paul@456    155 
attribute, or passed to another function or method might, if such observations were

 
 paul@456    156 
combined, allow frame-based or temporary allocation to occur.

 
 paul@456    157 
 
 paul@472    158 
Instantiation

 
 paul@472    159 
=============

 
 paul@472    160 
 
 paul@472    161 
Specific instances could be produced, providing type information and acting somewhat like

 
 paul@472    162 
classes during inspection.

 
 paul@472    163 
 
 paul@419    164 
Inlining

 
 paul@419    165 
========

 
 paul@419    166 
 
 paul@419    167 
Where a function or method call can always be determined, the body of the target could be

 
 paul@419    168 
inlined - copied into place - within the caller. If the target is only ever called by a

 
 paul@456    169 
single caller it could be moved into place. This could enhance deductions based on

 
 paul@456    170 
attribute usage since observations from the inlined function would be merged into the

 
 paul@456    171 
caller.

 
 paul@394    172 
 
 paul@394    173 
Function Specialisation

 
 paul@394    174 
=======================

 
 paul@394    175 
 
 paul@394    176 
Specialisation of certain functions, such as isinstance(x, cls) where cls is a known

 
 paul@394    177 
constant.

 
 paul@394    178 
 
 paul@394    179 
Structure and Object Table Optimisations

 
 paul@394    180 
========================================

 
 paul@394    181 
 
 paul@394    182 
Fix object table entries for attributes not provided by any known object, or provide an

 
 paul@394    183 
error, potentially overridden by options. For example, the augmented assignment methods

 
 paul@394    184 
are not supported by the built-in objects and thus the operator module functions cause

 
 paul@394    185 
the compilation to fail. Alternatively, just supply the methods since something has to do

 
 paul@394    186 
so in the builtins.

 
 paul@394    187 
 
 paul@394    188 
Consider attribute merging where many attributes are just aliases for the same underlying

 
 paul@394    189 
definition.

 
 paul@394    190 
 
 paul@349    191 
Consider references to defaults as occurring only within the context of a particular

 
 paul@349    192 
function, thus eliminating default value classes if such functions are not themselves

 
 paul@349    193 
invoked.

 
 paul@349    194 
 
 paul@394    195 
Scope Handling

 
 paul@394    196 
==============

 
 paul@394    197 
 
 paul@394    198 
Consider merging the InspectedModule.store tests with the scope conflict handling.

 
 paul@394    199 
 
 paul@343    200 
Consider labelling _scope on assignments and dealing with the assignment of removed

 
 paul@343    201 
attributes, possibly removing the entire assignment, and distinguishing between such cases

 
 paul@343    202 
and unknown names.

 
 paul@343    203 
 
 paul@342    204 
Check name origin where multiple branches could yield multiple scope interpretations:

 
 paul@342    205 
 
 paul@504    206 
  try:

 
 paul@504    207 
      set # built-in name

 
 paul@504    208 
  except NameError:

 
 paul@504    209 
      from sets import Set as set # local definition of name

 
 paul@342    210 
 
 paul@504    211 
  set # could be confused by the local definition at run-time

 
 paul@342    212 
 
 paul@394    213 
Object Coverage

 
 paul@394    214 
===============

 
 paul@394    215 
 
 paul@332    216 
Support __init__ traversal (and other implicit names) more effectively.

 
 paul@332    217 
 
 paul@499    218 
Importing Modules

 
 paul@499    219 
=================

 
 paul@499    220 
 
 paul@499    221 
Consider supporting relative imports, even though this is arguably a misfeature.

 
 paul@499    222 
 
 paul@394    223 
Other

 
 paul@394    224 
=====

 
 paul@394    225 
 
 paul@482    226 
Consider a separate annotation phase where deductions are added to the AST for the

 
 paul@482    227 
benefit of both the reporting and code generation phases.

 
 paul@482    228 
 
 paul@449    229 
Support self attribute visualisation in the reports and/or provide a function or

 
 paul@449    230 
annotations which can provide the eventual optimisation directly to such components.

 
 paul@408    231 
 
 paul@332    232 
Check context_value initialisation (avoiding or handling None effectively).

 
 paul@332    233 
 
 paul@342    234 
Consider better "macro" support where new expressions need to be generated and processed.

 
 paul@402    235 
 
 paul@402    236 
Detect TestIdentity results involving constants, potentially optimising status-affected

 
 paul@402    237 
instructions:

 
 paul@402    238 
 
 paul@402    239 
  TestIdentity(x, y) # where x is always y

 
 paul@402    240 
  JumpIfFalse(...)   # would be removed (never false)

 
 paul@402    241 
  JumpIfTrue(...)    # changed to Jump(...)

 
 paul@402    242 
 
 paul@402    243 
Status-affected blocks could be optimised away for such constant-related results.