www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is DMD 2.052 32-bit?

reply teo <teo.ubuntu yahoo.com> writes:
Is my understanding correct that dmd 2.052 itself is a 32-bit executable?
It can cross compile for 64-bit platforms, but is not a native 64-bit 
compiler.
Mar 08 2011
next sibling parent David Nadlinger <see klickverbot.at> writes:
On 3/8/11 9:37 PM, teo wrote:
 Is my understanding correct that dmd 2.052 itself is a 32-bit executable?
 It can cross compile for 64-bit platforms, but is not a native 64-bit
 compiler.

Yes, you're right. David
Mar 08 2011
prev sibling next sibling parent reply Trass3r <un known.com> writes:
 Is my understanding correct that dmd 2.052 itself is a 32-bit executable?
 It can cross compile for 64-bit platforms, but is not a native 64-bit
 compiler.

Yes, but you can compile an x64 dmd yourself on Linux.
Mar 08 2011
next sibling parent reply teo <teo.ubuntu yahoo.com> writes:
On Tue, 08 Mar 2011 21:45:28 +0100, Trass3r wrote:

 Is my understanding correct that dmd 2.052 itself is a 32-bit
 executable? It can cross compile for 64-bit platforms, but is not a
 native 64-bit compiler.

Yes, but you can compile an x64 dmd yourself on Linux.

Is there any "how to"? If not I will figure it myself out, but need to know where to get the source code from.
Mar 08 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 08.03.2011 22:03, schrieb teo:
 On Tue, 08 Mar 2011 21:45:28 +0100, Trass3r wrote:
 
 Is my understanding correct that dmd 2.052 itself is a 32-bit
 executable? It can cross compile for 64-bit platforms, but is not a
 native 64-bit compiler.

Yes, but you can compile an x64 dmd yourself on Linux.

Is there any "how to"? If not I will figure it myself out, but need to know where to get the source code from.

Download DMD as a zip, the code is included. Cheers, - Daniel
Mar 08 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"teo" <teo.ubuntu yahoo.com> wrote in message 
news:il65ip$1cl8$1 digitalmars.com...
 On Tue, 08 Mar 2011 21:45:28 +0100, Trass3r wrote:

 Is my understanding correct that dmd 2.052 itself is a 32-bit
 executable? It can cross compile for 64-bit platforms, but is not a
 native 64-bit compiler.

Yes, but you can compile an x64 dmd yourself on Linux.

Is there any "how to"? If not I will figure it myself out, but need to know where to get the source code from.

It's in the "src" subdirectory.
Mar 08 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/8/2011 1:23 PM, Trass3r wrote:
 Yes, but you can compile an x64 dmd yourself on Linux.

Is there any "how to"?

IIRC you have to edit linux.mak to use -m64 instead of -m32.

It has worked in the past, but the 64 bit build is not regularly tested.
Mar 08 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 09.03.2011 08:24, schrieb Jason E. Aten:
 On Wed, Mar 9, 2011 at 12:55 AM, Walter Bright
 <newshound2 digitalmars.com <mailto:newshound2 digitalmars.com>> wrote:

     On 3/8/2011 1:23 PM, Trass3r wrote:

                 Yes, but you can compile an x64 dmd yourself on Linux.


             Is there any "how to"?


         IIRC you have to edit linux.mak to use -m64 instead of -m32.


     It has worked in the past, but the 64 bit build is not regularly tested.


 When I tried this last week, changing -m32 to -m64 got me a clean 64-bit
 build of dmd2, with no build errors.  Very easy.

 A caveat-- I tried the same search and replace s/32/64/ in places on the
 druntime and phobos makefiles, but there was something more subtle going
 on--the generated libraries built fine but were still 32-bit objects
 inside the .a archives.  Somehow I wasn't passing the right flags to
 generate 64-bit libraries.

 Is there a flag to tell dmd to compile to 64-bit objects?

 Thanks,
 Jason

since 2.052 the -m64 flag should be supported to compile 64bit binaries (on Linux).
Mar 09 2011
prev sibling next sibling parent reply Nebster <Evil.Nebster gmail.com> writes:
On 09/03/2011 06:55, Walter Bright wrote:
 On 3/8/2011 1:23 PM, Trass3r wrote:
 Yes, but you can compile an x64 dmd yourself on Linux.

