On 14/05/2008, at 1:11 PM, Erick Tryzelaar wrote:
> On May 13, 2008, at 12:57 AM, john skaller wrote:
>
>> The likely problem is that no two languages have the same
>> architecture,
>> if they did .. why bother with another language?
>>
>> C and C++ are exceptions here, since one is derived from another.
>
>
> Yeah, I understand that. Got a better idea? We might be able to go
> directly to source, but then we'd have to handle the SSA stuff
> ourselves (do we do this already?). There's also the overhead of
> having to write out the assembly then load it back in for llvm to
> process it. So, to walk through a basic example. Say we have this
> simple code:
>
> fun foo (a:double, b:double) => a*a + 2.0*a*b + b*b;
> val a = 1.0;
> val b = 2.0;
> val c = (foo (a, b)) + 3.0;
> printd d;
>
> If we do a straightforward translation to llvm we should result in
> approximately this:
[]
>
> However, will it work with control flow? If we then have:
>
> fun foo: unit -> double = "...";
> fun bar: unit -> double = "...";
> fun baz: unit -> double = "...";
> fun boo (a:double) = {
> val b = if a == 0 then foo() else bar();
> return b + boo();
> }
>
>
> We need to generate this:
>
> declare double @foo()
> declare double @bar()
> declare double @baz()
>
> define double @boo(double %a) {
> entry:
> %tmp = fcmp one %a, 0
> br il %tmp, label %then, label %else
>
> then:
> %tmp1 = call double foo()
> br label %after
>
> else:
> %tmp2 = call double bar()
> br label %after
>
> after:
> %tmp3 = phi double [ %tmp1, %then ], [ %tmp2, %else ]
> %tmp4 = call double baz()
> %tmp5 = add double %tmp3, %tmp4
> ret double %tmp5
> }
>
>
> Hmm. That might work as well. I'm not sure if it'd capture all the
> semantics that we need, but it might be a good way to start.
Yes, it will work easily. Just look at flx_gen. We have to implement
each of the BEXE_* and BEXPR_* things in LLVM.
Control flow is simple, if I recall:
BEXE_goto label
BEXE_ifgoto (cond, label)
are all you need.
regexp, reglex, grammar stuff would work much like now, by making
C/C++ code, the only trick being to wrap the top level entry C/C++
code with LLVM binding (which presumably it has).
>
> In the long run, we still could go with the scheme-based FFI, but just
> make no attempt to share the same variants as the c++ FFI.
A better option is Ocaml 3.11 with dynamically loadable back end.. in
the
mean time just copy the back end, rename it llvm_*, and use a simple
switch to select C++ or LLVM back ends.
--
john skaller
[EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
