Re: [Tinycc-devel] Do we want a BSD license for tinycc?
Hi, On Tue, Apr 30, 2013 at 09:14:58PM +0200, Marc Andre Tanner wrote: The fear of proprietary forks seems unfounded because there is already a mature BSD licensed C compiler (clang) available for people to base their work on. Let's see.. $ size /opt/llvm/bin/clang textdata bss dec hex filename 389997781193992 54640 40248410266245a /opt/llvm/bin/clang I think TinyCC might be preferred by some people who just need a small scripting engine. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
Daniel Glöckner wrote: Hi, On Tue, Apr 30, 2013 at 09:14:58PM +0200, Marc Andre Tanner wrote: The fear of proprietary forks seems unfounded because there is already a mature BSD licensed C compiler (clang) available for people to base their work on. Let's see.. $ size /opt/llvm/bin/clang text data bss dec hex filename 38999778 1193992 54640 40248410266245a /opt/llvm/bin/clang I think TinyCC might be preferred by some people who just need a small scripting engine. TinyCC ist the only compiler which provides JIT compiling for ARM --Armin Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
On 5/1/2013 5:58 PM, Daniel Glöckner wrote: On Tue, Apr 30, 2013 at 09:14:58PM +0200, Marc Andre Tanner wrote: The fear of proprietary forks seems unfounded because there is already a mature BSD licensed C compiler (clang) available for people to base their work on. Let's see.. $ size /opt/llvm/bin/clang text data bss dec hex filename 389997781193992 54640 40248410266245a /opt/llvm/bin/clang I think TinyCC might be preferred by some people who just need a small scripting engine. I would vote for a BSD licensed tinycc (remembering that talk is easy, manpower supply is hard). Given a show of hands, I think BSD would come out on top. After all, it's not a state-of-the-art thingy with a huge potential market; CINT and Ch for example have not gained much traction beyond niche areas. Much more advanced compiled/JITed scripting engines like LuaJIT are already BSD licensed. LGPL holdouts can be removed in the BSD version and be relegated to legacy status. Perhaps big contributions can be evaluated early to assess deletions. The main problem is the issue of doing a thorough audit of code ownership. Of course, I'll leave that to those supplying the manpower... -- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
On 5/1/2013 7:10 PM, Armin Steinhoff wrote: Daniel Glöckner wrote: On Tue, Apr 30, 2013 at 09:14:58PM +0200, Marc Andre Tanner wrote: The fear of proprietary forks seems unfounded because there is already a mature BSD licensed C compiler (clang) available for people to base their work on. Let's see.. $ size /opt/llvm/bin/clang text data bss dec hex filename 389997781193992 54640 40248410266245a /opt/llvm/bin/clang I think TinyCC might be preferred by some people who just need a small scripting engine. TinyCC ist the only compiler which provides JIT compiling for ARM http://luajit.org/luajit.html http://luajit.org/performance_arm.html -- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
Le mercredi 1 mai 2013 05:54:54, KHMan a écrit : On 5/1/2013 9:51 AM, Rob Landley wrote: On 04/30/2013 11:53:31 AM, Daniel Glöckner wrote: On Tue, Apr 30, 2013 at 05:43:03PM +0200, Thomas Preud'homme wrote: As I already said privately, I'm fine with BSD-2-clause. Does that mean you prefer it over the LGPL? http://www.youtube.com/watch?v=SGmtP5Lg_t0#t=15m10s What about you, grischka? Which one do you prefer? Why on earth would that matter? I identified a dozen people I have to talk to just to get a clean version of the code in _my_ fork. You guys have been doing a mob branch for years, with random drive-by commits from people you don't even know, who have zero ongoing relationship with the project. What makes you think you _can_ relicense your version? I agree with Rob. Too many large and small contribs to be casually discussing about relicensing... I've been thinking about it as well. I wondered for instance about whether to ask people whose code constribution have been entirely rewritten since. On the one hand none of their code remains, on the other hand one could say the new code is just an improvement of the old one. It probably depends of the modifications made. Contacting everyone sounds impossible and it would thus require rewritting some bits. Maybe many many bits. And let me tell you I'm not overly excited about auditing the code ownership. Also, I already see several people against such a move. One of them wrote the arm support and added probably more code to tcc than I did. I don't feel like pushing the change. Best regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
On Fri, Apr 26, 2013 at 10:58:39PM +0200, Daniel Glöckner wrote: There are two things broken in the code generated by TCC: First of all TCC thinks it has to return the structure in memory pointed to by r0 and second it gets confused about where it stored r0 and instead reads the first float from the stack and interpretes that as a pointer. The latter should be fixed by the one-liner I just committed. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
Hi Daniel ARM hardfloat: fix struct return with float/double args Fixes the case where the structure is not returned in registers. I thought it was related to ret_2float_test At least on Rpi I still have: ret_2float_test... Segmentation fault C. P.S. Compiled from a fresh git -Original Message- From: tinycc-devel-bounces+eligis=orange...@nongnu.org [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Daniel Glöckner Sent: mercredi 1 mai 2013 16:40 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Recent changes segfault on Linux ARM On Fri, Apr 26, 2013 at 10:58:39PM +0200, Daniel Glöckner wrote: There are two things broken in the code generated by TCC: First of all TCC thinks it has to return the structure in memory pointed to by r0 and second it gets confused about where it stored r0 and instead reads the first float from the stack and interpretes that as a pointer. The latter should be fixed by the one-liner I just committed. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] ARM hardfloat prolog
Hi Thomas, I saw that you used the following line to store the floating point arguments that have been passed in fpu register: o(0xED2D0A00|nf); /* save s0-s15 on stack if needed */ In my 2nd edition ARM ARM this maps to the FSTMS instruction and there is a note allowing implementations to keep the values in an internal representation and just convert them to IEEE format for storing to memory. So I don't think we can use this instruction to store double arguments and need one FSTMS/FSTMD for each run of consecutive fpu registers of same precision to be stored. Or have read otherwise? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] ARM hardfloat prolog
Le mercredi 1 mai 2013 16:59:25, Daniel Glöckner a écrit : Hi Thomas, I saw that you used the following line to store the floating point arguments that have been passed in fpu register: o(0xED2D0A00|nf); /* save s0-s15 on stack if needed */ In my 2nd edition ARM ARM this maps to the FSTMS instruction and there is a note allowing implementations to keep the values in an internal representation and just convert them to IEEE format for storing to memory. So I don't think we can use this instruction to store double arguments and need one FSTMS/FSTMD for each run of consecutive fpu registers of same precision to be stored. Or have read otherwise? Nope, I didn't see that line. Please go ahead if you want to fix it, otherwise I'll do it later (I'm working right now). Best regards, Daniel Best regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
Hi Christian, On Wed, May 01, 2013 at 04:44:09PM +0200, Christian Jullien wrote: ARM hardfloat: fix struct return with float/double args Fixes the case where the structure is not returned in registers. I thought it was related to ret_2float_test At least on Rpi I still have: ret_2float_test... Segmentation fault well, it should still crash if you compile abitest.c with GCC, as the first of the two issues is not resolved. With TinyCC it should work though, judging from visual inspection of the disassembly. Which hardfp environment do you use for the Rpi? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
I simply do a ./configure Here are the lines I get gcc -o abitest-cc abitest.c ../libtcc.a -I.. -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -DCONFIG_LDDIR=\lib/arm-linux-gnueabihf\ -DCONFIG_MULTIARCHDIR=\arm-linux-gnueabihf\ -DTCC_TARGET_ARM -DWITHOUT_LIBTCC -DTCC_ARM_EABI -DTCC_ARM_HARDFLOAT -DTCC_ARM_VFP -lm -ldl -I.. ../tcc -B.. -I.. -I.. -I../include -o abitest-tcc abitest.c ../libtcc.a -I.. -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -DCONFIG_LDDIR=\lib/arm-linux-gnueabihf\ -DCONFIG_MULTIARCHDIR=\arm-linux-gnueabihf\ -DTCC_TARGET_ARM -DWITHOUT_LIBTCC -DTCC_ARM_EABI -DTCC_ARM_HARDFLOAT -DTCC_ARM_VFP -lm -ldl -I.. C. -Original Message- From: tinycc-devel-bounces+eligis=orange...@nongnu.org [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Daniel Glöckner Sent: mercredi 1 mai 2013 17:23 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Recent changes segfault on Linux ARM Hi Christian, On Wed, May 01, 2013 at 04:44:09PM +0200, Christian Jullien wrote: ARM hardfloat: fix struct return with float/double args Fixes the case where the structure is not returned in registers. I thought it was related to ret_2float_test At least on Rpi I still have: ret_2float_test... Segmentation fault well, it should still crash if you compile abitest.c with GCC, as the first of the two issues is not resolved. With TinyCC it should work though, judging from visual inspection of the disassembly. Which hardfp environment do you use for the Rpi? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc? / JIT
KHMan wrote: On 5/1/2013 7:10 PM, Armin Steinhoff wrote: Daniel Glöckner wrote: On Tue, Apr 30, 2013 at 09:14:58PM +0200, Marc Andre Tanner wrote: The fear of proprietary forks seems unfounded because there is already a mature BSD licensed C compiler (clang) available for people to base their work on. Let's see.. $ size /opt/llvm/bin/clang text databssdechexfilename 389997781193992 5464040248410266245a /opt/llvm/bin/clang I think TinyCC might be preferred by some people who just need a small scripting engine. TinyCC ist the only compiler which provides JIT compiling for ARM http://luajit.org/luajit.html http://luajit.org/performance_arm.html Interesting ! Thanks ! --Armin ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
On 04/30/2013 02:14:58 PM, Marc Andre Tanner wrote: On Tue, Apr 30, 2013 at 03:40:43PM +0200, grischka wrote: ... and since I got permission from Fabrice to use his original tcc code under a BSD license ... Actually it's a long standing offer from Fabrice, also repeated lately on the occasion of the 0.9.26 release. I don't know about longstanding offer but I did ask him about it a year ago: http://landley.net/notes-2012.html#14-05-2012 Specifically I wanted to do a kickstarter to hire _him_ to glue tcc and tcg together, and asked him to name his price. He said he wasn't interested. The PS I didn't reproduce in that blog entry was (rummages in email...) Message-ID: 4fb0ccef.1040...@bellard.org Date: Mon, 14 May 2012 11:14:23 +0200 From: Fabrice Bellard fabr...@bellard.org To: Rob Landley r...@landley.net Subject: Re: Contract query: How much to glue tcg to tcc and update tccboot? Hi, I had the same idea when I was working on TCC and QEMU. The code generator of QEMU is not generic enough to do it, but at that time I began to modify it to handle the missing bits. Unfortunately it is a large project and I lost interest in it. Maybe someday I'll be interested again in compilers (perhaps to do a mix between C Javascript), but now I have other projects which have a higher priority, so I cannot help you now. Regarding the licensing, I'd like to change the TCC license to BSD since a long time, so I see no problem with that. I would have to look at my old repository to see from which version it is safer to start. Best regards, Fabrice. On 05/11/12 20:55, Rob Landley wrote: Hello Mr. Bellard, I'd like to run a kickstarter to hire you to: 1) Adapt qemu's Tiny Code Generator to work as the back-end for your old Tiny C Compiler, to create a new qcc (QEMU C Compiler) that can produce output for the various targets qemu supports. 2) Resurrect tccboot with the result, and get it to boot a current (3.x) kernel to a shell prompt. (Another modified subset is fine, as long as it boots to a shell prompt.) 3) Release the result under a BSD license. Does this sound doable? If so, how much would you charge (so I know how much to ask the kickstarter for), how long do you think it might take (ballpark), and when might you be available to start (if we can get you the money by then)? (I.E. it would take me a dozen fortnights, cost my weight in canadian 'toonie' coins, and the next open slot in my schedule is 37 years from now.) --- Optional details: My notes on this project, from when I tried to do it myself, are at: http://landley.net/code/tinycc/qcc/todo.txt I can maintain this after it works, I just don't know enough to make it work in the first place, and have been trying to find time to learn for years now but keep growing _other_ projects instead (toybox, aboriginal linux, I accidentally became linux-kernel Documentation maintainer...) I have no particular interest in the current no releases in 3 years tcc mob branch, and am just as happy for you to start with your old code if you prefer. If you want anything out of my old tcc fork, I hereby grant it to you under the same BSD license as tcc/tcg. It doesn't need multilib, being able to build arm-tcc and similar would be fine, and probably the common case given the need for libc, libtcc, crtbegin, and so on. (Being able to specify code generation with the same granularity as qemu's -cpu option would be nice, but not a huge deal in the absence of any real optimization.) Eventually I'd like to busyboxify tcc/qcc, I.E. make it so the front-end recognizes whether it's called as cc/cpp/ld/as/strip and reacts accordingly. But I can handle that part later, and make its command line parsing understand more gcc-isms if necessary. I wrote some notes about that years ago here: http://landley.net/code/tinycc/qcc/commands.txt I don't care about C++. The missing C99 bits from your old tccboot notes would be really nice, though. Simple dead code elimination would be really nice. (Busybox depends on it to avoid linker calls to undefined functions.) Just detecting if (0) constructs after constant propogation and suppressing output (or diverting output to a ram buffer that gets discarded) would be plenty. But if that sounds out of scope, I could probably tackle that after the fact too... Thanks for your time, Rob This was the first public statement from him I could find on the matter. (If he mentioned this before then, could you point me at where?) So the questions is: Do you people want, is it possible, what would it take - to change our tinycc code's license from LGPL to a BSD-like one (such as below). I am interested in a quality C compiler which
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
On Tue, Apr 30, 2013 at 07:12:50PM +0200, Daniel Glöckner wrote: On Tue, Apr 30, 2013 at 07:07:34PM +0200, Thomas Preud'homme wrote: Mmmmh. Overall I'm more a (A|L)GPL guy but I choose different license for different project. For tcc I thought it could make sense since we have only libtcc has static lib and many people seem to build stuff around it. And if I volunteer to extend the Makefile for a shared libtcc? We already have rules for libtcc.so.1.0 and libtcc.dll in our Makefile. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] ARM hardfloat prolog
On Wed, May 01, 2013 at 05:02:54PM +0200, Thomas Preud'homme wrote: Le mercredi 1 mai 2013 16:59:25, Daniel Glöckner a écrit : In my 2nd edition ARM ARM this maps to the FSTMS instruction and there is a note allowing implementations to keep the values in an internal representation and just convert them to IEEE format for storing to memory. So I don't think we can use this instruction to store double arguments and need one FSTMS/FSTMD for each run of consecutive fpu registers of same precision to be stored. Or have read otherwise? Nope, I didn't see that line. Please go ahead if you want to fix it, otherwise I'll do it later (I'm working right now). I did some more research. ARM ARM 2nd edition (= Issue E) has several paragraphs below figure 2-1 in chapter C2 talking about that no assumptions can be made as to how single-precision registers overlap double-precision registers and that the value of double-precision registers after their corresponding single- precision registers have been loaded with a value becomes UNPREDICTABLE. Issue I, which can be downloaded after registering with ARM, replaces that half page of text with The mapping between a double-precision register and its pair of single-precision registers is as follows: - S2n lies in the least significant half of Dn - S2n+1 lies in the most significant half of Dn. So we are safe with the current implementation, at least on little-endian ARM. On big-endian ARM the halves will have the wrong order if we don't use FSTMD, but there is a lot more that needs to be done until we support big-endian ARM. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
