Re: Is DMD 2.052 32-bit?
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. 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.
Re: Is DMD 2.052 32-bit?
On Fri, 2011-03-11 at 16:02 -0500, lurker wrote: [ . . . ] > The efficiency claim is true. 64-bit architures have much more > registers. This can effectively double the code's performance in most > cases. Loads and stores can also use full 64 bits of bandwidth instead > of 32. Thus again twice as much speed. In general if you worry about > larger binary size, use UPX. Other than that, 64 bit code outperforms > the 32 bit. We want to keep the fastest compiler title, right? There are a large number of assumptions in the claim of "twice as much speed". All the AMD64 registers and ALUs are 64-bit wide but are all the caches? Are all the buses to memory? Are all the memory structures? Is the clock speed the same? Are all the components clocked in the same way? Has anyone got actual experimental data? Is there a benchmark suite? My preference for a 64-bit DMD relate to simplicity of use on Debian and Ubuntu where the packaging is far simpler if 64-bit executables are used throughout -- if those executables are dynamically linked. If they are statically linked there is not the same issues, but then physical size of executable becomes an issue. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Is DMD 2.052 32-bit?
"lurker" wrote in message news:ile2kg$2klo$1...@digitalmars.com... > Jonathan M Davis Wrote: > >> Now, assuming that all of that is taken care, if you're using a 32-bit >> binary on >> a 64-bit system, you're still going to be restricted on how much that >> program >> can use. It doesn't use the native word size of the machine to do what it >> does, >> and in many cases, running a 32-bit program on a 64-bit machine is slower >> than >> running a 64-bit version of that program on that machine (though that's >> going to >> vary from program to program, since there are obviously quite a few >> factors >> which affect efficiency). > > The efficiency claim is true. 64-bit architures have much more registers. > This can effectively double the code's performance in most cases. Loads > and stores can also use full 64 bits of bandwidth instead of 32. Thus > again twice as much speed. In general if you worry about larger binary > size, use UPX. Other than that, 64 bit code outperforms the 32 bit. We > want to keep the fastest compiler title, right? OTOH, 32-bit code on 64-bit already vastly outperforms 32-bit code on a 32-bit machine anyway.
Re: Is DMD 2.052 32-bit?
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
Re: Is DMD 2.052 32-bit?
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.
Re: Is DMD 2.052 32-bit?
Jonathan M Davis Wrote: > Now, assuming that all of that is taken care, if you're using a 32-bit binary > on > a 64-bit system, you're still going to be restricted on how much that program > can use. It doesn't use the native word size of the machine to do what it > does, > and in many cases, running a 32-bit program on a 64-bit machine is slower > than > running a 64-bit version of that program on that machine (though that's going > to > vary from program to program, since there are obviously quite a few factors > which affect efficiency). The efficiency claim is true. 64-bit architures have much more registers. This can effectively double the code's performance in most cases. Loads and stores can also use full 64 bits of bandwidth instead of 32. Thus again twice as much speed. In general if you worry about larger binary size, use UPX. Other than that, 64 bit code outperforms the 32 bit. We want to keep the fastest compiler title, right?
Re: Is DMD 2.052 32-bit?
On Thursday, March 10, 2011 09:29:01 dsimcha wrote: > == Quote from Jonathan M Davis (jmdavisp...@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. Probably the biggest advantage of purity is that it simplifies the system and makes life easier on package management and whatnot. For multilib, you have to have duplicate lib directories (lib and lib32, or lib and lib64, or possibly even lib, lib32, _and_ lib64). You have to make sure that everything is set up correctly so that the 32-bit stuff is where the 32-bit stuff goes and the 64-bit stuff is where the 64-bit stuff goes. You have to make sure that stuff doesn't clash. Some stuff doesn't deal very well with having mutliple architectures on the same box. You have to have more versions of all of the packages that get 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 versions of packages. Etc. Etc. It's not always trivial to mix 32-bit and 64-bit on the same machine, and it does create a fair bit of work for those managing the distros. On some level, it's the same as supporting a whole other achitecture. From the perspective of the user, while they may not have to worry about sorting out all of the lib directories and making sure that packages mix correctly, they _do_ have to worry about getting whatever 32-bit packages they need for something to work. As long as all you're using is distro-released packages, that isn't too bad, but using a 32-bit binary on a 64-bit box when you're not installing it with the package manager can be a pain, because you have to figure out exactly which packages you need for that particular binary to work. There 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 binary on a 64-bit system, you're still going to be restricted on how much that program can use. It doesn't use the native word size of the machine to do what it does, and in many cases, running a 32-bit program on a 64-bit machine is slower than running a 64-bit version of that program on that machine (though that's going to vary from program to program, since there are obviously quite a few factors which affect efficiency). And then of course, there are the people who want the purity of 64-bit for the sake of purity. They don't want to be running 32-bit programs in a 64-bit environment any more than they'd want to be running 16-bit programs in a 32-bit 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 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 number of problems and disadvantages in mixing architectures and running 32-bit programs on 64-bit machines. It's worse for the folks maintaining a distro than the user of a distro, but it can be a definite issue having to deal with 32-bit stuff on a 64-bit box. - Jonathan M Davis
Re: Is DMD 2.052 32-bit?
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.
Re: Is DMD 2.052 32-bit?
On 3/10/11, Jonathan M Davis 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.
Re: Is DMD 2.052 32-bit?
== Quote from Jonathan M Davis (jmdavisp...@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.
Re: Is DMD 2.052 32-bit?
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
Re: Is DMD 2.052 32-bit?
On Thu, 2011-03-10 at 21:19 +0800, KennyTM~ wrote: [ . . . ] > It doubles download time only because binaries of all platforms are > packed into one zip file. ;) Separate them out? I would prefer not to have the Windows stuff in the download pack. [ . . . ] -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Is DMD 2.052 32-bit?
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.)
Re: Is DMD 2.052 32-bit?
On Thu, 10 Mar 2011 01:57:37 -0800 Walter Bright 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 -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA signature.asc Description: PGP signature
Re: Is DMD 2.052 32-bit?
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.
Re: Is DMD 2.052 32-bit?
"Jonathan M Davis" wrote in message news:mailman.2408.1299726495.4748.digitalmar...@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.
Re: Is DMD 2.052 32-bit?
On Wed, 9 Mar 2011 19:08:04 -0800 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. +1 Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: CDBF17CA signature.asc Description: PGP signature
Re: Is DMD 2.052 32-bit?
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
Re: Is DMD 2.052 32-bit?
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.
Re: Is DMD 2.052 32-bit?
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 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: References: 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: use...@digitalmars.com NNTP-Posting-Date: Fri, 7 Jul 2006 20:17:17 + (UTC) User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) In-Reply-To: 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
Re: Is DMD 2.052 32-bit?
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
Re: Is DMD 2.052 32-bit?
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 :)
Re: Is DMD 2.052 32-bit?
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.
Re: Is DMD 2.052 32-bit?
On Wed, 09 Mar 2011 01:24:56 -0600, Jason E. Aten wrote: > On Wed, Mar 9, 2011 at 12:55 AM, 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. >> >> > 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 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"
Re: Is DMD 2.052 32-bit?
Am 09.03.2011 08:24, schrieb Jason E. Aten: On Wed, Mar 9, 2011 at 12:55 AM, Walter Bright mailto:newshou...@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).
Re: Is DMD 2.052 32-bit?
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. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Is DMD 2.052 32-bit?
On Wed, Mar 9, 2011 at 12:55 AM, 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. > 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
Re: Is DMD 2.052 32-bit?
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.
Re: Is DMD 2.052 32-bit?
"teo" 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.
Re: Is DMD 2.052 32-bit?
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.
Re: Is DMD 2.052 32-bit?
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
Re: Is DMD 2.052 32-bit?
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.
Re: Is DMD 2.052 32-bit?
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.
Re: Is DMD 2.052 32-bit?
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
Is DMD 2.052 32-bit?
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.
