www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 64 bit DMD binary on the Mac

reply Walter Bright <newshound2 digitalmars.com> writes:
Although DMD on the Mac can currently only generate 32 bit binaries, the Mac as 
I understand it can run 64 bit code.

Is there any reason that DMD itself should be a 32 bit app? Are there any 32
bit 
only Macs out there we should support?
Jun 28 2011
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 28/06/2011 19:43, Walter Bright wrote:
 Although DMD on the Mac can currently only generate 32 bit binaries, the
 Mac as I understand it can run 64 bit code.

 Is there any reason that DMD itself should be a 32 bit app? Are there
 any 32 bit only Macs out there we should support?
Standard practice is to use universal binaries, that is, having both the 64 bit and 32 bit binary in one eg: $ file `which which` /usr/bin/which: Mach-O universal binary with 3 architectures /usr/bin/which (for architecture x86_64): Mach-O 64-bit executable x86_64 /usr/bin/which (for architecture i386): Mach-O executable i386 /usr/bin/which (for architecture ppc7400): Mach-O executable ppc Although this will increase binary size, obviously. OS X then chooses which version to use itself, with preference being the same order as above (64, 32, ppc). This said, I see no reason why you can't switch to a 64 bit binary, as far as I'm aware all the intel hardware apple has shipped supports running 64 bit applications. You may want to check this though. -- Robert http://octarineparrot.com/
Jun 28 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-06-28 20:53, Robert Clipsham wrote:
 On 28/06/2011 19:43, Walter Bright wrote:
 Although DMD on the Mac can currently only generate 32 bit binaries, the
 Mac as I understand it can run 64 bit code.

 Is there any reason that DMD itself should be a 32 bit app? Are there
 any 32 bit only Macs out there we should support?
Standard practice is to use universal binaries, that is, having both the 64 bit and 32 bit binary in one eg: $ file `which which` /usr/bin/which: Mach-O universal binary with 3 architectures /usr/bin/which (for architecture x86_64): Mach-O 64-bit executable x86_64 /usr/bin/which (for architecture i386): Mach-O executable i386 /usr/bin/which (for architecture ppc7400): Mach-O executable ppc Although this will increase binary size, obviously. OS X then chooses which version to use itself, with preference being the same order as above (64, 32, ppc). This said, I see no reason why you can't switch to a 64 bit binary, as far as I'm aware all the intel hardware apple has shipped supports running 64 bit applications. You may want to check this though.
Very few applications are 64bit on Mac OS X 10.5. Most of the applications are 64bit on Mac OS X 10.6. Although, as far as I understand it, quite few Macs actually run the kernel in 64bit (by default), if that matters. Since most of the applications and most the libraries (basically all that ships with Mac OS X) are universal there's usually no problem of running/building both 32 and 64bit software. I just had a look at this: http://support.apple.com/kb/ht3696 Any Mac running Intel Core Solo or Intel Core Duo is 32bit only. Although it's hard to tell how many users that have a Mac with any of the above CPU's. -- /Jacob Carlborg
Jun 28 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/28/2011 12:13 PM, Jacob Carlborg wrote:
 Since most of the applications and most the libraries (basically all that ships
 with Mac OS X) are universal there's usually no problem of running/building
both
 32 and 64bit software.
I'll explain the motivation for 64 bit only DMD binaries: 1. It cuts the testing time in half. This is a significant deal for me, as adding another hour to the test cycle slows things down a lot. 2. It speeds downloading the dmd package. The only reason to have a 32 bit binary is if there are x86 Macs 10.5 or later that are incapable of running 64 bit code.
Jun 28 2011
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 28/06/2011 20:39, Walter Bright wrote:
 1. It cuts the testing time in half. This is a significant deal for me,
 as adding another hour to the test cycle slows things down a lot.
Definitely worth investigating then!
 2. It speeds downloading the dmd package.
