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