The spirit of BeOS was always forward thinking, Be light years ahead with reckless abandon…
What would happen if we switched primary build to x86_64, and moved GCC2 to Unsupported variant status?
The known problem is to compile a 64-bit Haiku, you need to compile a small part of the code as 32bit, namely the bootloader which is the one responsible for switching the machine to 64bit mode.
There are two ways to fix this: either by making our compiler and header files to support "multilib" mode so it can build both 32 and 64bit code, or make the system fully 64-bit by booting through UEFI instead of legacy BIOS. The latter would make us incompatible with early 64bit machines which were BIOS only, of course.
Once this issue is fixed we may or may not discover more problems.
I’m sorry, but that is a terrible idea. The stated purpose of Haiku is to act as a a 100% compatible replacement for BeOS R5. Granted that there have been minor adjustments to that goal, but to move to 64-bit would cut Haiku off completely from the existing BeOS software base, much of which is only available in binary form.
Once a functional R1 is out, of course, all that will no doubt change.
[quote=PulkoMandy]
you can’t compile 64-bit Haiku from inside Haiku currently[/quote]
I’m curious, what is preventing it from being compiled within 64 bit Haiku? What would it take to get there?
Hi,
The x86_64 port of Haiku is still missing several drivers which are not 64-bit safe yet, and a lot of packages in the Depot (including Qt, but that's not the only one). The latter will soon be solved by automated package building and uploading. There are also some rough edges in the debugging support (KDL and Debugger sometimes having trouble extracting a backtrace from a program, etc). And of course, you can't run the old BeOS apps on it. It is also not yet self-hosting: you can't compile 64-bit Haiku from inside Haiku currently, you need to be running Linux, BSD or Mac OS X. This is a major problem for people like me who are trying to use Haiku as much as possible, and probably the main reason I'm staying with the 32bit version for now.
BTW, If you haven’t played with x86_64 lately, it is DAMN solid, DAMN fast (faster than GCC2), Everything I tried works (sound, network etc…) Youtube seems to work better, and just feels more exciting… Sweet! IMHO. The only thing I see missing is QT, Correct?
-Shaka
This is statistically more or less inevitable. Almost nobody is a Haiku developer. This line of argument was a big favourite of Michael Phipps too, and it’s no better for another decade of attrition.
If you used it primarily as a C compiler I could largely buy this. Later C versions aren’t that exciting, and the low hanging fruit like updated standard headers could perhaps be bolted on by Haiku’s people. But in Haiku C++ is a primary language. It doesn’t fully support C++ 98, and doesn’t really attempt C++ 03, C++ 11, let alone C++ 14. Like Haiku’s kernel, code that will compile is actually going to be closer to “C with classes” and a sprinkling of sugar, than to modern C++ where it can rely on things like automatic type deduction.
[quote]and when it doesn’t, we have hybrid support anyway
[ . . . ]
Te reason we insist on gcc2 as the main API for as long as reasonably possible is so we can have a single compatibility break, when we switch to a new official compiler.[/quote]
But because, as you’ve said, “we have hybrid support anyway” you will in fact end up having to support, or explicitly and painfully abandon, your GCC4 ABI too. People can’t wait indefinitely for the new supported ABI, so they’re going to use the one that’s available, no matter how many “Danger, beware of the wolf” signs you post.
Either GCC4 ABI programs will stay working, or they will break; one means an ongoing effort to maintain a second userspace - a burden you’ve rejected, the other means that Haiku “compatibility” is immediately tarnished in the eyes of users, no matter how much you insist that they should have known, that they were warned or whatever.
C++ ABI juggling was a foreseeable problem of choosing C++. Everybody else has to do it too. Since the x86-64 ABI standardisation things are much less dramatic than they used to be, and as a tiny irrelevant OS Haiku will get to reap the advantage of that without having done any of the hard work. But it makes no sense to always fret about the next ABI change - if you can’t handle that then C++ was the wrong choice twenty years ago.
And still fourteen years into the project you don’t have a thunking layer. So you’ve got this unusual situation where your 64-bit OS is in all practical senses worse than the 32-bit OS because it doesn’t run the widely available 32-bit software.
More importantly than the instructions, there are more (and wider) general purpose registers. This provides a significant speed-up for tight inner loops in many programs, which you may or may not feel depending on how I/O bound they are.
I would like to point out that the benefits of Haiku X86-64 are actually small. There are no Haiku applications now that need more than 4GB of RAM. There are no server applications on Haiku that need mor e than 4GB of RAM. Typically you need more RAM on a workstation for stuff like image editing on PhotoShop,and video editing. On a server you need RAM for web serving with Apache, or databases with PostGres. We are not doing too much of that yet.
If you are using Haiku and doing stuff that needs more RAM, I for one would like to hear about it.
Thanks for all the responses! I was just throwing that out there to get people’s opinions and some tech info about the ramifications…
Having said that, I still feel we need to make steps towards the future BEFORE the elusive R1.
If for no other reason than to avoid all hell breaking loose the minute R1 is released! Everybody is saying “Once R1 is out THEN we’ll…<insert_big_change>”. Which could turn into another DANO… (change for change sake etc…)
Would switching to GCC4 Hybrid help move Haiku forward while maintaining the Prime Directive of BeOS compatibility? If so, why wait?
Always remember the goal of the game.
Nobody’s goal was to have an outdated system, it was more like to have the rocket ship BeOS continue to fly!
One last thing- It’s been a hell of a ride so far! Keep on keepin’ on!
Hi,
It's strange how most people complaining about gcc2 are usually not Haiku developers themselves. The compiler works reasonably well, and when it doesn't, we have hybrid support anyway so we can build some apps with gcc4 if needed.
What do you think we would win by switching to gcc4 hybrid? Not much, actually.
Te reason we insist on gcc2 as the main API for as long as reasonably possible is so we can have a single compatibility break, when we switch to a new official compiler. That may be gcc4, but it will probably be gcc6 or clang. It is simpler for us to have one single jump, and just two sets of libraries (gcc2 legacy and "current") instead of several sparkled along the line (gcc4, gcc5, clang, etc).
Regarding apps using more than 2GB of RAM, it's fairly easy to hit that limit if you open several heavy web pages in the web browser, and recently I was quite happy to have a 64-bit install so I could run bfs_recover on a disk with a lot of files (it took about 20G of RAM/swap).The other advantage of 64-bit HAiku is that it can use all the instruction set of 64-bit machine, while 32-bit Haiku is restricted to Pentium (MMX, no SSE or other fancy things). However, ffmpeg is able to detect the CPU used at runtime, and uses these instructions anyway when they are available. So, in the case where they matter most (media decoding), they are used anyway.