Of course the real solution for this one is to offer individual packages. If you're on OS X, why on earth would you want binaries for Windows/Linux32/Linux64/FreeBSD and the libraries to go with them? And why would you want to download a large zip file when you can download a tarball and have it be a fraction of the size (and work just as well out of the box as a zip). Or even better a .dmg or .pkg.
 The only reason to have a 32 bit binary is if there are x86 Macs 10.5 or
 later that are incapable of running 64 bit code.
-- Robert http://octarineparrot.com/
Jun 28 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/28/2011 12:46 PM, Robert Clipsham wrote:
 Of course the real solution for this one is to offer individual packages.
Even if we did for OSX, why have double the size with "universal binaries"? Basically, I'm looking for a reason to have 32 bit dmd binaries for OSX.
Jun 28 2011
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-06-28 15:39:42 -0400, Walter Bright <newshound2 digitalmars.com> said:

 On 6/28/2011 12:13 PM, Jacob Carlborg wrote:
 Since most of the applications and most the libraries (basically all that ships
 with Mac OS X) are universal there's usually no problem of 
 running/building both
 32 and 64bit software.
I'll explain the motivation for 64 bit only DMD binaries: 1. It cuts the testing time in half. This is a significant deal for me, as adding another hour to the test cycle slows things down a lot. 2. It speeds downloading the dmd package. The only reason to have a 32 bit binary is if there are x86 Macs 10.5 or later that are incapable of running 64 bit code.
Well, you could ship the next DMD version 64-bit only and of you get complains you bring back the 32-bit version as a universal binary. But you'll definitely rule out users of Apple's early Intel computers. I think the last Apple model with a 32-bit CPU was the "Mac Mini (Late 2006)", which was replaced mid 2007 with a Core 2 Duo model. As for increasing the download speed, you could try one of these too: * separate per-OS packages * separate source package * separate documentation package * faster server -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jun 28 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:iudhf9$2dr9$1 digitalmars.com...
 On 2011-06-28 15:39:42 -0400, Walter Bright <newshound2 digitalmars.com> 
 said:

 On 6/28/2011 12:13 PM, Jacob Carlborg wrote:
 Since most of the applications and most the libraries (basically all 
 that ships
 with Mac OS X) are universal there's usually no problem of 
 running/building both
 32 and 64bit software.
I'll explain the motivation for 64 bit only DMD binaries: 1. It cuts the testing time in half. This is a significant deal for me, as adding another hour to the test cycle slows things down a lot. 2. It speeds downloading the dmd package. The only reason to have a 32 bit binary is if there are x86 Macs 10.5 or later that are incapable of running 64 bit code.
Well, you could ship the next DMD version 64-bit only and of you get complains you bring back the 32-bit version as a universal binary. But you'll definitely rule out users of Apple's early Intel computers. I think the last Apple model with a 32-bit CPU was the "Mac Mini (Late 2006)", which was replaced mid 2007 with a Core 2 Duo model. As for increasing the download speed, you could try one of these too: * separate per-OS packages * separate source package * separate documentation package * faster server
* use 7z Using 7z instead of zip or tarballs has shrunk the size of my packaged Goldie releases down to roughly one-quarter the size of a zip or tar.bz2 (Yes, ~75% decrease is size). Of course, that's probably an extreme case, but I just tried making a 7z of DMD 2.053, and it came out to just under 9MB (vs just over 15MB for the official zip release), so fairly close to half the size. Still pretty damn good. And I really see no reason why any programmer shouldn't have a 7z-capable extractor these days. Heck, it's pretty typical on Linux, and it's built into WinRar. Zip and tarballs are like MP3's: They're still everywhere, but only because of inertia, not because of any inherent merit, of which there really isn't any. 7z is like moving to Vorbis (Except that I think 7z support is probably more common than Vorbis support, which is unfortunate for Vorbis fans like me, but that's even more OT...).
Jun 28 2011
next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
On Tue, Jun 28, 2011 at 3:13 PM, Nick Sabalausky <a a.a> wrote:

 "Michel Fortin" <michel.fortin michelf.com> wrote in message
 news:iudhf9$2dr9$1 digitalmars.com...
 On 2011-06-28 15:39:42 -0400, Walter Bright <newshound2 digitalmars.com>
 said:

 On 6/28/2011 12:13 PM, Jacob Carlborg wrote:
 Since most of the applications and most the libraries (basically all
 that ships
 with Mac OS X) are universal there's usually no problem of
 running/building both
 32 and 64bit software.
