One interesting approach to stack handling they suggested in the "Cheney on
the MTA" paper was using "alloca" with a negative parameter to *deallocate*
stack space. In their case it was relatively safe because they know that
all the stack frames are dead, but in your case you might be able to make a
similar assertion, perhaps for some functions you'd know that the current
stack frame is always dead and you will always use values from the "parent"
by passing a pointer to all the desired state into that function.
Another portable approach to tail calls in C/C++ is trampolining, but that
is costly in runtime performance because a trampolined call is far more
expensive than a regular call.
A hybrid approach with trampolining might be OK, though - perhaps
procedures can be "sharded" into smaller functions and the trampolining
technique is used to move between shards. Then maybe most calls don't have
to use the trampolines. Procedures that never yield control could be
converted into regular functions, too, which might alleviate the problem a
bit.
On Sun, Nov 25, 2012 at 11:55 PM, john skaller <
skal...@users.sourceforge.net> wrote:
>
> On 26/11/2012, at 4:19 PM, Dobes Vandermeer wrote:
>
> > 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).
>
> Yes, but the standard C calling convention in LLVM doesn't allow tail
> calls.
> I'm not sure why -- no one uses the archaic caller pop protocol in C
> these days (except for varargs).
>
> >
> > 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.
>
> Ooo .. good point. Thanks for bringing that up.
>
> > There are some advantages to using the MSVC linker on Windows, it seems.
>
> When in Rome .. :)
>
> >
> > 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.
>
> Yes. Erick did some work to support LLVM, but I had to throw it out when he
> left.
>
> >
> > As usual the decision boils down to finding some sort of target use
> cases and accept the loss of the others.
>
> Indeed.
>
> > 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.
>
> As a general purpose language, it's not really targeting a particular
> platform
> or industry area, rather a kind of development: for people that want
> security/safety,
> performance, rapid development, and a high level of reuse (including easy
> binding
> to C/C++ libraries).
>
> We have most of that, the main cost is complexity. Eg you can only read
> channels
> in top level procedures, you have to be careful about using variables
> before
> they're initialised (etc etc). And stability.
>
> The original problem can be solved in principle -- the problem is that it
> depends
> on the quality of C/C+= compiler and most of them are not very good at
> handling big functions. They're biased heavily towards the kind of code
> people write. LLVM has an advantage here -- it's easy to make a tool
> from it that simply omits optimisations that break on large functions.
>
> It's pretty bad. I have a simple test case. actually
> test/regress/rt/tuple-02.flx:
> with clang on -02:
>
> Total Execution Time: 92.0530 seconds (92.0723 wall clock)
>
>
> ---User Time--- --System Time-- --User+System-- ---Wall Time---
> --- Name ---
> 27.5508 ( 30.2%) 0.1963 ( 25.7%) 27.7470 ( 30.1%) 27.7566 ( 30.1%)
> Value Propagation
> 26.1573 ( 28.7%) 0.1526 ( 19.9%) 26.3099 ( 28.6%) 26.3122 ( 28.6%)
> Value Propagation
> 6.3041 ( 6.9%) 0.0269 ( 3.5%) 6.3310 ( 6.9%) 6.3340 ( 6.9%)
> Global Value Numbering
> 5.4471 ( 6.0%) 0.0172 ( 2.3%) 5.4644 ( 5.9%) 5.4648 ( 5.9%)
> Merge disjoint stack slots
> 4.6219 ( 5.1%) 0.1389 ( 18.1%) 4.7607 ( 5.2%) 4.7609 ( 5.2%)
> X86 DAG->DAG Instruction Selection
> 3.9909 ( 4.4%) 0.0024 ( 0.3%) 3.9933 ( 4.3%) 3.9935 ( 4.3%)
> Eliminate PHI nodes for register allocation
> ...
>
> ValuePropagation is killing it. Its twice as fast if I just break up the
> Felix code into 4 noinline functions, and 8 times faster if I split
> the code into 16 or so functions (one per print statement).
>
> With -O1 it compiles in a reasonable time. Felix now defaults clang to -O1,
> otherwise I can go to bed and wake up to find the test suite is STILL
> running.
>
> Generating everything in a single top level C function solves the pain
> of being restricted to C's archaic control model in a nice way.
> Using assembler non-local goto hacks is pretty ugly (and it doesn't
> really solve all the problems, just one of them).
>
> --
> 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