Is there any "how to"?

IIRC you have to edit linux.mak to use -m64 instead of -m32.

It has worked in the past, but the 64 bit build is not regularly tested.

Does the toolchain compile on windows in 64 bit too? It's awesome you're finally starting the transition :)
Mar 09 2011
next sibling parent Nebster <Evil.Nebster gmail.com> writes:
On 10/03/2011 00:30, Jonathan M Davis wrote:
 On Wednesday, March 09, 2011 16:23:15 Nebster wrote:
 On 09/03/2011 06:55, Walter Bright wrote:
 On 3/8/2011 1:23 PM, Trass3r wrote:
 Yes, but you can compile an x64 dmd yourself on Linux.

Is there any "how to"?

IIRC you have to edit linux.mak to use -m64 instead of -m32.

It has worked in the past, but the 64 bit build is not regularly tested.

Does the toolchain compile on windows in 64 bit too? It's awesome you're finally starting the transition :)

No. Regardless of whether you could build dmd itself as 64-bit (which is questionable), the linker is only 32-bit, and since it's written in assembly, you _definitely_ can't compile that as 64-bit. So, you don't have 64-bit on Windows - either the dmd binary or the binaries that it produces. And honestly, Path: digitalmars.com!not-for-mail From: Sean Kelly<sean f4.ca> Newsgroups: digitalmars.D Subject: Re: If D becomes a failure, what's the key reason, do you think? Date: Fri, 07 Jul 2006 13:17:17 -0700 Organization: Digital Mars Lines: 5 Message-ID:<e8mfgd$1hqe$1 digitaldaemon.com> References:<e8khb5$160j$1 digitaldaemon.com> <e8klm3$1b23$1 digitaldaemon.com> <e8kp39$1fol$1 digitaldaemon.com> <e8l426$26o3$1 digitaldaemon.com> <e8m6pv$15bp$1 digitaldaemon.com> <e8m9m3$19t5$1 digitaldaemon.com> <e8mbuv$1cm4$1 digitaldaemon.com> <e8meq3$1go2$2 digitaldaemon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: digitaldaemon.com 1152303437 51022 216.127.61.99 (7 Jul 2006 20:17:17 GMT) X-Complaints-To: usenet digitalmars.com NNTP-Posting-Date: Fri, 7 Jul 2006 20:17:17 +0000 (UTC) User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) In-Reply-To:<e8meq3$1go2$2 digitaldaemon.com> Xref: digitalmars.com digitalmars.D:39708 Walter Bright wrote:
 Not for 1.0.

Thanks :-)

Hehe, thanks for the response. I know about the linker but I was looking into the new version of UniLink which has support for D now afaik! It's not that much of a problem for me at the moment anyway :) Thanks, Nebster
Mar 09 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/9/2011 4:30 PM, Jonathan M Davis wrote:
 Much as I'd love to have a 64-bit binary of dmd, I don't think that the gain is
 even vaguely worth the risk at this point.

What is the gain? The only thing I can think of is some 64 bit OS distributions are hostile to 32 bit binaries.
Mar 09 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/9/2011 7:08 PM, Jonathan M Davis wrote:
 Truth be told, I would have thought that it would be a given that there would
be
 a 64-bit version of dmd when going to support 64-bit compilation and was quite
 surprised when that was not your intention.

Adding another set of binaries doubles the testing time and download times for users.
Mar 10 2011
next sibling parent KennyTM~ <kennytm gmail.com> writes:
On Mar 10, 11 17:57, Walter Bright wrote:
 On 3/9/2011 7:08 PM, Jonathan M Davis wrote:
 Truth be told, I would have thought that it would be a given that
 there would be
 a 64-bit version of dmd when going to support 64-bit compilation and
 was quite
 surprised when that was not your intention.

Adding another set of binaries doubles the testing time and download times for users.

It doubles download time only because binaries of all platforms are packed into one zip file. ;) (Not that I think 64-bit dmd is needed.)
Mar 10 2011
prev sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Jonathan M Davis (jmdavisProg gmx.com)'s article
 Linux distros _definitely_ prefer to have native binaries, and those that try
and
 be 64-bit pure _can't_ use 32-bit binaries unless those binaries are completely
 statically linked - though multilib is still the most common scenario for