I'll explain the motivation for 64 bit only DMD binaries: 1. It cuts the testing time in half. This is a significant deal for me, as adding another hour to the test cycle slows things down a lot. 2. It speeds downloading the dmd package. The only reason to have a 32 bit binary is if there are x86 Macs 10.5 or later that are incapable of running 64 bit code.
Well, you could ship the next DMD version 64-bit only and of you get complains you bring back the 32-bit version as a universal binary. But you'll definitely rule out users of Apple's early Intel computers. I think the last Apple model with a 32-bit CPU was the "Mac Mini (Late 2006)", which was replaced mid 2007 with a Core 2 Duo model. As for increasing the download speed, you could try one of these too: * separate per-OS packages * separate source package * separate documentation package * faster server
* use 7z Using 7z instead of zip or tarballs has shrunk the size of my packaged Goldie releases down to roughly one-quarter the size of a zip or tar.bz2 (Yes, ~75% decrease is size). Of course, that's probably an extreme case, but I just tried making a 7z of DMD 2.053, and it came out to just under 9MB (vs just over 15MB for the official zip release), so fairly close to half the size. Still pretty damn good. And I really see no reason why any programmer shouldn't have a 7z-capable extractor these days. Heck, it's pretty typical on Linux, and it's built into WinRar. Zip and tarballs are like MP3's: They're still everywhere, but only because of inertia, not because of any inherent merit, of which there really isn't any. 7z is like moving to Vorbis (Except that I think 7z support is probably more common than Vorbis support, which is unfortunate for Vorbis fans like me, but that's even more OT...).
Have you tried xz on Linux? I think WinRar supports it on Windows, but I haven't checked in a while.
Jun 28 2011
prev sibling next sibling parent Jimmy Cao <jcao219 gmail.com> writes:
On Tue, Jun 28, 2011 at 9:05 PM, Andrew Wiley <wiley.andrew.j gmail.com>wrote:

 On Tue, Jun 28, 2011 at 3:13 PM, Nick Sabalausky <a a.a> wrote:

 "Michel Fortin" <michel.fortin michelf.com> wrote in message
 news:iudhf9$2dr9$1 digitalmars.com...
 On 2011-06-28 15:39:42 -0400, Walter Bright <newshound2 digitalmars.com

 said:

 On 6/28/2011 12:13 PM, Jacob Carlborg wrote:
 Since most of the applications and most the libraries (basically all
 that ships
 with Mac OS X) are universal there's usually no problem of
 running/building both
 32 and 64bit software.
I'll explain the motivation for 64 bit only DMD binaries: 1. It cuts the testing time in half. This is a significant deal for me, as adding another hour to the test cycle slows things down a lot. 2. It speeds downloading the dmd package. The only reason to have a 32 bit binary is if there are x86 Macs 10.5
or
 later that are incapable of running 64 bit code.
