[haiku] Re: Binary Compatibility Combinations

  • From: André Braga <meianoite@xxxxxxxxx>
  • To: haiku@xxxxxxxxxxxxx
  • Date: Mon, 7 Sep 2009 13:54:33 -0300

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.

Other related posts: