x86_64 port: final report

Blog post by xyzzy on Tue, 2012-08-28 09:57

Since the three-quarter term report, I have continued porting userland servers and apps. The app server is fully functional, as are Deskbar and Tracker and a few other apps. I also cross-compiled all of the basic development optional packages (GCC/Binutils, autotools, make, etc.) for x86_64. Another screenshot showing the current state of things is below:

As you can see, this looks pretty much like a regular Haiku desktop. There's still a lot of things missing, though - not many apps or drivers yet. However, most things should be fairly simple to get working, typically just a few compilation fixes.

As expected, I encountered quite a few bugs in getting to this point, such as app_server rendering issues and crashes. These were caused by things like 64-bit calculation issues and type mismatches between client/server code - there were a few cases of one side using int32 in messages and the other side using long. Not an issue on 32-bit architectures because int32 and long are the same, but long is 64-bit on x86_64 so there was a mismatch. The most difficult bug to track down was intermittent kernel panics, particularly when the system was under heavy load. In the end I found that this was caused by libsupc++, the GCC C++ runtime support library. This library is linked into the kernel (and any C++ apps) to provide support code for C++ features like RTTI (dynamic_cast). The problem was that kernel code for x86_64 needs to be compiled with the GCC flag -mno-red-zone, to prevent use of the "red zone" specified by the AMD64 ABI. This is an area below the stack pointer that is reserved for code to use for temporary storage without changing the stack pointer. This can't be used in kernel code because CPU interrupts would overwrite that area. libsupc++ was not compiled with that flag, so it was using the red zone which ended up getting corrupted if an interrupt occurred during a dynamic_cast. I fixed this by building a separate libsupc++ for use by the kernel with the correct flags. Once this was fixed, stability improved a great deal, and in fact it is now possible to build Haiku x86_64 from within itself without running into any problems!

The future work required on the port is basically just continuing to port apps and drivers, and building more optional packages. Having the development packages available means it is easy for others to help with this. I won't be doing too many more fixes in my branch, as I think it'd be better to wait until after it is merged into the main repository (which I hope will happen after the Alpha 4 release). I've already made changes to a lot of code and the likelihood of merge conflicts will increase if I continue to make changes in my branch.

If anyone would like to try out the port, you can grab the code from here (don't forgot to check out the x86_64 branch after cloning) and build an image using the usual build targets. Be warned though that it's received nowhere near as much testing as the x86 port, so it could eat your data, kill your cat, etc ;) If you run into any bugs, feel free to poke me on the IRC channel about it.

Finally, thanks a lot to my mentor, Ingo Weinhold, and the other Haiku developers for the useful feedback on my code, as well as Rene Gollent and others who have been testing the port and reporting bugs!


Re: x86_64 port: final report

Great success.
Now the guys from ports.haiku-files.org have a lot to do :-)

Re: x86_64 port: final report

Impressive! Seems this has been Haiku's most productive Summer of Code yet. Many thanks for your hard work.

Re: x86_64 port: final report

Thank you xyzzy for your hard work and dedication to your x86_64 project and to Haiku! You have done in just a few months that many thought would take many more months or years to accomplish! My thanks goes to you, xyzzy, and to the people who makes Google Summer of Code possible.

Now that the kernel and App server has been ported over to x86_64, I expect there will soon be a experimental build for testers in haiku-files.org. Once the port is fully complete (eg. drivers, servers, apps etc) those who run Haiku on 64 bit intel/amd computers should notice a performance increase! Especially those who has more than 4 gigs of ram in their system should notice this performance increase because at this point PAE (Phisical AddressExtension) will no longer be needed to map the memory addresses beyond the 32 bit range!

I look forward to testing this port, thanks xyzzy!

Re: x86_64 port: final report

x86-64's paging scheme actually looks a lot like PAE, the performance difference is more or less nonexistent (x86-64 mainly just adds one additional level to the page table). Furthermore > 4GB of RAM won't make any difference whatsoever to a basic Haiku install performance-wise. The biggest performance benefit from x86-64 comes from having additional architectural registers, and even that will mainly benefit only a handful of intensive algorithms and not so much the general case, since in most other cases that winds up being balanced out by code size being larger and thus less of it fitting into the CPU's cache at any given time.

Re: x86_64 port: final report

Just wondering, how much more work would it require for 32bit apps to run on 64bit haiku?

Re: x86_64 port: final report

In terms of the kernel support, there would need to be modifications made to support loading both 32 and 64-bit binaries (it only supports one or the other at the moment), need to switch the CPU to compatibility mode, and support 32-bit system calls (and converting the arguments from 32-bit to 64-bit).

For userland, I think the mechanism used to do GCC2/GCC4 hybrid builds could be reused, do a hybrid of x86_64 and GCC2 x86.

Re: x86_64 port: final report

I am interested in trying out the new 64-bit build of Haiku. I have some instructions I've written up for building Haiku within Lubuntu. I'm wondering how much different from those, the instructions for building the 64-bit version of Haiku would be?

I assume, obviously, you need to be running a 64-bit system, before you JAM a 64-bit build of Haiku from within Lubuntu or Haiku.

Also, which drivers (video, networking, etc.) are usable in Haiku-64? Can you create a CD .ISO (during the JAM process), to boot Haiku-64 from or do you need to use a different boot medium?

Re: x86_64 port: final report

No need to build from a 64-bit host system, the cross-tools will generate 64-bit code even if you're on a 32-bit host. Build them with ./configure --build-cross-tools-gcc4 x86_64 .

