In message <20121015183937.GX12492@chiark.greenend.org.uk>
Theo Markettos <theo@markettos.org.uk> wrote:
> I notice John did some work on LLVM two years ago:
> http://www.riscos.info/websvn/listing.php?repname=gccsdk&path=%2Fbranches%2Fdevelopers%2Fjoty%2Fllvm
>
> It's still quite a fast-moving target. The ARM support is there but it
> keeps breaking due to changes in the core, and ARM are working on the
> testsuites to pick this up when it happens. As they have customers
> interested in all three, ARM plan to support the three available toolchains
> (GCC, LLVM, their own compiler) as much as they have sufficient manpower to
> do so. LLVM looks considerably easier to work with than GCC, and not
> subject to the GPL conditions (awkward for some ARM customers).
That last point is something I don't understand and believe it is just FUD.
GCC does not impose any restrictions on its use or on the binaries it
produces (any gcc provided runtime library which could get used by the
produced library has the GCC Runtime Library Exception).
> As for the implications for RISC OS generally... I don't know how much
> specifics we'd need for RISC OS, but I suspect it would be a lot easier than
> the previous work on GCC. So if someone feels like having a go...
>
> John, do you want to say how far you got with LLVM?
Basically the work I did in that svn branch was to investigate one of our
options for providing RISC OS compiler support in the future (time and
remaining passion permitting).
The work consisted of adding very basic (and incomplete) support for EABI
in UnixLib (that's now part of UnixLib @ trunk, so reusable) and build
llvm-gcc/clang as cross-compiler which produced static ELF binaries
usable under RISC OS. A bit to my surprise that worked well for moderate
simple sample programs after only a reasonable amount of work.
The only thing I'm a bit unsure of is how well its ARMv4/ARMv5 support
is as the current development focus is very much on ARMv7 (and a bit on
ARMv6).
So IMHO LLVM/Clang + EABI is a reasonable candidate as a future RISC OS
compiler.
The biggest reason for that success is the EABI choice as the alternative,
APCS-32, would require the development of a new target (basically also the
biggest and most trickiest work done for gcc as well). And this adds
another reason to seriously consider adopting an EABI flavoured target,
instead of APCS-32, for any future compiler work.
If we would adopt EABI as new target, then the gcc compiler option remains
open and would make most of our patches redundant which is always a pro,
the less custom changes we have, the better.
The question is whether there is sufficent momentum from RISC OS developer
community to support this all.
John.
--
John Tytgat, in his comfy chair at home BASS
John.Tytgat@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
No comments:
Post a Comment