Interesting restriction. I was curious so I googled the problem and found
that you can kind of handle it using tail calls (i.e. a tail call is a kind
of goto as long as you pass everything along).
LLVM also makes interoperating with C++ compiled object files tricky. If
you comply with the clang front-ends name mangling you'll be OK for clang
but you won't be able to link with MSVC or gcc object files. There are
some advantages to using the MSVC linker on Windows, it seems.
I guess it could be that you just have LLVM as an "optional" backend and
continue to support generating C++ but that seems troublesome to me because
it means maintaining and updating two backends - which is probably too much
work at this point.
As usual the decision boils down to finding some sort of target use cases
and accept the loss of the others. If you are interested in helping people
write network applications (the node.js crowd) then it's probably safe to
start with Linux as the main target and try to build a following from
there. That's how things went with node.js. If you're after gamers you
should buy a Windows image for your computer and get the Windows thing
working well. For mobile ... or scientific computing ... all have ways to
focus and features and platforms to trim away.
On Sun, Nov 25, 2012 at 4:06 PM, john skaller <skal...@users.sourceforge.net
> wrote:
> I've been looking at LLVM as a possible back end for Felix.
> Unfortunately it seems too C-centric.
>
> The basic problem is that LLVM abstracts parameter passing conventions,
> and provide only one way to transfer control; subroutine call.
>
> The requirement for a decent machine is PDP-11 branch and link instruction.
> This puts the "return address" into a register. We also need indirect jump,
> or jump to register. This allows control transfer globally without
> mentioning
> the evil stack.
>
> I think this can be "fixed" by a target specific parameter calling
> convention,
> however that means writing a back end for every processor, defeating
> the hoped for utility.
>
> C has the same problem. Felix gets around it using assembler jumps,
> and hacking up switches in-lieu of computed gotos. Then it returns
> the usual way from a procedure to the scheduler which resumes something
> else as required.
>
> The problem is that this only works for top level procedures, not
> functions,
> because functions use the machine stack for the return address.
> Apart from FFI issues, there's a performance reason for this:
> nested function calls form a single expression tree which is easy
> to analyse recursively with pattern matching.
>
> Three adress code (all procedures) requires pointers to temporary
> store and is required data flow analysis to analyse in general
> (even if using single assignments, i.e. linear types). In turn this
> is very hard if not impossible in complex code to analyse correctly,
> and would also kill the compiler performance since in general
> data flow is O(N^3).
>
> --
> john skaller
> skal...@users.sourceforge.net
> http://felix-lang.org
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Felix Language" group.
> To post to this group, send email to felix-langu...@googlegroups.com.
> To unsubscribe from this group, send email to
> felix-language+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/felix-language?hl=en.
>
>
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
