Home | About | Partners | Contact Us

SourceForge Logo

Quick Links
Building XL
XL Mailing List

Understanding XL
Conceptual overview
XL examples
Inside XL
Concept Programming

In depth
Browse GIT
SourceForge Info

Other projects
GNU Project
The Mozart Project

XLR: Extensible Language and Runtime

The art of turning ideas into code

XL, an extensible programming language, implements concept programming
If you want to know more, you should start here.

Redefined the tree information Daily
Tuesday, February 9, 2010

The tree information is now extensible. All tree information must derive from the Info class. There are template members to access that information:

  • Get reads the information, e.g. tree->Get<SymbolInfo>()
  • Set sets the information associated to the tree
  • Purge removes any information of a given type
  • Exists checks if a given tree has information of a given type.

I also added a compile-time assert in compiler.cpp after being bitten once more by a change in the Tree class not propagating to the tree.

Added serialization of trees Daily
Monday, February 8, 2010

Added a very simple form of tree serialization. It's implemented in serializer.cpp and serializer.h. Trees are stored using a relatively compact LEB128 binary encoding.

SHA-1 for trees Daily
Friday, February 5, 2010

Added some code to compute the SHA-1 for trees. We do that incrementally so as to leverage previous computations if any were done.

Partial state of interpreted mode committed Daily
Thursday, February 4, 2010

The latest version now contains the temporary state for the interpreter. It still fails with anything requiring local variable bindings, but the performance is already bad enough that I'm starting to doubt it will ever be useful.

Worked on separating the compilation and execution phases more cleanly.

Some trouble with LLVM Daily
Wednesday, February 3, 2010

One of the tests, tests/02.Data/rects.xl, doesn't work right. It crashes in LLVM:

Assertion failed: (T && "getTerminator returned null!"), function SuccIterator, file /Users/ddd/Development/llvm/include/llvm/Support/CFG.h, line 99.

I can't really see what is wrong with the function. After optimization, it is really not that complex (except that I don't know why the optmizer puts all these 'tail' calls):

define internal %tree* @xl_eval15(%tree*, %tree*) { allocas: %treek = load %tree** @xlcst17 ; <%tree*> [#uses=1] %treek71 = load %tree** @xlcst20 ; <%tree*> [#uses=0] %glob = load %tree** @xlint16 ; <%tree*> [#uses=1] %2 = tail call %tree* @xl_eval4(%tree* %treek, %tree* %1, %tree* %glob) ; <%tree*> [#uses=1] %3 = tail call %tree* @xl_evaluate(%tree* %2) ; <%tree*> [#uses=0] %glob80 = load %tree** @xlcst19 ; <%tree*> [#uses=1] %4 = tail call %tree* (%tree*, i32, ...)* @xl_new_closure(%tree* %glob80, i32 1, %tree* %1) ; <%tree*> [#uses=1] %glob83 = load %tree** @xlcst20 ; <%tree*> [#uses=1] %glob85 = load %tree** @xlint22 ; <%tree*> [#uses=1] %5 = tail call %tree* @xl_eval3(%tree* %glob83, %tree* %4, %tree* %glob85) ; <%tree*> [#uses=1] %6 = tail call %tree* @xl_evaluate(%tree* %5) ; <%tree*> [#uses=1] %7 = tail call %tree* @xl_evaluate(%tree* %6) ; <%tree*> [#uses=1] ret %tree* %7 }

This is a regression in LLVM: that test used to pass. I'm not running a precise release (because I'm fetching LLVM using git), but apparently whatever "stable" release you get from macports suffers the same problem.

I tried to update to the top-of-trunk of LLVM and see if that was fixed. Problem is that the XL compiler fails to compile. Once again, LLVM decided to change the constructors for the JIT. I don't know why they feel it's OK to change the source code without paying any attention to backward compatibility. It's a pain, because the downstream components have no way to provide code that works for all versions of LLVM. This time, the change appears to be the constructor of FunctionPassManager. It used to take a "provider", it now wants a "module". Not sure why it's not possible to provide backward-compatible bindings...

Back to the original bug. More analysis shows that the problem is in JIT::runJITOnFunctionUnlocked which apparently feels like it needs to JIT all functions referenced by the one I am building. Problem is that in the case of XL, these are more often than not forward functions, so they are incomplete, so some of their basic blocks don't terminate right. We ultimately fail on the allocas basic block for one of the pending functions. So now I only need to figure out how to disable that behavior.

It turns out to be easy, I only need to use ExecutionEngine::DisableLazyCompilation, and the test passes again. This is in 7874c68828a3dc6f7e1b631e1ae24416e8cb48ff

Disabled Subversion and CVS

Finally decided to go ahead and disable Subversion and CVS. Trying to maintain both Subversion and Git was really annoying. So moving forward, the Subversion tree will most likely no longer be maintained.

Interpreted mode is back alive Daily
Tuesday, February 2, 2010

The interpreted mode passes some simple tests. However, I still have some trouble with variable binding.

In the process, I created some interesting functions. One of them allows me to call a function that takes N arguments with an array containing N arguments. See Compiler::EnterArrayToArgsAdapter.

I also made the compiled mode slower. I investigated why... I traced it back to a couple of issues with the evaluyation of constant trees, for instance 0 or 'ABC'. So I added the possibility to rewrite these while still running quickly for the common case where they are not rewritten.

Reviving interpreted mode Daily
Monday, February 1, 2010

I'm attempting to revive an interpreted mode for the runtime (xlr) alongside LLVM. There are some situations where I expect dynamic code generation to be a problem more than a solution, in particular when the code being generated is too dynamic.

So far, I have not been able to get LLVM to "garbage collect" without leaving some dead bodies behind (read: SIGSEGV).

February 2010
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
Jan  Mar

Copyright 2010 Christophe de Dinechin (Blog)
E-mail: XL Mailing List (polluted by spam, unfortunately)