64-bit
 versions of most Linux distros.

Out of curiosity, what's the advantage of this purity, other than a fairly inconsequential amount of disk space and bandwidth savings? 32-bit can even be _more_ efficient for certain things because pointers are only 4 bytes instead of 8.
Mar 10 2011
prev sibling parent reply lurker <a a.a> writes:
Jonathan M Davis Wrote:

 On Wednesday 09 March 2011 17:56:13 Walter Bright wrote:
 On 3/9/2011 4:30 PM, Jonathan M Davis wrote:
 Much as I'd love to have a 64-bit binary of dmd, I don't think that the
 gain is even vaguely worth the risk at this point.

What is the gain? The only thing I can think of is some 64 bit OS distributions are hostile to 32 bit binaries.

Well, the fact that you then have a binary native to your system is obviously a gain (and is likely the one which people will cite most often), and that _does_ count for quite a lot. However, regardless of that, it's actually pretty easy to get dmd to run out of memory when compiling if you do much in the way of CTFE or template stuff. Granted, fixing some of the worst memory-related bugs in dmd will go a _long_ way towards fixing that, but even if they are, you're theoretically eventually supposed to be able to do pretty much anything at compile time which you can do at runtime in SafeD. And using enough memory that you require the 64- bit address space would be one of the things that you can do in SafeD when compiling for 64-bit. As long as the compiler is only 32-bit, you can't do that at compile time even though you can do it at runtime (though the current limitations of CTFE do reduce the problem in that you can't do a lot of stuff at compile time period). In any case, the fact that dmd runs out of memory fairly easily makes having a 64-bit version which could use all of my machine's memory really attractive. And honestly, having an actual, 64-bit binary to run on a 64-bit system is something that people generally want, and it _is_ definitely a problem to get a 32-bit binary into the 64-bit release of a Liunx distro. Truth be told, I would have thought that it would be a given that there would be a 64-bit version of dmd when going to support 64-bit compilation and was quite surprised when that was not your intention.

I think porting DMD to 64 bits would be a pragmatic solution to this. Computers are getting more memory faster than Walter is able to fix possible leaks in DMD. There's awful lots of template and CTFE code using more than 2 or 3 GB of RAM. I can't even imagine how one could develop some modern application if this was a hard limit. Luckily there are GDC and LDC, which allow enterprise users to take full advantage of the 24-64 GB available. Some simple use case would be Facebook's infrastructure. Assume Andrei wanted to rewrite it all in D. Probably more than 100M LOC. Would need hundreds of gigabytes of RAM to compile. It would also take days to compile, and maybe 50% less on a 64 bit system.
Mar 11 2011
parent Don <nospam nospam.com> writes:
lurker wrote:
 Jonathan M Davis Wrote:
 
 On Wednesday 09 March 2011 17:56:13 Walter Bright wrote:
 On 3/9/2011 4:30 PM, Jonathan M Davis wrote:
 Much as I'd love to have a 64-bit binary of dmd, I don't think that the
 gain is even vaguely worth the risk at this point.

distributions are hostile to 32 bit binaries.

gain (and is likely the one which people will cite most often), and that _does_ count for quite a lot. However, regardless of that, it's actually pretty easy to get dmd to run out of memory when compiling if you do much in the way of CTFE or template stuff. Granted, fixing some of the worst memory-related bugs in dmd will go a _long_ way towards fixing that, but even if they are, you're theoretically eventually supposed to be able to do pretty much anything at compile time which you can do at runtime in SafeD. And using enough memory that you require the 64- bit address space would be one of the things that you can do in SafeD when compiling for 64-bit. As long as the compiler is only 32-bit, you can't do that at compile time even though you can do it at runtime (though the current limitations of CTFE do reduce the problem in that you can't do a lot of stuff at compile time period). In any case, the fact that dmd runs out of memory fairly easily makes having a 64-bit version which could use all of my machine's memory really attractive. And honestly, having an actual, 64-bit binary to run on a 64-bit system is something that people generally want, and it _is_ definitely a problem to get a 32-bit binary into the 64-bit release of a Liunx distro. Truth be told, I would have thought that it would be a given that there would be a 64-bit version of dmd when going to support 64-bit compilation and was quite surprised when that was not your intention.

