[Mono-dev] Mono Tail Call status
Hi, what is current status of F# tail calls on Mono? I am doing a master thesis on functional languages in .Net and, for the practical part, I am planning to improve Mono F# support. Judging from the materials on the web, Tail Call Optimization is missing from Mono. Is this still true? If yes, what would be a good place to start? (I'm already familiar with basics of contributing to Mono) Any suggested readings, beside articles linked from discussion http://www.mail-archive.com/mono-devel-list@lists.ximian.com/msg21825.html ? Regards, Leszek 'skolima' Ciesielski ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Tail Call status
Hi, I'm not a Mono contributor, just a F# user. what is current status of F# tail calls on Mono? I am doing a master thesis on functional languages in .Net and, for the practical part, I am planning to improve Mono F# support. Judging from the materials on the web, Tail Call Optimization is missing from Mono. Is this still true? There are two bug reports related to F# tail calls: https://bugzilla.novell.com/show_bug.cgi?id=502575 https://bugzilla.novell.com/show_bug.cgi?id=476785 In simple cases, the F# compiler is able to replace the tail call by a while loop. When things get a bit more complex, F# compiler emits the .tail opcode. As far as I know, Mono is able to optimize some of them, but it fails in some cases (read file attached in bug 502575 for examples). As you are talking about F# support, I think the Reflection.Emit bug with generics is one of the other main problems. Many programs, even very simple ones, fail in F# Interactive. You see a few examples here: https://bugzilla.novell.com/show_bug.cgi?id=419828 -- Laurent ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Migration to GitHub completed!
Hi, pablosantosl...@terra.es pablosantosl...@terra.es writes: Congrats Gonzalo!!! Question: how long did the import take?? The actual import run takes about 2-3 hours. The whole process of debugging and fixing the import tool, fine-tuning the import, figuring out mappings between SVN committers and GitHub accounts, etc. took about a month. - Hari ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Tail Call status
On Fri, Jul 23, 2010 at 9:35 AM, Leszek Ciesielski skol...@gmail.com wrote: what is current status of F# tail calls on Mono? I am doing a master thesis on functional languages in .Net and, for the practical part, I am planning to improve Mono F# support. Judging from the materials on the web, Tail Call Optimization is missing from Mono. Is this still true? Yes. Although I prefer not to call it tail call optimization but proper tail calls. An optimization makes programs faster. Proper tail call makes programs work that wouldn't work without it. If yes, what would be a good place to start? (I'm already familiar with basics of contributing to Mono) Any suggested readings, beside articles linked from discussion http://www.mail-archive.com/mono-devel-list@lists.ximian.com/msg21825.html ? What's been said there still stands - you need a callee-pops-arguments calling convention. That is the biggest piece of the work to get proper tail calls. For an explanation for why you need callee-pops-args, see my diploma thesis: http://www.complang.tuwien.ac.at/schani/diplarb.ps Mark ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Proposed Patch - Google Native Client
Hi, I think the runtime changes now look mostly ok, if nobody from the runtime team has further comments, I will commit them with some coding style etc. changes when I come back from holidays. Zoltan On Fri, Jul 16, 2010 at 1:30 AM, Elijah Taylor elijahtay...@google.comwrote: Hi, here's an updated patch with your feedback addressed. I re-based the diff closer to head revision (r160382) to include the other changes of ours that already landed, as well as make sure we're still compatible with current Mono development. In general this diff should have a smaller impact on the .c files: mini-x86.c, exceptions-x86.c, tramp-x86.c specifically, and the Native Client changes are a little more grouped together rather than spread out. A couple of points separate from the feedback: 1) I fixed a bug in my implementation of genmdesc.pl changes, so that will be different from the previous patch 2) There's a small typo at head revision in mono/mini/tramp-x86.c which says rethow instead of reth*r*ow for your rethrow exception trampoline. This is also fixed in my patch. As always feedback is appreciated from everyone. -Elijah On Tue, Jul 6, 2010 at 6:35 AM, Zoltan Varga var...@gmail.com wrote: Hi, One possibility is to pad out all x86_prefix instructions to the nearest 32-byte boundary, but that could really bloat things depending on how often they're used. Do you have any idea of the prefix to non-prefix instruction ratio? It seems like it'd be pretty low based on looking at the code but I haven't looked at any actual metrics. I think that would be ok, they are seldom used. Zoltan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
