August 13, 2012 Re: First working Win64 program! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | On Monday, 13 August 2012 at 04:44:43 UTC, Nick Sabalausky wrote:
>> It's not the current plan. Frankly, I think 32 bits is rapidly
>> becoming irrelevant on the desktop.
>
> Bullshit.
While I agree with the sentiment (in fact, one of my newest computers
is 32 bit; I got a mini laptop - not quite netbook, but not regular
laptop either - that is 32 bit), it is worth noting that 32 bit
D isn't going away.
We're going to be in the same boat we're in now, which does work.
|
August 13, 2012 Re: First working Win64 program! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Monday, August 13, 2012 02:51:30 Walter Bright wrote:
> 64 bits is far more important. We don't have arrows for every target, we have to pick the juiciest ones.
I have no idea how much mork work it is to add 32-bit COFF on top of adding 64-bit COFF, and I'm totally fine with just targeting 64-bit COFF for now. I'm just pointing out that there's a definite cost to not having 32-bit COFF support on Windows, whereas your posts seem to imply that you don't think that it's important at all.
- Jonathan M Davis
|
August 13, 2012 Re: First working Win64 program! | ||||
---|---|---|---|---|
| ||||
Posted in reply to d_follower | On 8/13/2012 3:55 AM, d_follower wrote:
> Does that mean that we get x64 support on Windows (without legacy OMF support)?
> Linking with MSVC-produced libraries will work, too?
Yes.
|
August 13, 2012 Re: First working Win64 program! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On 8/13/2012 6:23 AM, Jacob Carlborg wrote:
> On 2012-08-13 08:21, Walter Bright wrote:
>
>> We'll see. It has already happened on OSX.
>
> The good think on Mac OS X is that basically all system libraries are universal
> binaries (both 32 and 64bit) meaning it really doesn't matter for the user if an
> application is 32 or 64bit.
>
> BTW, around 6.6% of my currently running processes are 32bit. Mac OS X 10.7 Lion.
True, but consider that dmd is a 64 bit app, and nobody either complains about it or notices, and dmd by default produces a 64 bit app, and as far as I can tell, nobody has noticed that either.
|
August 13, 2012 Re: OSX and 64-bit [Re: First working Win64 program!] | ||||
---|---|---|---|---|
| ||||
On Aug 13, 2012, at 12:04 AM, Russel Winder <russel@winder.org.uk> wrote:
> On Sun, 2012-08-12 at 23:29 -0700, Jonathan M Davis wrote: […]
>> OSX has a lot less backwards compatibility to worry about.
>
> Not entirely true.
>
> <semi-rant>
> Apple's strategy appears to be that computers are non-upgradable,
> non-repairable, disposable items that last until the next release:
> everyone is supposed buy the latest version as soon as it comes out and
> so be on the latest kit(*). Therefore Apple don't care about backward
> compatibility in the way some other manufacturers do, e.g. JDK for the
> last 17 years. Of course sometimes this backfires, cf. many white
> MacBooks which have 64-bit processors but 32-bit boot PROMs. OSX detects
> this and will not boot 64-bit. This leads to extraordinary problems
> trying to compile some codes where the compiler detects 64-bit processor
> and assumes a 64-bit kernel API. To build some applications I first have
> to build the whole compiler toolchain so as to deal with this mixed
> chaos.
>
> (*) And as we know there are a lot of people who actually do this, which
> is why there is a great market in second hand Apple kit, which is fine
> for me, since it is reasonable kit at a reasonable price. Unlike new
> kit.
> </semi-rant>
Strangely,libc on OSX is very backwards-compatible. To the point where buggy functions were preserved as-is and updated versions exported via weird labels linked by the compiler using some evil macro code. Needless to say, D unfortunalely links to the buggy versions because there's no way to express the new symbols in-language. I suppose I should try to sort something out using string mixins and inline assembler.
|
August 13, 2012 Re: First working Win64 program! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Monday, 13 August 2012 at 18:29:13 UTC, Walter Bright wrote:
> On 8/13/2012 6:23 AM, Jacob Carlborg wrote:
>> On 2012-08-13 08:21, Walter Bright wrote:
>>
>>> We'll see. It has already happened on OSX.
>>
>> The good think on Mac OS X is that basically all system libraries are universal
>> binaries (both 32 and 64bit) meaning it really doesn't matter for the user if an
>> application is 32 or 64bit.
>>
>> BTW, around 6.6% of my currently running processes are 32bit. Mac OS X 10.7 Lion.
>
> True, but consider that dmd is a 64 bit app, and nobody either complains about it or notices, and dmd by default produces a 64 bit app, and as far as I can tell, nobody has noticed that either.
I noticed! But it hasn't been a problem. One of the things I've actually been using D for is writing simple tools for work, to be executed while in livedisc environments (diagnostics and the like), so I have to keep both 32b and 64b versions of everything, and the only missing component was 64b for Windows. So yeah, I'm pretty stoked about this.
|
August 13, 2012 Re: OSX and 64-bit [Re: First working Win64 program!] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | On 8/13/2012 12:41 PM, Sean Kelly wrote:
> Strangely,libc on OSX is very backwards-compatible. To the point where buggy
> functions were preserved as-is and updated versions exported via weird labels
> linked by the compiler using some evil macro code. Needless to say, D
> unfortunalely links to the buggy versions because there's no way to express
> the new symbols in-language. I suppose I should try to sort something out
> using string mixins and inline assembler.
An easy way is to write a .c file for druntime that accepts the call to the buggy function and calls the un-buggy one. That way the magic macros will work.
I've thought many times about adding a D feature that allows one to specify "use this random character string instead of the identifier as the symbol name when writing the object file", but never got around to it.
|
August 13, 2012 Re: OSX and 64-bit [Re: First working Win64 program!] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 13-08-2012 23:34, Walter Bright wrote: > On 8/13/2012 12:41 PM, Sean Kelly wrote: >> Strangely,libc on OSX is very backwards-compatible. To the point where >> buggy >> functions were preserved as-is and updated versions exported via weird >> labels >> linked by the compiler using some evil macro code. Needless to say, D >> unfortunalely links to the buggy versions because there's no way to >> express >> the new symbols in-language. I suppose I should try to sort something out >> using string mixins and inline assembler. > > An easy way is to write a .c file for druntime that accepts the call to > the buggy function and calls the un-buggy one. That way the magic macros > will work. > > I've thought many times about adding a D feature that allows one to > specify "use this random character string instead of the identifier as > the symbol name when writing the object file", but never got around to it. > I've wanted a feature like that on several occasions (mostly when interfacing with non-C/C++ languages). How hard it would it be to implement? Theoretically, it sounds simple enough. -- Alex Rønne Petersen alex@lycus.org http://lycus.org |
August 13, 2012 Re: OSX and 64-bit [Re: First working Win64 program!] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | On 8/13/2012 2:37 PM, Alex Rønne Petersen wrote:
> I've wanted a feature like that on several occasions (mostly when interfacing
> with non-C/C++ languages). How hard it would it be to implement? Theoretically,
> it sounds simple enough.
You could do it with a pragma or something. It's always going to look ugly, though.
|
August 13, 2012 Re: OSX and 64-bit [Re: First working Win64 program!] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | No doubt that COFF 64 bits it are good and with high priority, though small, but support of COFF 32 bits will be a gift that will add popularity to dmd. Anyway I have words that add + to 64 bit and to 32 bit tools that supports linking with ms toolset. |
Copyright © 1999-2021 by the D Language Foundation