OSX i386/x86 and x86_64 - time to switch supported platforms?

I originally posted this on haskell-GHC-users, but was curious how the wider community felt. The last 32-bit, Intel Mac was the Mac Mini, discontinued in August 2007. The bulk of them were discontinued in 2006, along with PowerPC Macs. Does it make sense to relegate OSX x86_64 to community status while the 32-bit version is considered a supported platform? Given that I'm far from experienced enough to be able to contribute meaningfully to GHC, I'm not complaining about anyone's efforts, just that those efforts might be a bit misallocated. I'd venture a guess that far more people are interested in running 64-bit GHC on OSX than in running GHC on what is now fairly antiquated hardware. mc

On 2/3/11 10:48 AM, Max Cantor wrote:
Does it make sense to relegate OSX x86_64 to community status while the 32-bit version is considered a supported platform?
I'm not sure I can make sense of what you mean here. Given the preamble, I'd guess you're asking whether we should make x86_64 the targeted architecture for OSX support, and reclassify 32-bit OSX to unsupported or "hopefully it still works" status. (But in that case, it's the 32-bit which would be "relegated" to unsupported status while x86_64 is "considered a supported platform"...) Can you clarify the question? -- Live well, ~wren

On 4/02/2011, at 2:14 PM, wren ng thornton wrote:
On 2/3/11 10:48 AM, Max Cantor wrote:
Does it make sense to relegate OSX x86_64 to community status while the 32-bit version is considered a supported platform?
I'm not sure I can make sense of what you mean here. Given the preamble, I'd guess you're asking whether we should make x86_64 the targeted architecture for OSX support, and reclassify 32-bit OSX to unsupported or "hopefully it still works" status. (But in that case, it's the 32-bit which would be "relegated" to unsupported status while x86_64 is "considered a supported platform"...)
Can you clarify the question?
Here's something that happened to me: GHC was installed on this machine and worked fine, but when the operating system was upgraded to Mac OS X 10.6.something, GHC broke, with messages along the lines of "you can't use 32-bit absolute addresses in 64-bit code". The operating system is perfectly happy running both 32-bit and 64-code code and all the tool chain is happy working with either, but the *default* changed from "say nothing get 32-bit" to "say nothing get 64-bit". I'm guessing that GHC gives the compiler some C code and some (32-bit) object files or libraries. So now I have *different* GHC setups on the 10.6.5 desktop machine and the 10.5.8 laptop... Since both machines have only 4GB of physical memory, 32-bit would be fine, except for all those lovely extra registers in x86_64 mode. I think the original poster is saying that the targeted architecture for OS X support should be the architecture that OS X assumes by default, and these days that's x86_64. It would be really nice for x86 mode to be well supported for a while longer.

I'm not sure I can make sense of what you mean here. Given the preamble, I'd guess you're asking whether we should make x86_64 the targeted architecture for OSX support, and reclassify 32-bit OSX to unsupported or "hopefully it still works" status. (But in that case, it's the 32-bit which would be "relegated" to unsupported status while x86_64 is "considered a supported platform"...)
Yes. I'm saying that I believe that OSX x86_64 should be the officially supported platform instead of 32-bit x86 with all the associated guarantees and assurances. I wanted to see how people felt about that. mc
Can you clarify the question?
Here's something that happened to me: GHC was installed on this machine and worked fine, but when the operating system was upgraded to Mac OS X 10.6.something, GHC broke, with messages along the lines of "you can't use 32-bit absolute addresses in 64-bit code". The operating system is perfectly happy running both 32-bit and 64-code code and all the tool chain is happy working with either, but the *default* changed from "say nothing get 32-bit" to "say nothing get 64-bit". I'm guessing that GHC gives the compiler some C code and some (32-bit) object files or libraries.
So now I have *different* GHC setups on the 10.6.5 desktop machine and the 10.5.8 laptop... Since both machines have only 4GB of physical memory, 32-bit would be fine, except for all those lovely extra registers in x86_64 mode.
I think the original poster is saying that the targeted architecture for OS X support should be the architecture that OS X assumes by default, and these days that's x86_64.
It would be really nice for x86 mode to be well supported for a while longer.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Max Cantor wrote:
someone? wrote:
I think the original poster is saying that the targeted architecture for OS X support should be the architecture that OS X assumes by default, and these days that's x86_64.
That sounds reasonable to me. The big caveat is that OSX >= 10.5.8 && < 10.6 should still be targeted as well. While non-x86_64 Macs are quite old, OSX 10.6 is still pretty new and so there are a lot of people still using 10.5 (and our department still has a couple boxes running 10.4). So even though 10.5.8 defaults to 32-bit, it should still be actively supported (as an x86_64 architecture). Just pass the necessary flags to gcc :)
It would be really nice for x86 mode to be well supported for a while longer.
Yes, it'd be really nice to support 32-bit mode for a while yet, even if it isn't actively being targeted for improvements. -- Live well, ~wren

