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 ------------------------------------------------------------------------------ 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
