svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib

[Adrian Chadd]

Although non-LLVM may just die, I'd like people to please consider
what it takes to bring a new CPU architecture/platform up and how,
well, that support typically doesn't make it into the public LLVM
source straight away.

So if we want to be taken seriously by those funny companies that make
CPUs, then:

* we still need external toolchain support;
* .. and that may be LLVM, but it may not be the LLVM that you
currently have in HEAD, with the current set of expected features in
our LLVM.



-a


On 4 April 2014 07:17, Jordan Hubbard <jkh at ixsystems.com> wrote:
>
> On Apr 4, 2014, at 7:03 PM, David Chisnall <theraven at FreeBSD.org> wrote:
>
>> That said, I think we're increasingly going to be using LLVM for things that are beyond just simple AOT compilation, so platforms with no LLVM back end are likely to be left behind.
>
> Amen, and a topic worth an entire discussion in its own right, but I'll spare us that and leave the topic with just one quick anecdote:  When we ported MacRuby to LLVM, thus creating in effect a ruby JIT compiler, we were pretty amazed at how quickly the work progressed and how good the performance of the resulting code was.  MacRuby later died for other reasons, but its JIT/AOT compilation abilities were amazing enough that we were left wondered why the Python and Perl folks weren't stampeding over themselves to follow suit.
>
> I think the answer there was that they'd already rolled their own bytecode systems, as ultimately did Ruby, and had too much invested in those technologies, but I'm still holding out hope that the "everyone but C/C++" world of languages will eventually converge on LLVM, as seems to be slowly happening with projects like Rubinius and Numba.  Not relevant to FreeBSD right now, but who knows the future?
>
> - Jordan
>
>
>
>