I think porting DMD to 64 bits would be a pragmatic solution to this.

 Computers are getting more memory faster than Walter is able to fix possible
leaks in DMD.

No. This has nothing to do with memory leaks. The slowdown and excessive memory consumption is caused by a few lines of code. Fixing that 'bug' (really, the existing CTFE memory management (ie, non-existent!) was a quick hack to get things running) won't just make it consume 2 or 3 times less memory. We're talking 100x, 1000x, etc.
Mar 12 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, March 09, 2011 16:23:15 Nebster wrote:
 On 09/03/2011 06:55, Walter Bright wrote:
 On 3/8/2011 1:23 PM, Trass3r wrote:
 Yes, but you can compile an x64 dmd yourself on Linux.

Is there any "how to"?

IIRC you have to edit linux.mak to use -m64 instead of -m32.

It has worked in the past, but the 64 bit build is not regularly tested.

Does the toolchain compile on windows in 64 bit too? It's awesome you're finally starting the transition :)

No. Regardless of whether you could build dmd itself as 64-bit (which is questionable), the linker is only 32-bit, and since it's written in assembly, you _definitely_ can't compile that as 64-bit. So, you don't have 64-bit on Windows - either the dmd binary or the binaries that it produces. And honestly, I'd be _very_ leery - make that _extremely leery - of using a 64-bit build of dmd on _any_ OS before Walter actually makes sure that it works as 64-bit and maintains it as such. Much as I'd love to have a 64-bit binary of dmd, I don't think that the gain is even vaguely worth the risk at this point. - Jonathan M Davis
Mar 09 2011
prev sibling next sibling parent Trass3r <un known.com> writes:
 Yes, but you can compile an x64 dmd yourself on Linux.

Is there any "how to"?

IIRC you have to edit linux.mak to use -m64 instead of -m32.
Mar 08 2011
prev sibling next sibling parent "Jason E. Aten" <j.e.aten gmail.com> writes:
--00163646da7437a3bc049e07a0d0
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Mar 9, 2011 at 12:55 AM, Walter Bright
<newshound2 digitalmars.com>wrote:

 On 3/8/2011 1:23 PM, Trass3r wrote:

 Yes, but you can compile an x64 dmd yourself on Linux.

Is there any "how to"?

IIRC you have to edit linux.mak to use -m64 instead of -m32.

It has worked in the past, but the 64 bit build is not regularly tested.

When I tried this last week, changing -m32 to -m64 got me a clean 64-bit build of dmd2, with no build errors. Very easy. A caveat-- I tried the same search and replace s/32/64/ in places on the druntime and phobos makefiles, but there was something more subtle going on--the generated libraries built fine but were still 32-bit objects inside the .a archives. Somehow I wasn't passing the right flags to generate 64-bit libraries. Is there a flag to tell dmd to compile to 64-bit objects? Thanks, Jason --00163646da7437a3bc049e07a0d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Mar 9, 2011 at 12:55 AM, Walter Bright <span dir=3D"ltr">&lt;<a hre= f=3D"mailto:newshound2 digitalmars.com">newshound2 digitalmars.com</a>&gt;<= /span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot= e" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204,= 204); padding-left: 1ex;"> <div><div></div><div class=3D"h5">On 3/8/2011 1:23 PM, Trass3r wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class= =3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid= rgb(204, 204, 204); padding-left: 1ex;"> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Yes, but you can compile an x64 dmd yourself on Linux.<br> </blockquote> <br> Is there any &quot;how to&quot;?<br> </blockquote> <br> IIRC you have to edit linux.mak to use -m64 instead of -m32.<br> </blockquote> <br></div></div> It has worked in the past, but the 64 bit build is not regularly tested.<br=

ot me a clean 64-bit build of dmd2, with no build errors.=A0 Very easy.<br>= <br>A caveat-- I tried the same search and replace s/32/64/ in places on th= e druntime and phobos makefiles, but there was something more subtle going = on--the generated libraries built fine but were still 32-bit objects inside= the .a archives.=A0 Somehow I wasn&#39;t passing the right flags to genera= te 64-bit libraries.<br> <br>Is there a flag to tell dmd to compile to 64-bit objects?<br><br>Thanks= ,<br>Jason<br> --00163646da7437a3bc049e07a0d0--
Mar 08 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-03-08 at 22:55 -0800, Walter Bright wrote:
 On 3/8/2011 1:23 PM, Trass3r wrote:
 Yes, but you can compile an x64 dmd yourself on Linux.

