Re: [gccsdk] Development roadmap proposal
On Mon, May 24, 2010 at 01:18:50AM +0100, John Tytgat wrote: I've tried out this idea in a separate branch and it turns out more or less what I thought it would be: - SCL based programs have now network support (back). - SCL based programs can now be written in C++ and use STL. We still need to investigate exceptions and module code. - Less ugly hacks in our gcc patches to have multiple runtime libraries in one build tree as now from gcc pov there is only one runtime library. That sounds really useful - thanks for that. It saves a lot of messing around with TCPIPLibs etc that we used to do in Norcroft days. Theo (who hasn't had a chance to do much recently) ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Development roadmap proposal
In message ae6c5cd050...@hobbes.bass-software.com John Tytgat john.tyt...@aaug.net wrote: 4. Merge SCL stubs (libscl) and UnixLib : not really convinced yet this would be an overall win but again worthwhile to investigate. Pro: - The reasoning is that currently libscl is missing out network/socket support which is a pity as we can't build network related modules (I don't think libscl has any advantages on UnixLib for normal applications, binary footprint size aside). - We could solve this particular network issue by migrating the relevant bits from UnixLib to libscl but it could very well be that we get nearly freebies as well by doing the libscl UnixLib merge : pthread support (perhaps), C++ (because missing runtime routines are available as UnixLib runtime routines). - It would eliminate several nasty hacks in our gcc tree to have two runtime libraries which are enabled/disabled depending on the multilib configuration we're building. The basic idea is that we still have this one unified runtime library between SCL and UnixLib mode based on the presence/absence of -mlibscl option in the current multilib configuration. This would also help out with point 5. Contra: - It risks to complicate the code base. I've tried out this idea in a separate branch and it turns out more or less what I thought it would be: - SCL based programs have now network support (back). - SCL based programs can now be written in C++ and use STL. We still need to investigate exceptions and module code. - Less ugly hacks in our gcc patches to have multiple runtime libraries in one build tree as now from gcc pov there is only one runtime library. The price to pay is indeed that UnixLib becomes slightly more complicated. After weighting the pros cons I've decided that it was still worthwhile to go for it so I've merged this change to trunk. There are still some rough edges to smoothen out. So for those following the trunk changes and building their own cross-compiler, please do now a full clean build. John. -- John Tytgat, in his comfy chair at home BASS john.tyt...@aaug.net ARM powered, RISC OS driven ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Development roadmap proposal
John Tytgat wrote: Before I merge my developers/joty/binutils-gcc-separation branch to trunk, I would like to hear some feedback of people having tried out this new build system and hopefully confirming this turns out to be easier and less prone to subtilities, like e.g. we got in URL:http://www.riscos.info/pipermail/gcc/2009-November/004976.html. So anyone who like to spend some CPU cycles and bandwidth on their Unix alike computer (especially interested in Ubuntu 9.10 and Cygwin users), please try out the following: I have build what appears to be a working Firefox with this toolchain, so that is a thumbs up. This is under Debian unstable. I'll be interested to see how later versions of GCC perform, and if they given meaningful performance improvements, etc. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Development roadmap proposal
On Mon, 2010-01-04 at 23:04 +, Chris Gransden wrote: John Tytgat wrote: In message ae6c5cd050...@hobbes.bass-software.com John Tytgat john.tyt...@aaug.net wrote: If last command ends with something *different* than Built and installed GCCSDK cross compiler ok. Check out the README for examples of how to use the cross compiler or Autobuilder. please send me the 'build-cross-output.txt' log file, otherwise just an ack it worked on my XYZ system would be greatly appreciated. It worked on Ubuntu 9.10 x86_64 here. Same here, and also on Ubuntu 9.10 x86_64. Didn't try the resulting compiler though. Cheers, Jan-Jaap FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family! Visit http://www.inbox.com/photosharing to find out more! ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Development roadmap proposal
Hi John, 5. Since several of years there is a new kid around the block in 'free' compiler land : LLVM http://www.llvm.org/. Basically it is a compile infrastructure/JIT/code transformer/code analyser/etc of which one of its usecases is just compile C/C++ with apparently respectful or even impressive results. The C/C++ frontend is still a bit immature and not 100% ready for cross-compile purposes but I've already been playing a bit with it (gccsdk/branches/joty/llvm) to get a better understanding what this could mean as RISC OS compiler. Out of curiosity, were you playing with llvm-gcc, which is GCC for the front-end and LLVM for the back-end, or Clang, their new C/C++/Objective C/etc. compiler that doesn't use GCC and is aimed at being a faster compiler, more cleanly implemented? http://llvm.org/cmds/llvmgcc.html http://clang.llvm.org/ Cheers, Ralph. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Development roadmap proposal
In message 20091229172732.6d56b5...@blake.inputplus.co.uk Ralph Corderoy ra...@inputplus.co.uk wrote: Out of curiosity, were you playing with llvm-gcc, which is GCC for the front-end and LLVM for the back-end, or Clang, their new C/C++/Objective C/etc. compiler that doesn't use GCC and is aimed at being a faster compiler, more cleanly implemented? I tried both but settled for Clang as this is what the goal is. And it is actually Clang which is not yet cross-compile friendly (cfr. URL:http://clang.llvm.org/UniversalDriver.html). John. -- John Tytgat, in his comfy chair at home BASS john.tyt...@aaug.net ARM powered, RISC OS driven ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
[gccsdk] Development roadmap proposal
With GCCSDK GCC 4.1.1 Release 2 now being out of the door, I would like to propose some development ideas and would appreciate some feedback. For all clearness, this is what I can see myself doing for the coming months/year(s ?) but not a promise it will actually be done. If other people want to help out, of course feel free to join ;-) First of all, as some of these following ideas can be quite disruptive, I've created a stable gccsdk/branches/release_4_1_1 branch where we can do all assumed safe bug fixing and this could possible be used to spin off a GCC 4.1.1 Release 3 from it. 1. Some time I've investigated to upgrade binutils 2.17 we're currently using, to 2.19 (atm 2.20 is the latest release) while sticking to the stable GCC 4.1.1. Frankly this turned out to be a nightmare as the latest binutils and gcc releases have migrated to autotools 2.64 and having to use in the same tree autotools 2.64 (for binutils 2.19/2.20) and autotools 2.59 (for gcc 4.1.1) is just asking for trouble. Hence, I've experimented to build binutils and gcc separately instead of doing this in one tree and that works out fine (see svn gccsdk/branches/joty/binutils-gcc-separation). This allows us to have different autotools versions to be used and migrate binutils and gcc independently from each other. This change is a also using a Makefile instead of the build-it script which allows more easily to continue (or re-do a part of) the total build. Actually I plan to merge this to trunk very soon. 2. Upgrade gcc 4.1.1 to something more recent. I did some experiments with 4.4.0 and got reasonably far but it is too soon to know for sure if this is going to work and be stable. BTW, that's another reason to have binutils and gcc built separately so that the binutils upgrade is not blocked by the gcc one. 3. I'm wondering if it wouldn't be worthwhile to have UnixLib configurable for AEBI, i.e. basically no longer use stack chunks as mandated by APCS-32. It would free more registers for general use, have less prologue overhead and we can probably more easily fallback on existing code for shared libraries, thread support, debugging. Note the R9/SWI calling convention is not something we can change of course. Looks worthwhile to investigate and experiment with and could help with trying out point 5 (see below). Note I don't want to remove APCS-32 capability of UnixLib for the time being. 4. Merge SCL stubs (libscl) and UnixLib : not really convinced yet this would be an overall win but again worthwhile to investigate. Pro: - The reasoning is that currently libscl is missing out network/socket support which is a pity as we can't build network related modules (I don't think libscl has any advantages on UnixLib for normal applications, binary footprint size aside). - We could solve this particular network issue by migrating the relevant bits from UnixLib to libscl but it could very well be that we get nearly freebies as well by doing the libscl UnixLib merge : pthread support (perhaps), C++ (because missing runtime routines are available as UnixLib runtime routines). - It would eliminate several nasty hacks in our gcc tree to have two runtime libraries which are enabled/disabled depending on the multilib configuration we're building. The basic idea is that we still have this one unified runtime library between SCL and UnixLib mode based on the presence/absence of -mlibscl option in the current multilib configuration. This would also help out with point 5. Contra: - It risks to complicate the code base. 5. Since several of years there is a new kid around the block in 'free' compiler land : LLVM http://www.llvm.org/. Basically it is a compile infrastructure/JIT/code transformer/code analyser/etc of which one of its usecases is just compile C/C++ with apparently respectful or even impressive results. The C/C++ frontend is still a bit immature and not 100% ready for cross-compile purposes but I've already been playing a bit with it (gccsdk/branches/joty/llvm) to get a better understanding what this could mean as RISC OS compiler. So far, I'm well impressed as well and I think we should further followup on this. Hence, also the reason to have point 3 so that we don't have to initially go for APCS-32 support (if libscl support is wanted for llvm, APCS-32 support is required of course). I won't rule out that it might be more interesting on the long run to invest in LLVM on RISC OS and forget about upgrading GCC to a later version (point 2 above). Looking forward to some feedback, and perhaps there are some other ideas which can be put on the table as well ? John. -- John Tytgat, in his comfy chair at home BASS john.tyt...@aaug.net
