Hi guys, A few questions from a former Mozart hacker...
On Sat, Feb 25, 2012 at 7:02 PM, Yves Jaradin <[email protected]>wrote: > The part that corresponds to the new-style code that you gives is from the > line "allocateL3" (just after the line starting with "lbl(15)") to the line > "return" (two lines above the one starting with "lbl(103)") and without the > lines from "move(g(0) x(0))" (line after "lbl(42)") to the line > "endDefinition(42)" (line before "lbl(65)"). > > The reason for these cuts is that the old VM uses a single codearea for > many procedures, differing by more than the contextual environment. This is > bad for garbage collection as an abstraction will keep alive the code and > constants of all the things that were compiled with it. > This is excellent news! It allows to have a procedure A that creates a procedure B, and then have A garbage-collected while B is still alive in memory. I remember that that use case was problematic in the former design. Therefore, the new VM uses separate codearea for each procedure in the Oz > source (of course different instances with different contextual environment > will share the codearea). > ... > K registers are the way the new VM deals with compile-time constants. The > old VM just wrote them in the codearea amongst the opcodes and integer > arguments. This forced many algorithms in the old VM to do code-walking to > find all the nodes in a codearea. It was also problematic with the bigger > nodes that we have to guarantee alignment. So we decided to move the > constants to proper registers. As they are constants they were given the K > letter. An alternative design is to use G registers for constants. This is done commonly in functional languages (this operation is called "lifting"), where this lifting operation is a partial application of a function without constants (the language must support curryfication). I guess that K registers are simpler: all closures sharing a code area also share the code's K registers, while each closure has its own array of G registers. - Why are we using scala to bootstrap when we want to keep dependencies low? >> > > We need a bootstrap compiler written in anything but Oz (or any language > depending on Oz but that's not common). The obvious choice for minimizing > dependencies is C++ but writing a compiler (even a simple one) in C++ is no > piece of cake. It would have been my choice but I know that by the time > Sébastien will have a full compiler working, I would have just had the > framework to write the parsing and rewriting rules. The decision process > was quite easy. To have a compiler working soon, we needed to write it in a > language with strong symbolic support and pattern-matching (Oz fits the > bill nicely but ...) and the only such language any of us had real > expertise with was Scala, so Scala it was. Once all is done and working, > rewriting it in C++ would be a nice exercise. In any case, it is a rather > separate component without too much interaction with the rest so Scla won't > "contaminate" the whole project. Scala is an excellent choice, IMHO. In particular because you have typed tuples and pattern-matching right under your hands; it makes the VM bytecode clear and the compiler should be relatively simple. Thanks for the good work! Raphael
_________________________________________________________________________________ mozart-hackers mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-hackers