Well, you could ship the next DMD version 64-bit only and of you get complains you bring back the 32-bit version as a universal binary. But you'll definitely rule out users of Apple's early Intel computers. I think the last Apple model with a 32-bit CPU was the "Mac Mini (Late 2006)", which was replaced mid 2007 with a Core 2 Duo model. As for increasing the download speed, you could try one of these too: * separate per-OS packages * separate source package * separate documentation package * faster server
* use 7z Using 7z instead of zip or tarballs has shrunk the size of my packaged Goldie releases down to roughly one-quarter the size of a zip or tar.bz2 (Yes, ~75% decrease is size). Of course, that's probably an extreme case, but I just tried making a 7z of DMD 2.053, and it came out to just under 9MB (vs just over 15MB for the official zip release), so fairly close to half the size. Still pretty damn good. And I really see no reason why any programmer shouldn't have a 7z-capable extractor these days. Heck, it's pretty typical on Linux, and it's built into WinRar. Zip and tarballs are like MP3's: They're still everywhere, but only because of inertia, not because of any inherent merit, of which there really isn't any. 7z is like moving to Vorbis (Except that I think 7z support is probably more common than Vorbis support, which is unfortunate for Vorbis fans like me, but that's even more OT...).
Have you tried xz on Linux? I think WinRar supports it on Windows, but I haven't checked in a while.
I just tried using WinRAR to open a tar.xz file, and it didn't work.
Jun 28 2011
prev sibling next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
On Tue, Jun 28, 2011 at 9:17 PM, Jimmy Cao <jcao219 gmail.com> wrote:

 On Tue, Jun 28, 2011 at 9:05 PM, Andrew Wiley <wiley.andrew.j gmail.com>wrote:

 On Tue, Jun 28, 2011 at 3:13 PM, Nick Sabalausky <a a.a> wrote:

 "Michel Fortin" <michel.fortin michelf.com> wrote in message
 news:iudhf9$2dr9$1 digitalmars.com...
 On 2011-06-28 15:39:42 -0400, Walter Bright <
newshound2 digitalmars.com>
 said:

 On 6/28/2011 12:13 PM, Jacob Carlborg wrote:
 Since most of the applications and most the libraries (basically all
 that ships
 with Mac OS X) are universal there's usually no problem of
 running/building both
 32 and 64bit software.
I'll explain the motivation for 64 bit only DMD binaries: 1. It cuts the testing time in half. This is a significant deal for
me,
 as adding another hour to the test cycle slows things down a lot.

 2. It speeds downloading the dmd package.

 The only reason to have a 32 bit binary is if there are x86 Macs 10.5
or
 later that are incapable of running 64 bit code.
Well, you could ship the next DMD version 64-bit only and of you get complains you bring back the 32-bit version as a universal binary. But you'll definitely rule out users of Apple's early Intel computers.
I
 think the last Apple model with a 32-bit CPU was the "Mac Mini (Late
 2006)", which was replaced mid 2007 with a Core 2 Duo model.

 As for increasing the download speed, you could try one of these too:

 * separate per-OS packages
 * separate source package
 * separate documentation package
 * faster server
* use 7z Using 7z instead of zip or tarballs has shrunk the size of my packaged Goldie releases down to roughly one-quarter the size of a zip or tar.bz2 (Yes, ~75% decrease is size). Of course, that's probably an extreme case, but I just tried making a 7z of DMD 2.053, and it came out to just under 9MB (vs just over 15MB for the official zip release), so fairly close to half the size. Still pretty damn good. And I really see no reason why any programmer shouldn't have a 7z-capable extractor these days. Heck, it's pretty typical on Linux, and it's built into WinRar. Zip and tarballs are like MP3's: They're still everywhere, but only because of inertia, not because of any inherent merit, of which there really isn't any. 7z is like moving to Vorbis (Except that I think 7z support is probably more common than Vorbis support, which is unfortunate for Vorbis fans like me, but that's even more OT...).
Have you tried xz on Linux? I think WinRar supports it on Windows, but I haven't checked in a while.
I just tried using WinRAR to open a tar.xz file, and it didn't work.
Ah, then I suppose I'm a liar and/or delusional. I remember opening one on Windows with some archiver, but I've only ever done it a few times, and not on a box I have access to at the moment.
Jun 28 2011
prev sibling parent Jimmy Cao <jcao219 gmail.com> writes:
The 7-Zip archiver supports it.

On Tue, Jun 28, 2011 at 11:40 PM, Andrew Wiley <wiley.andrew.j gmail.com>wrote:

 On Tue, Jun 28, 2011 at 9:17 PM, Jimmy Cao <jcao219 gmail.com> wrote:

 On Tue, Jun 28, 2011 at 9:05 PM, Andrew Wiley <wiley.andrew.j gmail.com>wrote:

 On Tue, Jun 28, 2011 at 3:13 PM, Nick Sabalausky <a a.a> wrote:

 "Michel Fortin" <michel.fortin michelf.com> wrote in message
 news:iudhf9$2dr9$1 digitalmars.com...
 On 2011-06-28 15:39:42 -0400, Walter Bright <
