dllaurence at dslextreme.com
Wed Jan 13 09:46:53 PST 2010
On 01/13/2010 04:08 AM, Garrison Venn wrote:
> If it helps, to see what is involved, outside of a pure IR context,
> see the example code, and doc at:
It does, although in the "let me show you why this is too much to
> Although this is a pure example that shows several test cases,
> including foreign exception interaction, it is not an IR example, but
> rather a LLVM IR API example. It would be interesting to see a pure
> IR version of a personality function. I don't see why this would not
> be possible, although costly in terms of effort. Clang would help.
Beyond the scope of the project, I guess. Sounds too far out on the
diminishing returns curve for knowledge. If I spend too much time
handcoding IR the first extension to the project would be to write a
"high-level IR" front-end that provides a 1-1 mapping of the semantics,
but with handcoding-friendly syntax and tools. It would actually save
time at some level, given that I'm manually #including headers just to
reduce the amount of code duplication to saying it twice instead of many
Complete aside--I hate when people tell me something is impossible, even
me. :-) So after I said you couldn't do without CPP-style #includes a
few days ago I was annoyed enough to design in my head an import/export
mechanism using only unix tools everyone has laying around. Just to
prove myself wrong, I guess. I'm not sure I'll implement it given that
I already have a lot of code written the other way, but LLVM syntax is
simple enough that it could be done without parsing the IR.
I don't know if I have enough IR left to justify switching over, but it
would be satisfying in principle to get rid of the duplication of headers.
> There are also ways to lower your invoke/unwind into a
> setjump/longjump implementation, but I do not know how to do this in
> IR, as it requires function pass setup which is outside the scope of
I don't know enough about how setjmp/longjmp are implemented to have a
clue. If I'm getting into uncharted territory it's easier to just
unwind the evaluator stack by hand, just as I already did with the
parser when unwinding didn't work. The focus is on learning IR and
about the simple lisp evaluation model.
There are actually limits to my madness, you know. :-) It would be more
profitable to learn another aspect of the system by implementing a MMIX
back-end or something.
Or, and I know this is just *crazy* talk, I could actually follow the
intended learning path and use the main C++ API for something. :-)
More information about the llvm-dev