Google Wants LLVM To Mainline x32 ABI Support

[phoronix]

Phoronix: Google Wants LLVM To Mainline x32 ABI Support

The Google Native Client (NaCl) team is looking to upstream some of their LLVM changes such as support for Software Fault Isolation (SFI). As part of pushing forward the changes for Native Client in LLVM, they're also looking to see mainlined the x32 ABI support. X32 is the Application Binary Interface that looks to take advantage of common x86_64 CPU features like increased CPU registers and more instruction set extensions while using 32-bit pointers...

http://www.phoronix.com/vr.php?view=MTI3NTk

[duby229]

I'm sorry, but I just don't see the point in x32. It seems like a complete waste of effort.

[bnolsen]

I'm sorry, but I just don't see the point in x32. It seems like a complete waste of effort.

totally agreed. ram is so cheap this is silly.

[Veerappan]

totally agreed. ram is so cheap this is silly.

On newer Desktop/laptop machines, this is true. On an atom/brazos machine, there are sometimes hardware limitations to the amount of RAM the system can have... In those cases, the chip might be able to run 64-bit code (and get the new instructions and more registers), but it wouldn't hurt to have 32-bit pointers to items in RAM.

[Drago]

Not to mention that weak CPUs have way less caches.

[Koorac]

totally agreed. ram is so cheap this is silly.

It is not so much about reduced RAM usage. The important point is that with smaller pointers you can fit more into the CPU caches.
The biggest slowdown is usually cache misses, and those could be reduced with smaller pointers

[fernandoc1]

Only a little off topic, but it still related to Google's Native Client.
There are plenty of games, built with Native Client and they are of nearly quality.
I would like to point those from CoreOnline.com (a SquareEnix website), which includes: Lara Croft and the Guardians of Light.
Some of these games works really great on Linux if you have proper video cards with proper device drivers and the latest stable Linux version of Google Chrome.
Phoronix usually don't like to cover these titles.
In my opinion, Steam is the best thing ever on Linux gaming, but there are some other platforms on Linux, which are less known, but with great capabilities and are very innovative, like Native Client.

[XorEaxEax]

It is not so much about reduced RAM usage. The important point is that with smaller pointers you can fit more into the CPU caches.
The biggest slowdown is usually cache misses, and those could be reduced with smaller pointers

Exactly. Google's interest in this is that of the performance impact rather than ram usage impact.

[newwen]

Only a little off topic, but it still related to Google's Native Client.
There are plenty of games, built with Native Client and they are of nearly quality.
I would like to point those from CoreOnline.com (a SquareEnix website), which includes: Lara Croft and the Guardians of Light.
Some of these games works really great on Linux if you have proper video cards with proper device drivers and the latest stable Linux version of Google Chrome.
Phoronix usually don't like to cover these titles.
In my opinion, Steam is the best thing ever on Linux gaming, but there are some other platforms on Linux, which are less known, but with great capabilities and are very innovative, like Native Client.

I really thought nobody was using Native Client. It will boost very much their Chrome OS.
Anyway, being sandboxed, despite its benefits regarding security, I find it pretty limiting for real world apps, except games. If it can't even access the filesystem it is pointless to port any non-game app to Native Client for Chrome

[fernandoc1]

I really thought nobody was using Native Client. It will boost very much their Chrome OS.
Anyway, being sandboxed, despite its benefits regarding security, I find it pretty limiting for real world apps, except games. If it can't even access the filesystem it is pointless to port any non-game app to Native Client for Chrome

I really think that this is all the way opposite to your thought.
In HTML5 specification, there is a lot of APIs that allow people to access files in the Filesystem and to create a sandboxed filesystem for the Web Application.
There is no need for an application to have full and unrestricted access to the whole system, except if that application is something like Gparted or cfdisk or the Web Browser itself to actually manage access rights.
For example, why a Word Processor or a Spreadsheet, would need to access any file on your filesystem?

If you need to open a file that is in your USB Drive, just "upload" it to the application. This procedure could be even handled by the browser as a copy to the application Sandboxed filesystem, because on the modern HTML5 there is also support for offline applications.

The unique thing that is prohibitive is when you need to work with very very large files, so you really need to have direct access to the device where it is stored.

However, this is not something very common on peoples regular computing needs.

In my opinion in today's modern Web, there is really few situations that you would need something out of the browsers capabilities.