Posted Jun 27, 2012 15:49 UTC (Wed) by butlerm (subscriber, #13312)
[Link]
The porting effort for software to run on x32 is a rounding error compared to what would typically be required to universally use offsets instead of pointers in dynamically allocated objects.
Something like a JVM can do this reasonably easily because the JVM bytecode itself is pointer size independent. Making a comparable change to Firefox or Chrome without compiler support would be essentially impossible. It would amount to translating C and C++ into an entirely new dialect. The chances of the upstreams for something like Webkit merging that are basically non-existent.
Pettenò: Debunking x32 myths
Posted Jun 27, 2012 16:03 UTC (Wed) by gioele (subscriber, #61675)
[Link]
> The porting effort for software to run on x32 is a rounding error compared to what would typically be required to universally use offsets instead of pointers in dynamically allocated objects.
This kind of changes can be shoehorned into compilers and VMs. Even if you do not make changes to Chrome, just using something similar to JVM's compressed pointer in V8 may make it much less cache-hungry. The same argument can be made for any other JIT.
Also, please consider in the total x32 effort also the amount of changes, testing and support that compilers and distros will have to sustain to make x32 available to end users.
Pettenò: Debunking x32 myths
Posted Jun 28, 2012 5:25 UTC (Thu) by butlerm (subscriber, #13312)
[Link]
Any distribution that doesn't think x32 is worthwhile clearly isn't going to support it. If I were in charge of a general purpose distribution, I would be inclined to say that x32 might be worth supporting as a replacement for x86, but not in addition to it. The reason should be clear enough.