http://ftp.digitalmars.com/dmd1beta.zip

Mainly for those daring folks who want to help develop it further:

        $(LI 80 bit reals are truncated to 64 bits when formatting.)
        $(LI Many math functions are not implemented.)
        $(LI No symbolic debug info is generated.)
        $(LI Cannot catch Win64 structured exception handling exceptions.)
        $(LI VS debugger cannot look at call stack.)
        $(LI No DLL support.)
        $(LI Only tested with VS 2010.)
        $(LI No installer.)

My plan going forward is to now switch to bringing D2 up to this state.

Help, of course, is appreciated in addressing the shortcomings above. The math problems are due to reliance on the C standard library, and VC is both missing many C99 functions, and of course has no 80 bit support.

We'll have to roll our own.

The call stack problem is because the VC 64 bit ABI does not use a standard stack layout, so it cannot walk the stack. dmd uses the stack layout used on every other D port, which VC doesn't recognize. Eventually, this will have to get fixed. Frankly, not being able to look at the call stack in the debugger is quite a nuisance.

DLL support is probably straightforward.

I haven't looked at the symbolic debug info format.

I've been folding the changes into the D2 compiler as I've gone along, so that will hopefully mostly work out of the box. I have only done some of the library work for D2. Essentially I gotta go through the commit history on Phobos1 and fold it all into Druntime/Phobos2.

D will probably not bother with the 64 bit SEH.

Walter Bright:

> http://ftp.digitalmars.com/dmd1beta.zip

How do I switch from producing a 32 bit to 64 binary? I am looking for a -b64 or -b32 or similar switch...

Bye,
bearophile

On 9/27/12, Walter Bright <newshound2@digitalmars.com> wrote:
> D will probably not bother with the 64 bit SEH.

How come, and what will be the consequences of this?

Anyway great work so far!

On 2012-09-27 15:42, Andrej Mitrovic wrote:
> On 9/27/12, Walter Bright <newshound2@digitalmars.com> wrote:
>> D will probably not bother with the 64 bit SEH.
>
> How come, and what will be the consequences of this?
>
> Anyway great work so far!

What he said. What about this:

http://msdn.microsoft.com/en-us/library/1eyas8tf.aspx

Not SEH?

-- 
/Jacob Carlborg

On Thursday, 27 September 2012 at 15:00:23 UTC, Jacob Carlborg wrote:
> On 2012-09-27 15:42, Andrej Mitrovic wrote:
>> On 9/27/12, Walter Bright <newshound2@digitalmars.com> wrote:
>>> D will probably not bother with the 64 bit SEH.
>>
>> How come, and what will be the consequences of this?
>>
>> Anyway great work so far!
>
> What he said. What about this:
>
> http://msdn.microsoft.com/en-us/library/1eyas8tf.aspx
>
> Not SEH?

This _is_ the 64 bit SEH implementation (although it is table-based instead of relying on setup in the function prologues, like on 32 bit Windows).

Walter seems to imply that he will roll/port his own EH mechanism?

David

On 09/27/2012 01:56 PM, bearophile wrote:
> Walter Bright:
>
>> http://ftp.digitalmars.com/dmd1beta.zip
>
> How do I switch from producing a 32 bit to 64 binary? I am looking for a
> -b64 or -b32 or similar switch...
>
> Bye,
> bearophile

-m32 and -m64 ? i'ts what dmd uses on linux.

-- 
Mike Wey

On 9/27/2012 8:27 AM, David Nadlinger wrote:
> Walter seems to imply that he will roll/port his own EH mechanism?

Well, I did. The EH mechanism in dmd Win64 is the same as that used for dmd Linux, OSX and FreeBSD, 32 and 64.

Mike Wey:

> -m32 and -m64 ? i'ts what dmd uses on linux.

Are those usable on DMD-Windows64 too?

Bye,
bearophile

On 9/27/2012 4:56 AM, bearophile wrote:
> How do I switch from producing a 32 bit to 64 binary?

-m64

On 2012-09-27 21:51, Walter Bright wrote:

> Well, I did. The EH mechanism in dmd Win64 is the same as that used for
> dmd Linux, OSX and FreeBSD, 32 and 64.

What does that practically mean from the users point of view?

-- 
/Jacob Carlborg