Doesn't 10.5.x have the ability to generate and run 64-bit binaries? mc On Feb 4, 2011, at 10:19 AM, wren ng thornton wrote:
Max Cantor wrote:
someone? wrote:
I think the original poster is saying that the targeted architecture for OS X support should be the architecture that OS X assumes by default, and these days that's x86_64.
That sounds reasonable to me. The big caveat is that OSX >= 10.5.8 && < 10.6 should still be targeted as well. While non-x86_64 Macs are quite old, OSX 10.6 is still pretty new and so there are a lot of people still using 10.5 (and our department still has a couple boxes running 10.4).
So even though 10.5.8 defaults to 32-bit, it should still be actively supported (as an x86_64 architecture). Just pass the necessary flags to gcc :)
It would be really nice for x86 mode to be well supported for a while longer.
Yes, it'd be really nice to support 32-bit mode for a while yet, even if it isn't actively being targeted for improvements.
-- Live well, ~wren
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Wholly support moving OSX to x64. x86 should be supported only on a
best effort basis for legacy.
Steve
On Thu, Feb 3, 2011 at 6:28 PM, Max Cantor
Doesn't 10.5.x have the ability to generate and run 64-bit binaries?
mc
On Feb 4, 2011, at 10:19 AM, wren ng thornton wrote:
Max Cantor wrote:
someone? wrote:
I think the original poster is saying that the targeted architecture for OS X support should be the architecture that OS X assumes by default, and these days that's x86_64.
That sounds reasonable to me. The big caveat is that OSX >= 10.5.8 && < 10.6 should still be targeted as well. While non-x86_64 Macs are quite old, OSX 10.6 is still pretty new and so there are a lot of people still using 10.5 (and our department still has a couple boxes running 10.4).
So even though 10.5.8 defaults to 32-bit, it should still be actively supported (as an x86_64 architecture). Just pass the necessary flags to gcc :)
It would be really nice for x86 mode to be well supported for a while longer.
Yes, it'd be really nice to support 32-bit mode for a while yet, even if it isn't actively being targeted for improvements.
-- Live well, ~wren
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- ------------------------------------ Steve Severance c. 240.472.9645 e. steve@medwizard.net ------------------------------------

On 4 February 2011 02:35, Steve Severance
Wholly support moving OSX to x64. x86 should be supported only on a best effort basis for legacy.
Moving from x86 to x64 has advantages and disadvantages from my POV. Advantages: * Able to address more memory * More registers for code generation * Haskell dependencies wouldn't need to be built for x86 on Snow Leopard (though if we swapped to x64 on Leopard as well, the Leopard users would start having to build 64-bit libraries specially) Disadvantages: * Pointers become wider, and Haskell data structures mostly consist of pointers. This will bloat memory use of Haskell programs. * Generated binaries won't work on older Macs that don't have a 64-bit OS/CPU. This is important if you are distributing compiled Haskell binaries, which is not something I personally do but which is probably important to support Did I miss anything? I don't know if anyone using a 64-bits GHC on e.g. Linux has reported experience of whether moving to 64-bits is a net win or not from a performance perspective. My guess is that it is a win for certain classes of programs (numerically intensive, "high performance Haskell"), and a loss for programs making extensive use of laziness, boxed data structures etc. I notice that there is some work towards standardisation of a "x32" ABI for 64-bit applications using thin, 32 bit pointers. See http://robertmh.wordpress.com/2011/01/19/finally-amd32-is-taking-shape/. This might be an interesting thing to explore when it becomes more fully developed. Cheers, Max

On 2/3/11 9:28 PM, Max Cantor wrote:
Doesn't 10.5.x have the ability to generate and run 64-bit binaries?
Yes, it does. But it defaults to 32-bit as I recall. Richard O'Keefe suggested a general practice of targeting the architecture considered default by the operating system. That's a good suggestion; I was just pointing out that when new versions of OSX change the default architecture, we should continue to support older versions of OSX on the newly-default architecture even though that architecture isn't the default one for the older version of OSX. -- Live well, ~wren

On Feb 3, 2011, at 5:55 PM, Max Cantor wrote:
Yes. I'm saying that I believe that OSX x86_64 should be the officially supported platform instead of 32-bit x86 with all the associated guarantees and assurances. I wanted to see how people felt about that.
I don't think this is such a good idea. There are plenty of Macs in the field that can only execute 32bit code. (I'm typing on one right now!) Anyone wanting to produce binaries that they can distribute or deploy will need an environment that produces either 32bit only binaries, or multi-arch 32bit/64bit binaries. My understanding is that GHC is quite a long way, if ever, from producing multi-arch binaries from a single compiler. To produce multi-arch binaries you'd need to install two copies of the GHC (one 32bit, one 64bit), build your code twice, once with each, and stitch the results together with lipo. Hence, for the Haskell developer needing to deploy code, the path of least resistance is going to be simply compiling and distributing 32bit for awhile. Because of this, the 32bit version should be officially supported just as much as the 64bit for at least the next few years. My plan for the upcoming Haskell Platform is to build and distribute two installers: one 32bit and 64bit. Most developers should take the 64bit one if their machine supports it. Developers with older machines, and those building binary distributions will need to take the 32bit. - Mark
participants (6)
-
Mark Lentczner
-
Max Bolingbroke
-
Max Cantor
-
Richard O'Keefe
-
Steve Severance
-
wren ng thornton