newshound2 digitalmars.com>
 said:

 On 6/28/2011 12:13 PM, Jacob Carlborg wrote:
 Since most of the applications and most the libraries (basically all
 that ships
 with Mac OS X) are universal there's usually no problem of
 running/building both
 32 and 64bit software.
I'll explain the motivation for 64 bit only DMD binaries: 1. It cuts the testing time in half. This is a significant deal for
me,
 as adding another hour to the test cycle slows things down a lot.

 2. It speeds downloading the dmd package.

 The only reason to have a 32 bit binary is if there are x86 Macs 10.5
or
 later that are incapable of running 64 bit code.
Well, you could ship the next DMD version 64-bit only and of you get complains you bring back the 32-bit version as a universal binary. But you'll definitely rule out users of Apple's early Intel computers.
I
 think the last Apple model with a 32-bit CPU was the "Mac Mini (Late
 2006)", which was replaced mid 2007 with a Core 2 Duo model.

 As for increasing the download speed, you could try one of these too:

 * separate per-OS packages
 * separate source package
 * separate documentation package
 * faster server
* use 7z Using 7z instead of zip or tarballs has shrunk the size of my packaged Goldie releases down to roughly one-quarter the size of a zip or tar.bz2 (Yes, ~75% decrease is size). Of course, that's probably an extreme case, but I just tried making a 7z of DMD 2.053, and it came out to just under 9MB (vs just over 15MB for the official zip release), so fairly close to half the size. Still pretty damn good. And I really see no reason why any programmer shouldn't have a 7z-capable extractor these days. Heck, it's pretty typical on Linux, and it's built into WinRar. Zip and tarballs are like MP3's: They're still everywhere, but only because of inertia, not because of any inherent merit, of which there really isn't any. 7z is like moving to Vorbis (Except that I think 7z support is probably more common than Vorbis support, which is unfortunate for Vorbis fans like me, but that's even more OT...).
Have you tried xz on Linux? I think WinRar supports it on Windows, but I haven't checked in a while.
I just tried using WinRAR to open a tar.xz file, and it didn't work.
Ah, then I suppose I'm a liar and/or delusional. I remember opening one on Windows with some archiver, but I've only ever done it a few times, and not on a box I have access to at the moment.
Jun 28 2011
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Jun 29, 11 02:43, Walter Bright wrote:
 Although DMD on the Mac can currently only generate 32 bit binaries, the
 Mac as I understand it can run 64 bit code.

 Is there any reason that DMD itself should be a 32 bit app? Are there
 any 32 bit only Macs out there we should support?
With universal binary there's no need to worry about it anyway. Just pass '-m32 -m64' to gcc. However, I see little reason making DMD itself a 64-bit executable.
Jun 28 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-06-28 12:11, KennyTM~ wrote:
 On Jun 29, 11 02:43, Walter Bright wrote:
 Although DMD on the Mac can currently only generate 32 bit binaries, the
 Mac as I understand it can run 64 bit code.
 
 Is there any reason that DMD itself should be a 32 bit app? Are there
 any 32 bit only Macs out there we should support?
With universal binary there's no need to worry about it anyway. Just pass '-m32 -m64' to gcc. However, I see little reason making DMD itself a 64-bit executable.
For at least some of the same reasons that Linux users want a 64-bit dmd binary (though obviously not all, since the universal binary solves some of the distro-related problems). For instance, to make it less likely to run out of memory - particularly when you're using a lot of templates. Once dmd actually becomes smarter about handling memory, it won't be as big an issue, but at this point, it really isn't all that hard to get dmd to run out of memory on a 32-bit system. - Jonathan M Davis
Jun 28 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/28/2011 12:11 PM, KennyTM~ wrote:
 With universal binary there's no need to worry about it anyway.
