View mode: basic / threaded / horizontal-split · Log in · Help
August 13, 2012
Re: First working Win64 program!
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!
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!
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!
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!
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!]
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!]
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!]
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!]
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.
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home