Is there any "how to"?

IIRC you have to edit linux.mak to use -m64 instead of -m32.

It has worked in the past, but the 64 bit build is not regularly tested.

Sounds like there is a need for a build test farm. Buildbot or Jenkins would provide good infrastructure. --=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
Mar 08 2011
prev sibling next sibling parent jam <gr0v3er+d gmail.com> writes:
On Wed, 09 Mar 2011 01:24:56 -0600, Jason E. Aten wrote:

 On Wed, Mar 9, 2011 at 12:55 AM, Walter Bright
 <newshound2 digitalmars.com>wrote:
 
 On 3/8/2011 1:23 PM, Trass3r wrote:

 Yes, but you can compile an x64 dmd yourself on Linux.



tested.

build of dmd2, with no build errors. Very easy. A caveat-- I tried the same search and replace s/32/64/ in places on the druntime and phobos makefiles, but there was something more subtle going on--the generated libraries built fine but were still 32-bit objects inside the .a archives. Somehow I wasn't passing the right flags to generate 64-bit libraries. Is there a flag to tell dmd to compile to 64-bit objects? Thanks, Jason

In addition to changing the MODEL env variable in the makefiles, I also had to pass the -m64 flag to the dmd binary to build x64 libphobos.a and libdruntime.a i.e. make -f posix.mak DMD="PATH_TO_DMD -m64"
Mar 09 2011
prev sibling parent teo <teo.ubuntu yahoo.com> writes:
On Tue, 08 Mar 2011 22:23:19 +0100, Trass3r wrote:

 Yes, but you can compile an x64 dmd yourself on Linux.

Is there any "how to"?

IIRC you have to edit linux.mak to use -m64 instead of -m32.

Ok, I wrote a simple bash script: ===BEGIN=== #!/bin/bash echo "building dmd..." cd ./dmd make -f linux.mak MODEL=-m64 cd .. if [ ! -f ./dmd/dmd ] then echo "failed." exit 1 fi echo "building druntime..." cd ./druntime make -f posix.mak MODEL=64 DMD=../dmd/dmd cd .. echo "building phobos..." cd ./phobos make -f posix.mak MODEL=64 DMD=../dmd/dmd cd .. ===END=== You have to put it in dmd2/src. I got a clean build on Ubuntu 10.04 x86_64 with GCC 4.4.3 and GNU Make 3.81.
Mar 09 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday 09 March 2011 17:56:13 Walter Bright wrote:
 On 3/9/2011 4:30 PM, Jonathan M Davis wrote:
 Much as I'd love to have a 64-bit binary of dmd, I don't think that the
 gain is even vaguely worth the risk at this point.

What is the gain? The only thing I can think of is some 64 bit OS distributions are hostile to 32 bit binaries.

Well, the fact that you then have a binary native to your system is obviously a gain (and is likely the one which people will cite most often), and that _does_ count for quite a lot. However, regardless of that, it's actually pretty easy to get dmd to run out of memory when compiling if you do much in the way of CTFE or template stuff. Granted, fixing some of the worst memory-related bugs in dmd will go a _long_ way towards fixing that, but even if they are, you're theoretically eventually supposed to be able to do pretty much anything at compile time which you can do at runtime in SafeD. And using enough memory that you require the 64- bit address space would be one of the things that you can do in SafeD when compiling for 64-bit. As long as the compiler is only 32-bit, you can't do that at compile time even though you can do it at runtime (though the current limitations of CTFE do reduce the problem in that you can't do a lot of stuff at compile time period). In any case, the fact that dmd runs out of memory fairly easily makes having a 64-bit version which could use all of my machine's memory really attractive. And honestly, having an actual, 64-bit binary to run on a 64-bit system is something that people generally want, and it _is_ definitely a problem to get a 32-bit binary into the 64-bit release of a Liunx distro. Truth be told, I would have thought that it would be a given that there would be a 64-bit version of dmd when going to support 64-bit compilation and was quite surprised when that was not your intention. - Jonathan M Davis
Mar 09 2011
parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.2408.1299726495.4748.digitalmars-d puremagic.com...
 On Wednesday 09 March 2011 17:56:13 Walter Bright wrote:
 On 3/9/2011 4:30 PM, Jonathan M Davis wrote:
 Much as I'd love to have a 64-bit binary of dmd, I don't think that the
 gain is even vaguely worth the risk at this point.

