2009/9/7 Ingo Weinhold <ingo_weinhold@xxxxxx>: > Sorry, I certainly didn't want to imply retarded. A bit annoying maybe, but > not retarded. ;-) Now you're being gentle with the "a bit" part :) >> I'm not taking offense at your tone just because you seem to think >> that LLVM is some "interesting technology that will spin on its wheels >> for at least 4 years more before really going anywhere" > > At least with respect to what would be useful for Haiku that pretty much hits > the nail on the head. I beg to differ... > I don't disagree. But to stick with the carpenter metaphors: LLVM seems to be > your hammer and everything is looking like a nail. At least ATM I don't see > that many nails in Haiku. I guess eventually we do want move away from gcc, > but until clang/C++ is complete this is not possible. LLVM at the back end enables such a large amount of uses that it's not even funny. For one, it makes the whole 32bit/64bit discussion pretty much mute, since you can write your code for arbitrary precision, even non-power-of-2 ones, and the JIT or the assembler will produce the correct target machine code for you. Not only that, but being an abstract low level language, LLVM is what enables OpenCL, being used at Apple, NVIDIA and Rapidmind for seamlessly running the *same code* on the GPU or the CPU depending on their capabilities and load. With the rebirth of DSPs in the guise of GPGPU, and each of those coming from a different vendor, this is the way forward and for the first time ever the whole industry (the backers of OpenCL) agrees with that. Think the WORA motto of Java, only done right. Then there are the code analysis tools. And the JIT. And what they call "life-long optimisation" strategies. And... > Using LLVM bitcode for architecture independent binaries sounds like a fun > idea, but Haiku runs only on one architecture yet and -- call me a pessimist > -- I don't see that change anytime soon. Well, this whole thread is half about GCC2 and GCC4 and half about targets which Haiku haven't been ported to yet, and how it could turn into an exponential explosion of targets of care is not taken, right? So there, the problem has been brought up and I suggested that (same) solution (I've been suggesting the other times this has been brought up). Besides: I can tell you that there is quite the interest on Haiku running on ARM, and I'm not talking about PDAs, tablets, smartphones OR netbooks. Still on the embedded market, though :) Next time there will no doubt be a discussion about the PPC port or the resurgence of MIPS in the form of Loongson, or renewed interest in SH, or whatever gets (re)invented next. So why not (at least plan for) kill(ing) all birds with one (low-level virtual) stone ;) > The next supported architecture will > probably be Intel 64, but there we should be able to run IA-32 code without > too much hassle (and might even want to continue staying BeOS compatible). > Besides even when Haiku runs on three or four different architectures, I > wouldn't consider cross-compilation a big deal, if the respective tools are > provided and are easy to use. It has never worked before for any OS on any architecture to expect (native, commercial) application makers to produce and test binaries for 2+ architectures. The few times it worked was for opensource apps with volunteers maintaining the "ported" code. Part of the success of Java is the WORA thing, indeed. Same applies to dynamic languages like Python and Ruby. Back of the envelope, I'd say that having a interpreter that enables machine-independent programming contributed at least 10% for the popularity of those languages. > So, to make my point entirely clear: LLVM is a cool technology, but ATM I > don't see how it could help Haiku at the OS level. Note, that I'm not > speaking of LLVM *under* Haiku. Wow. If target-independent native binaries, life-long optimisation and state-of-the-art refactoring and coverage tools don't entice you at the OS level, I'm out of ideas o_O Cheers, A.