All the disk drivers are available, you should be able to build an ISO and boot from that. USB works too, should be able to boot from a USB stick, and use USB keyboards/mice. All the Ethernet drivers are available. Only the vesa graphics driver is included at the moment. There's no sound yet, and no filesystems other than BFS and ISO9660.

Re: x86_64 port: final report

Where can I send you my customized how-to (I wrote up myself), so you can look at it and show me specifically what needs to be typed in the Terminal, at what point? Do I simply post it here? I've got a nightly of Haiku on one system (I could use step-by-step instructs for building 64-bit Haiku on that, as well) and am trying to get Lubuntu running on my Acer Aspire 5560 laptop, but don't have wireless functioning (has to be manually installed or somesuch), so have to fix that first.

Re: x86_64 port: final report

I typed in:

./configure --build-cross-tools-gcc4 x86_64

And it says it's missing parameters.

So I typed: ./configure --build-cross-tools-gcc4 x86_64 ../buildtools/

And it worked!

However, after several minutes it ends with:

/home/luposian/haiku/buildtools/gcc/gcc/lto-compress.c:28:18: fatal error: zlib.h: No such file or directory
compilation terminated.
make[2]: *** [lto-compress.o] Error 1
make[2]: Leaving directory `/home/luposian/haiku/haiku/generated/cross-tools-build/gcc/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/luposian/haiku/haiku/generated/cross-tools-build/gcc'
make: *** [all] Error 2
ERROR: Building gcc failed.

Did it have the wrong parameters again or is there a bug in the build tools or...?

I'm following my "Build Haiku in Lubuntu" instructs (everything goes along fine), except changing the buildtools line to your instructs. That's where it fails and I'm stuck.

UPDATE: I just tried doing a standard GCC4 x86 tool build and it also failed! Same thing, too... no zlib.h. Ok, who's the wiseguy hiding the zlib.h file... give it to me, eh? :-D

Re: x86_64 port: final report

Sounds like your lubuntu installation's missing the zlib development package.

Re: x86_64 port: final report

Yup, that was it! Had to google "Haiku zlib.h", to find the solution, but once I put it in, the 64-bit tools built fine. Now I'm trying to figure out why trying to JAM a 64-bit build of Haiku is failing. If I type "sudo jam -q haiku-cd" (or haiku-image), it stops shortly after starting, ending at ATAChannel.o. If I type "sudo jam haiku-cd" (or haiku-image), it goes on a lot longer, but finally fails. The -q I think means to quit at the first substantial error.

I'm GITing everything from the same place I use, to do my 32-bit GCC4 builds from. Could that be causing the problem? Do I need to GIT the sources from xyzzy's (I hope I got his handle right) site, where he has his own 64-bit fork he's been working with?

UPDATE: Nope. GITing them from xyzzy's site has the same results. :-(

Re: x86_64 port: final report

Yes, you need to get it from xyzzy's github repo, and then you need to git checkout x86_64. All the work is currently in that branch. Note however that not all drivers have been made 64-bit safe yet, nor have all the apps been ported yet, don't expect a 100% normal Haiku out of it just yet.

Re: x86_64 port: final report

what about a x32abi port? is someone thinking about it?
i'm really looking forward an os with x32abi support...

Re: x86_64 port: final report

If you have an 32bit CPU or you want to be downward-compatible to 32bit, then taking the normal 32bit-OS.
If you have an 64bit CPU, then your disk space is big enough and CPU-speed is fast enough for 64bit pointer.

I really don't see any advantage of x32.

And there are a lot of situations, where I need big pointer, register, etc.
For example BigInteger calculations and so on are faster with an 64bit system then with x32.

Re: x86_64 port: final report

The reasoning behind the x32 ABI is that in a lot of cases you don't need a 64-bit address space, so by limiting to 32-bit pointers you reduce the overhead of calculations involving pointers (you only need to do 32-bit calculations rather than 64-bit). But because you're still in 64-bit mode, you get the benefit of certain features only available there like an additional 8 registers and IP-relative addressing that can help increase performance. So theoretically, x32 could be faster than normal 32- or 64-bit code. The benchmarks on the x32 site don't really tell much, though, I'd be interested to see a more comprehensive set of benchmarks.

Re: x86_64 port: final report

The last ones I saw was these benchmarks posted by one of the Intel devs as part of a x32 patch-proposal for LLVM:


Overall there's some nice gains, also x32 is a 'new' abi and chances are that still there are fine-tuning opportunities to be made in compiler optimization which can further yield performance.

How will be 32bit programs supported on it?

How will be 32bit programs supported on it?

Like on Windows and Linux with twice existing libaries (all in 32bit and 64bit)?

x86-64bit-Linux have in /lib and /usr/lib the 32bit libaries and in /lib64 and /usr/lib64 the 64bit libraries.
Binaries are in 32bit OR in 64bit in /bin and /usr/bin

64bit Windows doing it similar.
In C:\Windows\System32 are 64bit libraries and programs.
And in C:\Windows\SysWOW64 are the same libaries and programs in 32bit.
Yes, there are also notepad.exe, calc.exe, etc twice.
And for the installed programs existing different places, too.
In "C:\Program Files" are the 64bit programs and in "C:\Program Files (x86)" are the 32bit programs.

What will Haiku do?
Will be 32bit programs on 64bit Haiku supported?
If yes: Will be all libraries exiting twice?