What is the gain? The only thing I can think of is some 64 bit OS distributions are hostile to 32 bit binaries.

Well, the fact that you then have a binary native to your system is obviously a gain (and is likely the one which people will cite most often), and that _does_ count for quite a lot.

Specifically?
 However, regardless of that, it's actually pretty easy to
 get dmd to run out of memory when compiling if you do much in the way of 
 CTFE or
 template stuff. Granted, fixing some of the worst memory-related bugs in 
 dmd will
 go a _long_ way towards fixing that, but even if they are, you're 
 theoretically
 eventually supposed to be able to do pretty much anything at compile time 
 which
 you can do at runtime in SafeD. And using enough memory that you require 
 the 64-
 bit address space would be one of the things that you can do in SafeD when
 compiling for 64-bit. As long as the compiler is only 32-bit, you can't do 
 that
 at compile time even though you can do it at runtime (though the current
 limitations of CTFE do reduce the problem in that you can't do a lot of 
 stuff at
 compile time period).

 In any case, the fact that dmd runs out of memory fairly easily makes 
 having a
 64-bit version which could use all of my machine's memory really 
 attractive. And
 honestly, having an actual, 64-bit binary to run on a 64-bit system is 
 something
 that people generally want, and it _is_ definitely a problem to get a 
 32-bit
 binary into the 64-bit release of a Liunx distro.

 Truth be told, I would have thought that it would be a given that there 
 would be
 a 64-bit version of dmd when going to support 64-bit compilation and was 
 quite
 surprised when that was not your intention.

I'd be more interested in a build of DMD that just doesn't eat memory like popcorn.
Mar 09 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, 9 Mar 2011 19:08:04 -0800
Jonathan M Davis <jmdavisProg gmx.com> wrote:


 Truth be told, I would have thought that it would be a given that
 there would be a 64-bit version of dmd when going to support 64-bit
 compilation and was quite surprised when that was not your intention.

+1 Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA
Mar 09 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, 10 Mar 2011 01:57:37 -0800
Walter Bright <newshound2 digitalmars.com> wrote:

 Adding another set of binaries doubles the testing time and download
 times for users.

Maybe some buildbot could be configured to automate such tasks. Download time is, imho, not significant obstacle to have 64bit release. Actually, I do not know about any 32bit compiler which goes 64bit code generation...all of 'em have native binaries... Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA
Mar 10 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2011-03-10 at 21:19 +0800, KennyTM~ wrote:
[ . . . ]
 It doubles download time only because binaries of all platforms are=20
 packed into one zip file. ;)

Separate them out? I would prefer not to have the Windows stuff in the download pack. [ . . . ] --=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
Mar 10 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday 10 March 2011 01:57:37 Walter Bright wrote:
 On 3/9/2011 7:08 PM, Jonathan M Davis wrote:
 Truth be told, I would have thought that it would be a given that there
 would be a 64-bit version of dmd when going to support 64-bit
 compilation and was quite surprised when that was not your intention.

Adding another set of binaries doubles the testing time and download times for users.

The testing time, I understand. The download times seems pretty inconsequential to me and not a big deal at all (and as Gour points out, you could have separate zip files for separate architectures). However, it's a given that people are going to want a full 64-bit binary and to some extent will expect it. It's not at all normal to produce 64-bit binaries from a 32-bit compiler. Obviously such cross-compiling _can_ be done and sometimes is, but it's not at all the norm, and the more naive folks probably don't even think that you can do that, so having a 32-bit binary produce 64-bit code will confuse the less experienced. Linux distros _definitely_ prefer to have native binaries, and those that try and be 64-bit pure _can't_ use 32-bit binaries unless those binaries are completely statically linked - though multilib is still the most common scenario for 64-bit versions of most Linux distros. Still, they lean heavily towards 64-bit and generally try to use absolutely as little 32-bit as possible. So, having a 32-bit binary produce 64-bit binaries works, and it's better than having no 64-bit support, but in the long run, it really is preferable to have a 64-bit binary for dmd. I understand if that's not exactly a high priority at the moment (and I agree that there are more important issues), but I would still expect that we'd get a 64-bit dmd binary eventually. - Jonathan M Davis
Mar 10 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/10/11, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 The download times seems pretty
 inconsequential
 to me and not a big deal at all.