It's not what I'm asking, I'm asking if there is any reason at all to ship a 32 bit dmd binary?
Jun 28 2011
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Jun 29, 11 03:52, Walter Bright wrote:
 On 6/28/2011 12:11 PM, KennyTM~ wrote:
 With universal binary there's no need to worry about it anyway.
It's not what I'm asking, I'm asking if there is any reason at all to ship a 32 bit dmd binary?
Nope :). But I just worry in case there would be bugs introduced in the C++ code due to the change in pointer size.
Jun 28 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/28/2011 1:27 PM, KennyTM~ wrote:
 Nope :). But I just worry in case there would be bugs introduced in the C++
code
 due to the change in pointer size.
Only one way to shake those out! (And 64 bit DMD on Linux has pretty much accomplished that.)
Jun 28 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:iudbma$1d9k$2 digitalmars.com...
 On 6/28/2011 12:11 PM, KennyTM~ wrote:
 With universal binary there's no need to worry about it anyway.
It's not what I'm asking, I'm asking if there is any reason at all to ship a 32 bit dmd binary?
To not encourage people to accidentally end up writing code that's so ctfe/template-heavy that it won't compile with a 32-bit DMD? I don't mean that as a snide remark, just a practical consideration. Plus, in the same way that 64-bit DMD can help shake out 64-bit bugs, 32-bit can help shake out memory-usage problems. OTOH, It seems to be pretty typical, standard, accepted practice in the Apple world for older machines to get abandoned *very* quickly, so maybe 32-bit is already needless on Mac?
Jun 28 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/28/2011 3:22 PM, Nick Sabalausky wrote:
 OTOH, It seems to be pretty typical, standard, accepted practice in the
 Apple world for older machines to get abandoned *very* quickly, so maybe
 32-bit is already needless on Mac?
Are there any 32 bit x86 Mac machines? My several-years-old mac mini is 64 bits.
Jun 28 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 29.06.2011 00:27, schrieb Walter Bright:
 On 6/28/2011 3:22 PM, Nick Sabalausky wrote:
 OTOH, It seems to be pretty typical, standard, accepted practice in the
 Apple world for older machines to get abandoned *very* quickly, so maybe
 32-bit is already needless on Mac?
Are there any 32 bit x86 Mac machines? My several-years-old mac mini is 64 bits.
Yes, see: Am 28.06.2011 23:30, schrieb Michel Fortin:
 But you'll definitely rule out users of Apple's early Intel computers. I
 think the last Apple model with a 32-bit CPU was the "Mac Mini (Late
 2006)", which was replaced mid 2007 with a Core 2 Duo model.
and Am 28.06.2011 21:13, schrieb Jacob Carlborg:
 I just had a look at this:

 http://support.apple.com/kb/ht3696

 Any Mac running Intel Core Solo or Intel Core Duo is 32bit only.
 Although it's hard to tell how many users that have a Mac with any of
 the above CPU's.
Cheers, - Daniel
Jun 28 2011
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
I think the original Core 2 Duo was 32-bit. People still use these at work, b=
ut they're getting rather long in the tooth. Most of them have failed alread=
y (mine did).

Sent from my iPhone

On Jun 28, 2011, at 3:27 PM, Walter Bright <newshound2 digitalmars.com> wrot=
e:

 On 6/28/2011 3:22 PM, Nick Sabalausky wrote:
 OTOH, It seems to be pretty typical, standard, accepted practice in the
 Apple world for older machines to get abandoned *very* quickly, so maybe
 32-bit is already needless on Mac?
=20 Are there any 32 bit x86 Mac machines? My several-years-old mac mini is 64=
bits.
=20
=20
Jun 29 2011
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-06-29 17:54, Sean Kelly wrote:
 I think the original Core 2 Duo was 32-bit. People still use these at work,
but they're getting rather long in the tooth. Most of them have failed already
(mine did).

 Sent from my iPhone

 On Jun 28, 2011, at 3:27 PM, Walter Bright<newshound2 digitalmars.com>  wrote:

 On 6/28/2011 3:22 PM, Nick Sabalausky wrote:
 OTOH, It seems to be pretty typical, standard, accepted practice in the
 Apple world for older machines to get abandoned *very* quickly, so maybe
 32-bit is already needless on Mac?
