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

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

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

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

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.