Except for the fact that Walter is the only person with the legal right to distribute DMD + downloading is slow from digitalmars.com. I get around ~100Kb/sec average and often times much slower download speeds even though my download speed easily reaches 500Kb/sec on other websites. What will happen when D gets more popular? The site will likely slow down to a crawl. I'm saying we'll eventually need mirrors to download from, but this isn't going to happen with the current legal shenanigans.
Mar 10 2011
prev sibling next sibling parent "Jason E. Aten" <j.e.aten gmail.com> writes:
--0016e6da98b71649ce049e24c6b1
Content-Type: text/plain; charset=ISO-8859-1

An alternative: I would point out that LDC2 is 64-bit and open source.  It
lets you target a multitude of architectures, including, recently, OpenCL
for GPGPU.  Heck, you might even be able to cross compile from Linux and
target your system of choice.

So if you really want 64-bit support for platform X, you could likely add it
to LDC2 without too much work.

Jason

-- 
Jason E. Aten, Ph.D.

--0016e6da98b71649ce049e24c6b1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>An alternative: I would point out that LDC2 is 64-bit and open source.=
=A0 It lets you target a multitude of architectures, including, recently, O=
penCL for GPGPU.=A0 Heck, you might even be able to cross compile from Linu=
x and target your system of choice.<br>
<br>So if you really want 64-bit support for platform X, you could likely a=
dd it to LDC2 without too much work.<br clear=3D"all"><br>Jason<br><br>-- <=
br>Jason E. Aten, Ph.D.<br><br>

--0016e6da98b71649ce049e24c6b1--
Mar 10 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, March 10, 2011 09:29:01 dsimcha wrote:
 =3D=3D Quote from Jonathan M Davis (jmdavisProg gmx.com)'s article
=20
 Linux distros _definitely_ prefer to have native binaries, and those th=


 try and be 64-bit pure _can't_ use 32-bit binaries unless those binaries
 are completely statically linked - though multilib is still the most
 common scenario for 64-bit versions of most Linux distros.

Out of curiosity, what's the advantage of this purity, other than a fairly inconsequential amount of disk space and bandwidth savings? 32-bit can even be _more_ efficient for certain things because pointers are only 4 bytes instead of 8.

Probably the biggest advantage of purity is that it simplifies the system a= nd=20 makes life easier on package management and whatnot. For multilib, you have= to=20 have duplicate lib directories (lib and lib32, or lib and lib64, or possibl= y=20 even lib, lib32, _and_ lib64). You have to make sure that everything is set= up=20 correctly so that the 32-bit stuff is where the 32-bit stuff goes and the 6= 4-bit=20 stuff is where the 64-bit stuff goes. You have to make sure that stuff does= n't=20 clash. Some stuff doesn't deal very well with having mutliple architectures= on=20 the same box. You have to have more versions of all of the packages that ge= t=20 duplicated. You have to maintain 32-bit versions of packages targetted for = 64- bit systems in addition to the normal 32-bit versions and the 64-bit versio= ns of=20 packages. Etc. Etc. It's not always trivial to mix 32-bit and 64-bit on the same machine, and i= t=20 does create a fair bit of work for those managing the distros. On some leve= l,=20 it's the same as supporting a whole other achitecture. =46rom the perspective of the user, while they may not have to worry about = sorting=20 out all of the lib directories and making sure that packages mix correctly,= they=20 _do_ have to worry about getting whatever 32-bit packages they need for=20 something to work. As long as all you're using is distro-released packages,= that=20 isn't too bad, but using a 32-bit binary on a 64-bit box when you're not=20 installing it with the package manager can be a pain, because you have to f= igure=20 out exactly which packages you need for that particular binary to work. The= re=20 have been plenty of problems with people trying to get dmd working on their= 64- bit machines. It doesn't just work out of the box. Now, assuming that all of that is taken care, if you're using a 32-bit bina= ry on=20 a 64-bit system, you're still going to be restricted on how much that progr= am=20 can use. It doesn't use the native word size of the machine to do what it d= oes,=20 and in many cases, running a 32-bit program on a 64-bit machine is slower t= han=20 running a 64-bit version of that program on that machine (though that's goi= ng to=20 vary from program to program, since there are obviously quite a few factor= s=20 which affect efficiency). And then of course, there are the people who want the purity of 64-bit for = the=20 sake of purity. They don't want to be running 32-bit programs in a 64-bit=20 environment any more than they'd want to be running 16-bit programs in a 32= =2Dbit=20 environment. They want a 64-bit machine to be running 64-bit code. And I'm sure that there are other reasons/advantages/disadvantages, but I=20 believe that the average user who is aware of the issue wants to be running= 64- bit programs on 64-bit machines, not 32-bit programs. And there _are_ a num= ber=20 of problems and disadvantages in mixing architectures and running 32-bit=20 programs on 64-bit machines. It's worse for the folks maintaining a distro = than=20 the user of a distro, but it can be a definite issue having to deal with 32= =2Dbit=20 stuff on a 64-bit box. =2D Jonathan M Davis
Mar 10 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, March 11, 2011 13:11:53 lurker wrote:
 Jonathan M Davis Wrote:
 On Wednesday 09 March 2011 17:56:13 Walter Bright wrote:
 On 3/9/2011 4:30 PM, Jonathan M Davis wrote:
 Much as I'd love to have a 64-bit binary of dmd, I don't think that
 the gain is even vaguely worth the risk at this point.