Are there any 32 bit x86 Mac machines? My several-years-old mac mini is 64 bits.
According to this: http://support.apple.com/kb/ht3696 all Macs with a Core 2 Duo are 64bit. -- /Jacob Carlborg
Jun 29 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/29/2011 8:54 AM, Sean Kelly wrote:
 I think the original Core 2 Duo was 32-bit. People still use these at work,
 but they're getting rather long in the tooth. Most of them have failed
 already (mine did).
My mac mini died, needed a new mobo for $200. Aggh.
Jun 29 2011
prev sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Wed, 2011-06-29 at 08:54 -0700, Sean Kelly wrote:
 I think the original Core 2 Duo was 32-bit. People still use these at wor=
k, but they're getting rather long in the tooth. Most of them have failed a= lready (mine did). Core Duo was 32-bit, Core 2 Duo was 64-bit. (*)
 Sent from my iPhone
=20
 On Jun 28, 2011, at 3:27 PM, Walter Bright <newshound2 digitalmars.com> w=
rote:
=20
 On 6/28/2011 3:22 PM, Nick Sabalausky wrote:
 OTOH, It seems to be pretty typical, standard, accepted practice in th=
e
 Apple world for older machines to get abandoned *very* quickly, so may=
be
 32-bit is already needless on Mac?
=20 Are there any 32 bit x86 Mac machines? My several-years-old mac mini is=
64 bits. (*) But just because you have a 64-bit processor doesn't mean you can run a 64-bit OS. Mac OS X selects whether to be 32-bit or 64-bit not on the word width processor, but on the word width of the boot PROM. So my Core Duo Mac Mini is happily 32-bit, but my Core 2 Duo MacBook has a hell of a time since Mac OS X says 32-bit and the processor says 64-bit. One can only assume Apple assume that anything over 3 years old is broken and already disposed of to be replaced by a new Apple product. Rant elided. I'll stick with Debian Testing for most of my work. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jun 29 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-06-29 18:59, Russel Winder wrote:
 On Wed, 2011-06-29 at 08:54 -0700, Sean Kelly wrote:
 I think the original Core 2 Duo was 32-bit. People still use these at work,
but they're getting rather long in the tooth. Most of them have failed already
(mine did).
Core Duo was 32-bit, Core 2 Duo was 64-bit. (*)
 Sent from my iPhone

 On Jun 28, 2011, at 3:27 PM, Walter Bright<newshound2 digitalmars.com>  wrote:

 On 6/28/2011 3:22 PM, Nick Sabalausky wrote:
 OTOH, It seems to be pretty typical, standard, accepted practice in the
 Apple world for older machines to get abandoned *very* quickly, so maybe
 32-bit is already needless on Mac?
Are there any 32 bit x86 Mac machines? My several-years-old mac mini is 64 bits.
(*) But just because you have a 64-bit processor doesn't mean you can run a 64-bit OS. Mac OS X selects whether to be 32-bit or 64-bit not on the word width processor, but on the word width of the boot PROM. So my Core Duo Mac Mini is happily 32-bit, but my Core 2 Duo MacBook has a hell of a time since Mac OS X says 32-bit and the processor says 64-bit. One can only assume Apple assume that anything over 3 years old is broken and already disposed of to be replaced by a new Apple product. Rant elided. I'll stick with Debian Testing for most of my work.
Yes exactly. Actually very few macs, what I've heard, run the kernel in 64bit. -- /Jacob Carlborg
Jun 29 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 29.06.2011 22:01, schrieb Jacob Carlborg:
 On 2011-06-29 18:59, Russel Winder wrote:
 On Wed, 2011-06-29 at 08:54 -0700, Sean Kelly wrote:
 I think the original Core 2 Duo was 32-bit. People still use these at
 work, but they're getting rather long in the tooth. Most of them have
 failed already (mine did).
