On Wed, Aug 26, 2009 at 3:30 AM, Tom Schouten<[email protected]> wrote: >> If the rewrite rules are monotonic, then there's an easy procedure >> to optimize the program: list out all programs, calculate their >> efficiency, and select one of the best ones > > I guess here `monitonic' means that there are no loops? Something > like `strictly decreasing'. > No, I meant more like there's a partially ordered set of programs, where one program is "smaller" than another if it's more optimized, and your rewrite rules always rewrite a bigger program to a smaller one. Then, if there are no infinite descending chains, ie if there's no infinite sequence of rewrites to smaller and smaller programs, the (slow) algorithm for optimization that I described works. > >> Maybe the algorithm to find the optimal series of peephole >> optimizations will be a confluent subset of the general rewriting >> system of all valid peephole optimizations; is this what you mean? > > What I meant was that the algorithm in Staapl is formulated > differently (each word is a macro: a _fuction_ which takes an object > code stack to an object code stack). I don't immediately see how this > can be reformulated as a more general rewrite system on code _syntax_, > but I've got this hunch it's not so difficult. > > I'm also not sure if they are really 100% equivalent, since I'm > throwing in some extra specification of the order of evaluation. This > makes it possible to play tricks like using objects that only exist at > compile time without requiring any special notation for it: the eager > algorithm guarantees that such objects are fully reduced before code > is compiled (or raise an error). What would be neat is to be able to > keep this semantics, but use a more elegant way of formulating it as a > syntactic operation. (If this doesn't make sense I'd be happy to > elaborate.)
Yeah, that makes sense, like a kind of abstract interpretation, you're saying? > >> On register-based architectures (like the PIC18, right?), doing >> everything with a stack is inherently inefficient because of peeks >> and replaces on the top of the stack. > > The 8-bit PIC chips are weird. The 16-bit cores are more or less > standard register/risc but on the 8-bitters everything needs to pass > through a single working register. This makes it almost cry for a > stack language approach :) > Oh, right, that does sound like it'd limit the benefits of a more advanced compiler like Factor's. Dan ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