What is the gain? The only thing I can think of is some 64 bit OS distributions are hostile to 32 bit binaries.

Well, the fact that you then have a binary native to your system is obviously a gain (and is likely the one which people will cite most often), and that _does_ count for quite a lot. However, regardless of that, it's actually pretty easy to get dmd to run out of memory when compiling if you do much in the way of CTFE or template stuff. Granted, fixing some of the worst memory-related bugs in dmd will go a _long_ way towards fixing that, but even if they are, you're theoretically eventually supposed to be able to do pretty much anything at compile time which you can do at runtime in SafeD. And using enough memory that you require the 64- bit address space would be one of the things that you can do in SafeD when compiling for 64-bit. As long as the compiler is only 32-bit, you can't do that at compile time even though you can do it at runtime (though the current limitations of CTFE do reduce the problem in that you can't do a lot of stuff at compile time period). In any case, the fact that dmd runs out of memory fairly easily makes having a 64-bit version which could use all of my machine's memory really attractive. And honestly, having an actual, 64-bit binary to run on a 64-bit system is something that people generally want, and it _is_ definitely a problem to get a 32-bit binary into the 64-bit release of a Liunx distro. Truth be told, I would have thought that it would be a given that there would be a 64-bit version of dmd when going to support 64-bit compilation and was quite surprised when that was not your intention.

I think porting DMD to 64 bits would be a pragmatic solution to this. Computers are getting more memory faster than Walter is able to fix possible leaks in DMD. There's awful lots of template and CTFE code using more than 2 or 3 GB of RAM. I can't even imagine how one could develop some modern application if this was a hard limit. Luckily there are GDC and LDC, which allow enterprise users to take full advantage of the 24-64 GB available. Some simple use case would be Facebook's infrastructure. Assume Andrei wanted to rewrite it all in D. Probably more than 100M LOC. Would need hundreds of gigabytes of RAM to compile. It would also take days to compile, and maybe 50% less on a 64 bit system.

It's not that bad. dmd has some serious memory leaks with regards to CTFE and templates in that it generally doesn't release memory for a lot of it until it's done. So, it uses _way_ more memory that it needs to. I don't know why it does things the way it does, but theoretically, it should be able to reduce that to sane levels on 32-bit. I expect that it just requires taking the time to do it. Also, in most cases, if using too much memory due to CTFE or templates is a problem, then all you have to do is do incremental builds and build each module separately. Then you're usually fine. So, while having a 64-bit dmd would definitely help alleviate dmd's memory issues, those memory issues _do_ need to be fixed regardless. And fixing them would almost certainly make it dmd's memory consumption acceptable with 32-bit in most cases. - Jonathan M Davis
Mar 11 2011