[<<][staapl][>>][..]
Wed May 6 10:10:06 CEST 2009

rules

So instead of the rules in [1] isn't it better to explain what addlw
means in terms of qw then derive the rule?  in other words, instead of
defining rules for packing, define them for unpacking too.

(([addlw a] unpack) ([qw a] [cw +]))

As an intermediate step towards more insight, it might be best to find
which rules or clauses within a rule are invertible.  Once there are
inverses, it should be possible to start optimizing by search.

The thing is: once subsets of code have better isolated properties,
transformations on them could be done on a higher level.

In general, code concatenation is a moniod [2] :
  - closure
  - associativity
  - identity element

Identifying invertible elements would maybe make it possible to find a
subgroup in the monoid.  Then finding commutation relations could
construct an abelian group.

Actually, the 'unpack macros are disassemblers.

I'm thinking that a mechanism on top of the current macros is
necessary for this.  The problem with rules and general rewriters is
that they are algorithmically complex.  However, it might be possible
to devise a couple of passes of eager macros from a set of more
general rules and a bunch of training data in the form of programs.

The trick is going to be to link together the semantics of the
transformers defined in terms of how they act on code, and the
algebraic structure defined by the transformers alone, without this
semantics attached.


[1] entry://20090505-091631
[2] http://en.wikipedia.org/wiki/Monoid
[3] http://en.wikipedia.org/wiki/Transition_monoid



[Reply][About]
[<<][staapl][>>][..]