http://d.puremagic.com/issues/show_bug.cgi?id=673

           Summary: ABI as documented is 32 bit specific.. how about 64
                    bits?
           Product: D
           Version: unspecified
          Platform: PC
               URL: http://www.digitalmars.com/d/abi.html
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: www.digitalmars.com
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: braddr@puremagic.com


Borrowing from http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/ABI
========
Should 32-bit-pointer assumptions be hardcoded into the ABI like this (offset
numbers in Classes) given that the world is starting to shift to 64-bit?

Arrays in D are already 8 bytes on 32-bit and 16 bytes on 64-bit, I'm assuming
the same would go for the vtables ? \ The documentation here is out of date, or
at least not updated to 64 bits yet (probably two ABIs, right ?)
--AndersFBjörklund
========

The documented ABI is pretty clearly 32 bit specific.  Under both linux and windows, the ABI between 32 and 64 bits are likely to differ in significant ways, though the other parts are in the TBD blocks.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=673





------- Comment #1 from afb@algonet.se  2006-12-10 03:59 -------
But D 1.0 will only be released for 32-bit X86 anyway, right ?


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=673





------- Comment #2 from braddr@puremagic.com  2006-12-10 04:07 -------
That's a potentially valid path (though not the one I'd prefer to see taken). If it is, the ABI page probably ought to call itself out clearly as specifying just linux/x86/32 and win/x86/32.  It would be nice if it incorporated more details since gdc is starting to implement other platforms and other word sizes.  The spec is larger than dmd's implementation in a few dimensions like this.

This is one of the pages where it's clear that 'D, the spec' != 'DMD, the implementation.'


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=673





------- Comment #3 from afb@algonet.se  2006-12-10 04:11 -------
"starting to" ? We've been trying to get other processors and 64-bit patches into D/DMD/Phobos for years I think. :-)

I don't think there is much difference between D and DMD
at the moment, as they are both released simultaneously ?


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=673


smjg@iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg@iname.com




------- Comment #4 from smjg@iname.com  2006-12-11 21:18 -------
(In reply to comment #0)
> Arrays in D are already 8 bytes on 32-bit and 16 bytes on 64-bit, I'm assuming the same would go for the vtables ? \ The documentation here is out of date, or at least not updated to 64 bits yet (probably two ABIs, right ?)

Why have two ABIs?  Just have one ABI written in bits-neutral terms.  For example:

    offset    contents
    0         array dimension
    p         pointer to array data

where p is the platform's pointer size.

Or more concisely:

    offset            contents
    0                 array dimension
    (void*).sizeof    pointer to array data


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=673





------- Comment #5 from braddr@puremagic.com  2006-12-11 21:27 -------
Because vtable layout is but just a tiny portion of the ABI.  One major area that will end up being different is exception handling.  The EH mechanisms differ by OS, by cpu, and by wordsize.  For example, the win32 eh mechanism is _signifigantly_ different from the win64 mechanism.  For some details, see this talk:  http://www.nwcpp.org/Meetings/2006/10.html

Those parts of the document are still blank, obviously, but at some point they will be I hope/expect.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=673





------- Comment #6 from smjg@iname.com  2006-12-12 12:54 -------
(In reply to comment #5)
> Because vtable layout is but just a tiny portion of the ABI.

What's that to do with anything?  It goes without saying that the layout in memory of _anything_ that relies on pointers must be defined in terms of the platform's pointer size.

> One major area
> that will end up being different is exception handling.  The EH mechanisms
> differ by OS, by cpu, and by wordsize.  For example, the win32 eh mechanism is
> _signifigantly_ different from the win64 mechanism.  For some details, see this
> talk:  http://www.nwcpp.org/Meetings/2006/10.html
> 
> Those parts of the document are still blank, obviously, but at some point they will be I hope/expect.

Exactly.  So it'll just as well be different on different 32-bit platforms and on different 64-bit platforms.  So by your reasoning, surely we should have a whole separate ABI for each possible (OS, cpu, wordsize) combination.

Having loads of separate ABIs would make them a nightmare to maintain.  Just have one basic ABI, with variations only where really necessary.  In the case of EH, state that it's compatible with the platform's own exception handling mechanism, and then describe it more specifically for each platform as necessary.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=673





------- Comment #7 from fvbommel@wxs.nl  2006-12-12 13:06 -------
> Having loads of separate ABIs would make them a nightmare to maintain.  Just have one basic ABI, with variations only where really necessary.  In the case of EH, state that it's compatible with the platform's own exception handling mechanism, and then describe it more specifically for each platform as necessary.

One tiny problem: it's not 'compatible' with the platform's own exception handling on Linux, for so far as there is one. Dmd-linux uses its own custom exception handling, incompatible with the one used by GCC and compatibles. I seem to recall Walter stating this was because he couldn't figure out how that ABI worked so he rolled his own...


-- 

d-bugmail@puremagic.com wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=673
> 
> 
> 
> 
> 
> ------- Comment #7 from fvbommel@wxs.nl  2006-12-12 13:06 -------
>> Having loads of separate ABIs would make them a nightmare to maintain.  Just
>> have one basic ABI, with variations only where really necessary.  In the case
>> of EH, state that it's compatible with the platform's own exception handling
>> mechanism, and then describe it more specifically for each platform as
>> necessary.
> 
> One tiny problem: it's not 'compatible' with the platform's own exception
> handling on Linux, for so far as there is one. Dmd-linux uses its own custom
> exception handling, incompatible with the one used by GCC and compatibles.
> I seem to recall Walter stating this was because he couldn't figure out how
> that ABI worked so he rolled his own...

By my reading of the Win64 ABI, I'm not confident that D will able to use standard Win64 exception handling, either. The ABI seems to ignore the possibility of nested functions. I could be wrong about this, though, I didn't read it very carefully.

http://d.puremagic.com/issues/show_bug.cgi?id=673


bugzilla@digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #9 from bugzilla@digitalmars.com  2006-12-27 02:03 -------
Fixed DMD 0.178


--