Core Duo was 32-bit, Core 2 Duo was 64-bit. (*)
 Sent from my iPhone

 On Jun 28, 2011, at 3:27 PM, Walter
 Bright<newshound2 digitalmars.com>  wrote:

 On 6/28/2011 3:22 PM, Nick Sabalausky wrote:
 OTOH, It seems to be pretty typical, standard, accepted practice in
 the
 Apple world for older machines to get abandoned *very* quickly, so
 maybe
 32-bit is already needless on Mac?
Are there any 32 bit x86 Mac machines? My several-years-old mac mini is 64 bits.
(*) But just because you have a 64-bit processor doesn't mean you can run a 64-bit OS. Mac OS X selects whether to be 32-bit or 64-bit not on the word width processor, but on the word width of the boot PROM. So my Core Duo Mac Mini is happily 32-bit, but my Core 2 Duo MacBook has a hell of a time since Mac OS X says 32-bit and the processor says 64-bit. One can only assume Apple assume that anything over 3 years old is broken and already disposed of to be replaced by a new Apple product. Rant elided. I'll stick with Debian Testing for most of my work.
Yes exactly. Actually very few macs, what I've heard, run the kernel in 64bit.
So is a 32bit kernel just default or can't you even upgrade to 64bit OSX if you want to with these older Macs (with 64bit CPUs)? Sounds like a really broken mess.. probably the DMD for OSX should stick to 32bit or universal binaries. Cheers, - Daniel
Jun 29 2011
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-06-29 20:55:43 -0400, Daniel Gibson <metalcaedes gmail.com> said:

 Am 29.06.2011 22:01, schrieb Jacob Carlborg:
 Yes exactly. Actually very few macs, what I've heard, run the kernel in
 64bit.
So is a 32bit kernel just default or can't you even upgrade to 64bit OSX if you want to with these older Macs (with 64bit CPUs)? Sounds like a really broken mess.. probably the DMD for OSX should stick to 32bit or universal binaries.
It might look messy, but in reality it's doesn't matter much. First, there is no 64-bit or 32-bit version of OS X, both versions are installed at the same time. Second, the 32-bit kernel is able to run 64-bit programs just fine if you have a 64-bit CPU, just like the 64-bit kernel can run 32-bit programs. The reason very few Macs run the kernel in 64-bit in the current version of Mac OS X is to avoid breaking older 32-bit third-party drivers (which must run inside the kernel's address space). So unless you do driver programming, you generally don't care at all in which mode the kernel is running. Note that which kernel to use is determined at boot time. You can hold the 6 and 4 keys while you boot to force the 64-bit kernel to be used. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jun 29 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 30.06.2011 04:32, schrieb Michel Fortin:
 On 2011-06-29 20:55:43 -0400, Daniel Gibson <metalcaedes gmail.com> said:
 
 Am 29.06.2011 22:01, schrieb Jacob Carlborg:
 Yes exactly. Actually very few macs, what I've heard, run the kernel in
 64bit.
So is a 32bit kernel just default or can't you even upgrade to 64bit OSX if you want to with these older Macs (with 64bit CPUs)? Sounds like a really broken mess.. probably the DMD for OSX should stick to 32bit or universal binaries.
It might look messy, but in reality it's doesn't matter much. First, there is no 64-bit or 32-bit version of OS X, both versions are installed at the same time. Second, the 32-bit kernel is able to run 64-bit programs just fine if you have a 64-bit CPU, just like the 64-bit kernel can run 32-bit programs. The reason very few Macs run the kernel in 64-bit in the current version of Mac OS X is to avoid breaking older 32-bit third-party drivers (which must run inside the kernel's address space). So unless you do driver programming, you generally don't care at all in which mode the kernel is running. Note that which kernel to use is determined at boot time. You can hold the 6 and 4 keys while you boot to force the 64-bit kernel to be used.
Thanks for explaining. Interesting that this works, I have never before heard of a 32bit kernel executing 64bit binaries. But still the issues with Core Solo and Core Duo (without "2") CPUs remain, so at least as long as DMD supports versions of OSX that support these (32bit only) CPUs, we need 32bit binaries. Cheers, - Daniel
Jun 29 2011