www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 673] New: ABI as documented is 32 bit specific.. how about 64 bits?

reply d-bugmail puremagic.com writes:
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.


--
Dec 10 2006
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=673






But D 1.0 will only be released for 32-bit X86 anyway, right ?


--
Dec 10 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=673






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.'


--
Dec 10 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=673






"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 ?


--
Dec 10 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=673


smjg iname.com changed:

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







 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


--
Dec 11 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=673






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.


--
Dec 11 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=673








 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.


--
Dec 12 2006
prev sibling next sibling parent reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=673







 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...


--
Dec 12 2006
parent Don Clugston <dac nospam.com.au> writes:
d-bugmail puremagic.com wrote:

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


 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.
Dec 13 2006
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=673


bugzilla digitalmars.com changed:

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





Fixed DMD 0.178


--
Dec 27 2006