June 2010 - Tachyon-list - mailman.iro.umontreal.ca

Meeting Tomorrow 10h am
by Erick Lavoie 16 Jun '10

16 Jun '10

I suggest we meet in the 2166 room if it is available. If I remember well we should have a bigger whiteboard and a little more room. What do you think? Erick

4 5

Meeting Wed May 26th, 10am ?
by Erick Lavoie 11 Jun '10

11 Jun '10

I just want to confirm our meeting next Wednesday at 10am. Is it all right for everybody? Erick

5 38

KISS SSA Conversion
by chevalma＠iro.umontreal.ca 09 Jun '10

09 Jun '10

Clark Verbrugge pointed out to me that someone had done work on making a *very* simple SSA conversion algorithm. It works by first pessimistically inserting phi nodes everywhere, and then iteratively removing them using two (trivial) simplification rules. This generates minimal SSA for reducible graphs, and has the advantage of being extremely simple. Furthermore, it has the advantage that we can tweak the cost by setting a maximum number of iterations, if we wish. The authors show timing comparisons slowing that with unbounded number of iterations, it's slightly slower than dominance frontiers, *but*, it's much simpler to implement, it's *incremental* (meaning we can eliminate phi nodes introduced by naive code transformations easily), and I think we can improve over it by being less pessimistic when we first insert phi nodes. We could also potentially make it better for irreducible graphs by implementing more powerful reduction rules w.r.t. cycles, which we could use for code we really want to optimize. I suggest we implement this algorithm for the AST->SSA IR conversion. It will be fast to implement, and fast if we bound the number of iterations for the baseline compiler. It should also be fairly easy to replace by another algorithm if we ever think we need to. See: "SIMPLE GENERATION OF STATIC SINGLE ASSIGNMENT FORM", CC2000, JOHN AYCOCK, NIGEL HORSPOOL - Maxime

1 0

x86 code generator and in-memory assembler
by Marc Feeley 09 Jun '10

09 Jun '10

We need to start implementing the x86 code generator and in-memory assembler. Once we have that we can start experimenting with dynamic code generation and start work on the Tachyon back-end. We can use the code I wrote for the Gambit x86 back-end as a starting point. It supports code generation for 32 and 64 bit architectures and most of the instructions and addressing modes we need are implemented. So this work will be in large part a translation effort from Scheme to JS. The in-memory assembler is about 800 lines of Scheme. The x86 code generator is about 1400 lines of Scheme. Who is interested in working on this? Marc

2 7

Automatic semicolon insertion
by Marc Feeley 09 Jun '10

09 Jun '10

The parser now supports automatic semicolon insertion. It can be enabled/disabled when the Parser object is created (a parameter of the constructor). We should plan to have a command-line option for the compiler so that automatic semicolon insertion can be disabled (to check for proper style). Marc

1 0

Parser milestone
by Marc Feeley 08 Jun '10

08 Jun '10

I've just pushed my latest changes to the parser. The parser is now self-applicable. In fact, the js2scm translator, which uses the parser, is now able to bootstrap itself on top of Gambit. Once bootstrapped, js2scm is a standalone executable program (i.e. no need for v8 anymore). I'm not suggesting that we do away with v8 for our development work... The point is that the development of js2scm gave me a good idea of the runtime support that is needed to implement the compiler, and a better understanding of the runtime model. Note that js2scm is more portable than v8 (because the Gambit compiler compiles to C, which we could compile anywhere). This might come in handy. There are no optimizations in js2scm (hash-tables everywhere, etc) so it runs about 20 times slower than v8. I'm surprised it is not slower (because something as innocuous as x.abc is translated to (table-ref (Object-ht x) "abc") so the Scheme code has to hash the string "abc" and search the hash-table of x, which is not cheap). The bootstrapping process was very useful to discover some remaining bugs in the source (v8 does not flag misspelled variable names, but Gambit does). For that reason alone, it might be good to use js2scm (and/or jslint?) once in a while to eliminate such bugs. Marc

1 0

Semantics of blocks
by Marc Feeley 07 Jun '10

07 Jun '10

I'm in the process of simplifying the structure of the AST, doing things like resolving variable references, flattening nested blocks and transforming switch statements into nested ifs. One thing that I'm unclear about is wether blocks add anything to the semantics other than just grouping statements. For example, is the program var foo = 1; print(foo); equivalent to { var foo = 1; print(foo); } ? It is hard to decipher the ECMAScript spec to guarantee that it is so (which I think it is). Anyone have an opinion? Marc

2 3