• Thomas Kuehne (40/41) Oct 31 2006 -----BEGIN PGP SIGNED MESSAGE-----
• Walter Bright (3/7) Nov 01 2006 Not really. It's callee clean stack, args pushed right to left, last arg...
• Don Clugston (4/12) Nov 01 2006 Could you please copy & paste that into the "Function Calling
• Walter Bright (3/6) Nov 01 2006 I just uploaded a new http://www.digitalmars.com/d/abi.html with more
• Alexander Panek (2/9) Nov 01 2006
• Chris Miller (3/9) Nov 01 2006 Great, thanks!
• Chris Miller (11/17) Nov 01 2006 Can you please explain some more...
• Jarrett Billingsley (52/61) Nov 01 2006 Here's all that I've researched:
• Don Clugston (17/26) Nov 01 2006 [snip]
• Thomas Kuehne (20/30) Nov 01 2006 -----BEGIN PGP SIGNED MESSAGE-----
• =?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?= (128/129) Nov 01 2006 boundary="------------000909070804020005060602"
• Frank Benoit (keinfarbton) (7/7) Nov 13 2006 Hi Thomas
• Thomas Kuehne (15/19) Nov 14 2006 -----BEGIN PGP SIGNED MESSAGE-----
• Wolfgang Draxinger (18/25) Nov 14 2006 I'm currently working on a preliminary ABI, plattform neutral ABI
• John Reimer (4/27) Nov 15 2006 Wow! I'm interseted!

Thomas Kuehne <thomas-dloop kuehne.cn> writes:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Is D's functions calling convention somewhere documented?

I've been tinkering with a reflection module for D.
Gaining access to all dynamic and static symbols is
currently possible as well as calling C functions
(see below) but calling functions with D linkage isn't
yet implemented:



























output:
 strlen('unter den Birnen') -> 16

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFFSBqALK5blCcjpWoRArGZAJ4uf0tgdH2pQdaFL6KIFtVfnu9sMACdHiVN
LLWDFZ6wUzPJo+q0PUWfPaU=
=NJ5g
-----END PGP SIGNATURE-----

Walter Bright <newshound digitalmars.com> writes:

Thomas Kuehne wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Is D's functions calling convention somewhere documented?

Not really. It's callee clean stack, args pushed right to left, last arg 
passed in EAX.

Don Clugston <dac nospam.com.au> writes:

Walter Bright wrote:
 Thomas Kuehne wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Is D's functions calling convention somewhere documented?

 
 Not really. It's callee clean stack, args pushed right to left, last arg 
 passed in EAX.

Could you please copy & paste that into the "Function Calling 
Conventions" part of the ABI page on the spec? It's better than nothing.
And maybe add 'this pointer passed in EBX' (if that's true).

Walter Bright <newshound digitalmars.com> writes:

Don Clugston wrote:
 Could you please copy & paste that into the "Function Calling 
 Conventions" part of the ABI page on the spec? It's better than nothing.
 And maybe add 'this pointer passed in EBX' (if that's true).

I just uploaded a new http://www.digitalmars.com/d/abi.html with more 
complete information on the D calling convention.

Alexander Panek <alexander.panek brainsware.org> writes:

That looks a way more complete, great!

On Wed, 2006-11-01 at 11:33 -0800, Walter Bright wrote:
 Don Clugston wrote:
 Could you please copy & paste that into the "Function Calling 
 Conventions" part of the ABI page on the spec? It's better than nothing.
 And maybe add 'this pointer passed in EBX' (if that's true).

 
 I just uploaded a new http://www.digitalmars.com/d/abi.html with more 
 complete information on the D calling convention.

"Chris Miller" <chris dprogramming.com> writes:

On Wed, 01 Nov 2006 14:33:17 -0500, Walter Bright  
<newshound digitalmars.com> wrote:

 Don Clugston wrote:
 Could you please copy & paste that into the "Function Calling  
 Conventions" part of the ABI page on the spec? It's better than nothing.
 And maybe add 'this pointer passed in EBX' (if that's true).

 I just uploaded a new http://www.digitalmars.com/d/abi.html with more  
 complete information on the D calling convention.

Great, thanks!

"Chris Miller" <chris dprogramming.com> writes:

On Wed, 01 Nov 2006 05:40:18 -0500, Walter Bright  
<newshound digitalmars.com> wrote:

 Thomas Kuehne wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
  Is D's functions calling convention somewhere documented?

 Not really. It's callee clean stack, args pushed right to left, last arg  
 passed in EAX.

Can you please explain some more...

For variadic functions, the caller probably cleans up and the last arg not  
put in EAX.

What if the last arg does not fit in EAX; e.g. a char[], is half put in  
EAX / half on the stack, or all on the stack?

Return value: EAX, or also I believe EAX and EDX for 64-bit values.

Returning floating point: in floating point register?

Bigger return types probably first push a pointer to a return buffer?

Variadic TypeInfo[] _arguments pushed last or first or something else?

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Chris Miller" <chris dprogramming.com> wrote in message 
news:op.tib3szvnpo9bzi tanu...
 Can you please explain some more...

Here's all that I've researched:

DMD FUNCTION CALLING CONVENTION:

params are passed, in general, l-to-r.

in functions with varargs, all params are passed r-to-l, and are all pushed.
varargs also push the _arguments array as the last (furthest left) param.
caller is responsible for cleaning up params to vararg function.

typesafe variadic functions just take an array as their variadic arg; the 
array is
built by the caller and passed as a regular array - because it's basically
a non-vararg function, params are passed l-to-r.

all kinds of ints, pointers, class refs, bools, char, wchar, dchar, func 
pointers:
 if not last, push; else, put in EAX

longs:
 push hi, push lo

float, ifloat:
 push

double, idouble:
 push hi, push lo

real, ireal:
 push really hi, push hi, push lo

cfloat:
 push float im, push float re

cdouble:
 push double im, push double re

creal:
 push real im, push real re

arrays:
 push pointer (hi), push length (lo)

delegates:
 push address, push context ptr ('this' or frame ptr)

structs:
 push the whole damn thing, starting at the beginning

D METHOD CALLING CONVENTION:

Similar to above, with following differences:

all kinds of ints, ptrs, refs etc:
 push

'this' goes into EAX

D DELEGATE CALLING CONVENTION:

put context in both EAX and EBX -- EBX is not actually used in the delegate 
though
put address in EDX
call EDX

 For variadic functions, the caller probably cleans up and the last arg not 
 put in EAX.

Right.

 What if the last arg does not fit in EAX; e.g. a char[], is half put in 
 EAX / half on the stack, or all on the stack?

It's pushed entirely.

 Return value: EAX, or also I believe EAX and EDX for 64-bit values.

I'm pretty sure longs are put in EDX:EAX as you say.

 Returning floating point: in floating point register?

Ooh, not sure about that one.

 Bigger return types probably first push a pointer to a return buffer?

Hmm, guess I didn't do much return type research :S

 Variadic TypeInfo[] _arguments pushed last or first or something else?

It's pushed last, so it's technically the furthest-left param (before all 
other params). 

Don Clugston <dac nospam.com.au> writes:

Jarrett Billingsley wrote:
 "Chris Miller" <chris dprogramming.com> wrote in message 
 news:op.tib3szvnpo9bzi tanu...
 Can you please explain some more...

 
 Here's all that I've researched:
 

[snip]

A great collection! How about tidying it up, and giving the whole thing 
to Walter to put into the spec?

 Returning floating point: in floating point register?

 
 Ooh, not sure about that one.

Yes, they are returned on top of the x87 floating point stack.
This applies to complex types as well:

Example:

// Calculate cos(y) + i sin(y).
creal expi(real y)
{
         asm
         {
             fld y;
             fsincos;
             fxch st(1), st(0);
         }
}

Thomas Kuehne <thomas-dloop kuehne.cn> writes:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jarrett Billingsley schrieb am 2006-11-01:
 "Chris Miller" <chris dprogramming.com> wrote in message 
 news:op.tib3szvnpo9bzi tanu...
 Can you please explain some more...

 Here's all that I've researched:

 DMD FUNCTION CALLING CONVENTION:

Thanks.

 params are passed, in general, l-to-r.

 in functions with varargs, all params are passed r-to-l

<snip>

Wouldn't it be easier and less bug prone to use r-to-l for all?

Even unidirectional __cdecl/extern(C) seems hard to implement:
"Random Testing of C Calling Conventions"; Christian Lindig; 2005
http://www.st.cs.uni-sb.de/~lindig/papers/quest/quest.pdf

 Bigger return types probably first push a pointer to a return buffer?

 
 Hmm, guess I didn't do much return type research :S

Defining that seems to be crucial.
The C++ people have serious problems with structs:

http://www.agner.org/optimize/calling_conventions.pdf

Table 7(methods for returning structure, class and union objects)
shows how everybody and his dog uses a different approach.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFFSQ12LK5blCcjpWoRAqGRAKChAYjWAjB0BDAZonuVL7CIe2wgYgCeMCOM
R6Zzykj4FlI0OaOqvfJkraE=
=Vhbq
-----END PGP SIGNATURE-----

=?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?= <thomas-dloop kuehne.cn> writes:

 boundary="------------000909070804020005060602"

This is a multi-part message in MIME format.
--------------000909070804020005060602
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

 I've been tinkering with a reflection module for D.

Attached is rudimental reflection module for D.

limitations:
* only supported on *nix systems (porting to Windows should be straight f=
orward)
* read permissions required in addition to execution permission for findi=
ng symbols
* the symbol sizes generated by DMD are defective, thus no class/struct s=
upport
* the D calling convention is undocumented, thus unsupported

license:
ZLIB

Thomas

--------------000909070804020005060602
Content-Type: application/zip;
 name="reflection.zip"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="reflection.zip"

UEsDBBQAAgAIAP11YTWHFR9UPQsAAE0gAAAMABUAcmVmbGVjdGlvbi5kVVQJAAOOpUhFjqVI
RVV4BADoA2QAtVnrcts2Fv4tPQVWM0lkh1YkO21TKU7ryE4nu71kamemM66HQ1GQxJgXLUHa
VnfTJ9t/+2L7nXNAEro4cbu7nY5MAAcfzh3nIM/2Va5nsQ6LKEt7U3VwoExRTlQ2c+aVKZfL
LC/ULMtVsdDqVC3zbJ4HSRKlcxUH6bwM5rrdVupG54Z2HPb7Xx4MBgf9gRr0h4PD4dHXtDzO
lqs8mi8K1R3vMZG6WGRJYNTf/v2vRarVy4KH316XGsNemL6ibReLyCiTzYrbINcK3zj+Jprq
qXoSmIPIPPHUbYSdZaGCdKX03TLXxihwGyXLONJTYGBrHqTFqqfU21SlmdI3Oi2wL45ZpqAE
QG7URKuFjqcqjoJJrFlkwpwGCUQ0AAryyJDYszxLeGdpNOmrcJnsEdvvdJ5EhvWBpTkdD5aL
jAAzCIsv2ru2sT5wWebLzGgPOFEaxuWUzgyzJNF5GAWxCpaQLAzIPsbDDgGOCw2hCx7nehqZ
Io8mZQGlFQCa5VrHKw/2nHyAaWkHCTDL4ji7JXyoDRvY6GZIIgx6UD7Eg9GidEtKlZSmgC4L
0hpEzTUpXpOYI7XKynodSPgvjIOIVBYUvHibZ4VmBgQeQtXqU29nTLOlH0ECLwE5wbQMCxJe
BeF1mt3GejpPyKpYJ1xLoaZZWNI8a0vdZiXsO7FQ0GOuoVEyDTRFliKBcv33MoIGe6A67KkT
UiwoTFbmoa7c3IiAEH4J0dJ4pZIgvwYZHNqU4ULs4ihJjlzXFBFPNGl/tyqw56gnIQCQCKcn
wapSeq6T7AYY5DSWRfZL8iDLa+0EFOHt/WftdjuBWuDbYdqzcdbE+qjdXubRTUAuk3DQm2La
I4R0Ptq1lOs54g3brE66cZSWd3v/aLeePVOnP5yqlwev1Hen43aryg3H6n0a3Y3aH9ttfQee
U8oFN1kE7YZB6k8gfr7q7o2cZaAxQapvfbNKJlncDRdBvq/SINEeb95XN0FcYmCi37Rf8B9P
nTPxxWoJN8IPAbVkThkwAjxL0rVIDYYnO0bYIUeaS9NLkOvgZT5RXwHAYPkjSWLIuUL21S6d
siEKKOScS+L78upKWUySMi0Tl9GhKierQgPk/Y/n787Gb9+8PTttHau+12799PqvZ+OLFkYD
jN68/3F88fanHzE8ZHUS0jiIYYL5OEspwUHhABqD+F0AnmKvzYYJkN4M0lkLJsRsDFFknWAg
TE5hc5LPOWxInEapI7HFPlJiEYxEdib/WRdlTqdFadHy8QPKOEvnLZ9+MShT4cbuby0zEOmc
Ncz4LV/+slJbuQ7ilk+/fAqyB3L6z7Wnnt2FeskBPVT1N9DZBKJllZg5mxwXmM67NKrsJWii
dRdpB/6fwgRFRe+4DCg3PLLWJhwoJ8HXNO2cvO7rTP0AX3cPJ3etY7lXZOf8wY7PXk5H9RiY
KYUdO4sDaFLML3N0BuasEBC/ZWOAI3UWUTrqRildytuu7ymrnWVQUIx7apIhJiWd+UlQhAtg
z4LYiBwWjndS0P6s52d3y67dveet7dz7M/wI4kP5iWbdtRNproWrWwfhgjU6ItTetV6Z3rRc
yjrtsvg93ia6t4uUZXoC2tikRYEgPx81Dn/wOX/5Lw4S7Uk4K8oO3a2cgkokvfHqDAFDBvnc
8AG5s0+orLMyxbppHnKGOPysTMPd5xmUfpCQiEXAEJltOwv2xkMR3+Fv3BXYijPIfs9mSY7b
CDK/DTPVs6CMC7uhWOTZrXPZ1Kml2ylTKlwETCq86syOhWossq20cfd+7fDnlknGcXStG36F
yLOebY1T3fI7zuPdnzvTBk9kRDvMQlUd0NUvZrLo8FXJYpxkUGEeH6vnlR+jlPPPTn7xR87w
tBrSzaD884u+HQvMfp2lmhlw5k6gENVBWi6bOVsKyPJlLUgv1um8WKinanAlxFh6EC0TV3Ea
pVN916h7VGtGfdMoDXdPg4VQRoSSznQdtDjvkpGo7qhIe42wxFtDAD8urGL3Gmq5sutoF9BN
EWh7f6RQJWiqXqmizSvhH0bM1M/2+Y9CoZClTwpK+OlcD+1k6+z1L546O3+Ln1P6ef2uWjk9
pwXcZ+d25pmcbhJRRYqy0K/4EDwqaea6qAVl68gK0pyCC3nK1dR0au/M5yOH6hRUl6C1tiZQ
3OgO6jcyHyZLIe5bwg+osjOfAmS0xg6pe4OL2hWZCYw2eBhv8xAudHi9LpraYKSC+DChqEVL
6yfwvQai3owmYhLN55r6eLRNR4eTqDAbLAKxYhEm5an+3Zs3vv3/hV1EEymLzx2BmH/M2tCq
WRluMDyoGI7VmjlHG7xcAvCK3ev1+++GCvO/3XGLPDg4oiK5iRlrm2VpFg0DwuR4g0kb/s0k
U63pEXxu6tFauJKEimZKgY6Spx+o00NeC68bcatYd2TW6N58ZsLV3Pk7bz0xVUSNi5sC3FCT
jqvFsRqnSEftdvKUJ2tjzkyxdNNla4Yu2Bl/lLC12V4OqRItffdscY6Ad3JytUa5eecCZ+lj
96BqhbqCKlOV2L+3ntwdopcvj+GqOxb+ubHdOX1TiqZ8qm4eFOs6L7p9T+EWpocinUhDbvsS
jjT3Fq4RPgdgVqbQiWy99+62pcP/6AJHC1bf37a0rit8FwKxg4qw23lk1CXXZcNHLwxLOnz0
3HA1P3xkrjreWt/iuQ2Hp5rmgRuNugGynfUMt5DtqkU6+HdOTFQXohlV7W9VTHerzgOWZmr1
+LHq0pd6qaq1p0o6EVvIWolMreVqJi1j2zKKIghGG3NRMb3OlPMc4DDOq0Cm8qRisu6OjuvN
DRe9jT7PcZct1T/t3z36BSpe3+QxqjpYu7vtmXtbQlZogOq/IDDLcSN2bSS3MSSmUWOawjZg
oLuB5Jcd560BYB15aKCv6pGhQ1eSPfzmsrjio7aL9iLbmqs6Z2426DFBKvZqKAV7Z0yHhVMd
xvThN1/2c+iockd1P6qBJLBoq33cYBT3ux58GlOACLgq59trxfxaGW/fyBH926W8etL5naVX
v3eedOpwqWriU/RipIi1B7dplFEZ2byQOd2sOK9Pd49dt5X2DiK6TLZnpw52tZcz6pIHvimT
rtyvnszj/jIL5o5NFqunCIJR9cUxaPUY2yzEbXfkB4kPN+VNt3lU6FkMdS10HGdIMSvRSmSG
6pGxPuxG6mO7n1OMs//XQh6FRa6xuglyea7HJKlfT+8DFMV9Gu/0j+JNP41ni/0/CLok0Pqx
jKbuOwPV4R/D3mB3z7UYNlN4+LjR7FOr2bQevVPbJYXIiFJ6Ol+x32IXbiU97Ajv9yR8TqbN
UxSl3e5mLuwcgeIIeJ099Qo9hu2DXPlZQLPWJt8jFKnED/zQp3uTI1YSj+QlnkQSRL7I0dV0
1vUc6+KJKJUf6MeqwhAF84h5kDS7LzcJQ0Zp88zbaq6S1q573raV9ZLtOOXpTxRFLJ5r+ScT
BCiarRVncXQoBU9O9DxKU1CyCK0a+7J/VT/hicql196moo4FVI+rB//2ZkVIEL3d7zW9sVOR
iFXWrdX9FXffr7DnwSvRnajJ2/ksKWN+2XOrz731q9U9wGR5vvJIESiSjdaJoX/gmlC1reTk
xlyth7iLzYWf9pl3J+fjk+/98/c/fNpvBOzzziPVyP0exKOHu9GRuBHn8gn16nfPn9/rHJPP
+sWEl+RGYLSTk9ev/S+++PJL/6uvXrzwv/663/9+Y/ugxo934w8afGmg7U3DBwwG/uHhxobD
xp13Ix46nnyPE7Me7/PkqmX7tDtTFUe9cfXLjm1LO+vZE49vzsaLSXX/Zx/mf4BB+R5Zj63v
YDp2Z3qX2mkrRTrTW6HAWrU3ft8WNP8BUEsDBBQAAgAIAEFwYTW0MiE+uwcAAKMSAAAFABUA
ZWxmLmNVVAkAA8qaSEXKmkhFVXgEAOgDZACVV21T20gS/mz/il62DDLYBgOV7GKgjoDJsuEg
FZu7SkHKJUsjPEEvPs0IcHb5Z/ft/tg9PSPJErDJXSqJPT3dz3Q/3dM93lwnEQY9j7pd/kIq
m8+TVFOQpOTFvbtMzGLRS0UQCk/LJO751GwS3YtUYUXbW1tvuv1+d6tP/a29/vbezq+8fZzM
F6m8nWlyjttGicazJHIVffjPvwFI+9os/5bje/Ehm41nUpFKAv3gpoLwfZ4m99IXPq25qivV
WoceJCwzTW68IPE4T4VSBFdlNA+l8IEB09SN9aJHdBZTnJC4F7GGXRiSnglyMwCkiqaCZiL0
KZTuNBQmXsb03ci9FQpAbiqVjG8pSJPIWGZKUBLga8XJHrv9UaSRVIYPbN3y8XBZJwyYIFh8
Y9uaYXngPEvniRId4MjYCzOfz/SSKBKpJ92Q3Dki81zmXnVgYYFDLRC0NutU+FLpVE4zDdI0
gIJUiHDRQTKnX5E2tuAAgiQMkwfGB20wMAlVexxCvwfyER6SJuMXUVKUKQ0uNbOGUFPBxAsO
c0CLJCv3gYQ/XuhKpszVZvMhTbQwDlh4BFXSR2eB0XnBj0WCLy4XgZ95moMn17uLk4dQ+LcR
ZxX7jJtrkJ94GcsNW/SQZMjvNIcCj6kAo5waMMWZ4oBS8a9MgsEetLZ7dMTEQkMlWeqJosyV
DRDBzxFaHC4octM7qKGgVebNbF4qJNkj60yx8lQw+69TAZudnr0CAJE4PXIXBempiJJ7YHDR
5C6auuQKyn0ti4BvaXN9s9n82RYUbpvSvkx6s8O6KJTT57IU/tVl3B1qglDGd3VJFuNo/xnU
Qm3qxVyoujjwYh2yqHmfSJ9i8TBRi2iahI4HmjV5Mzddp9iNRIdYY53u3TDDQslvYqLNR4cy
GetfsOID2gME6otA4qKNDNQY0snVxejj8Pjs9Gx40th6TeHy3e/D43Gj/9re6dXF8fjs8qKx
zSQGUKCT4bur96Xu+eV7FB28CEpRJZTc/aXjHesp3TQbf+R2zsp1a36j1V7rW3aj9V5rNsu+
3OiWuolXOuQY4za+sDl/GgB8Mna7PaAnepjJUDhbiP9nESrRbBhG4ZljSUSDiVzcml6v1/6j
2XiCWuzLoMLW0T+Gk0/DoxNnmgWBSDtoO1ms2yQDJxWu7ziBz0faXf5m99u0D79sQtqlLBU6
S+NBHX00HH5wkiBQwsLCT3FX4ObyDrEWVMdtOjigbn+Jpfgme6YQSHluPEExOrYssJXqokYQ
WAe9AFPL51CHYfBPZzjz0zZavOuLdJDLRkam7CQrhYsIskWEOmowhqQD2sJmXnFf86Ul1d6Q
iTYz44Aurs7P2Y5ZXyk9bM2pS61526QydxQucqU2NteJuTWz1jpHuKqNZS5WrdQWThI4y2CQ
9mZjiZCHYcxBrTXriYmagVhmcou5aBRcogBgjKJwOMCKdpxFcLc/QOCHYB+f3a6xXGbwGfYG
VNerEOhvpk4HhZWNJPewHsqoCAW6hrbrlvxCLWnIkp0irJ6aTfLr3eDwnok5vtFv48lo/Gl8
9M64uyTG5Ihsjpid6kHorrA5u3hvzzPwlUgrx+TlaRSepd3esDYaNAaqVzUqaajwUDWuxVcq
P/EFpu9E+fnvL6NcREB8NT6jXY2vjpwHZtBMQdgSR6XvP/eONuu5w1VB7/m6sZFbf485lMlX
lMkLe+tSvVAWUeevFeH9T9DoKT3h7kd//knF2rbJ3JcGRoiWcSZyuyf7AcIOD+nD+dXJ+yHt
UeJzhUxkHCQ5eUivRTOyVXDxeDoobff3f2CLF6k3cyoQS39cZHU0Hk8uLsefPw73cnHtuIO/
GFqDQnmKbN8NniPa6fVjRKv3AzAedz+GKobi62Do+m4W6hLmf8qF6/vmAV9wyXVaSayZM3bM
mC5aEltT2jioa704sZrByol2vzK2a5d8gyolxwOZB027enCn0LATvloA1gXjgfmv7MG8fGpi
FGcxPyrKK1AT8HXK30dmpEzxTkwXDkdvhxBeYGI5oIqg8yUGDRanZ+fDdfSn+SAfavkEIx3N
y2FmB/vS1K4noYiR+d2tX9/g+m7Xx1vhC7qLaeHW5GVLXEIZNTgCnSCZi9hZ2cRz3dtUmICb
kCu0qZWU0Tj9RtHO1Veml33yOBw/w90Krcq3y/LEDseNF8lPFRwTAdvtUf7E4oUdLoBSHFxg
gOFN69tjF/8o7T621j1qrT/in4e/e/YDq6zlrXQ4tav5fF81b5BV0FtMLMxZeLDT5n7lQM6r
NVqzaz7p+u3OFyPcXGvb0q5eGhOwoUREXjR3igq0x63c9N++HZ6fIpDdF8b5kxXbx+dHo9HO
dm3E2Dab3xgme9fas8t5Fu1tux6eTQyA8XKJll/D2g0vX5fPzn6z+/2zf/m/zn6z+92z85Ne
oRL/MeNoFW93BvniGvcd1WJS0e72v+TvPFMPplBtNVxOPp1cXpx/Nmk1ZWQ2W6pN3cPi3WJV
ZZF6mT9kX/ekfCfWU5qv7FvWIHlhooRjvrNhYNdc3JDwb/ziaT5AS6n/UOE7H+GnqukaxS+O
j2cnjUbuMe7OXPqOGbLFfuFYA79MWGe1ELxQsm2grmdlVVV2oEGlFi95u9ZIsIYrnHrHdAp7
4TkTZVr/C1BLAwQUAAIACAAkdmE1MEw9sEMBAABpAgAACgAVAHJlYWRtZS50eHRVVAkAA9Ol
SEXTpUhFVXgEAOgDZACVUrtOAzEQ7P0VqxQRIJJI0EVKdyUoFEiUyLH3kpVs7+G1j4SvxzZ5
UVBw3ZxnxjMjv0QeEbgHw8HgkCBi79Ak4gDkB4ceQ9IN9hyhU6t/fko58vRjIUt1BxzcASQP
A8eEtkC4C7QHOUhCL4UQUVsYMHoSqaLy4yNTLFwKoK2lliYx4B5NbuDCbil7CpbCtnj6Dbvq
mXZ4RCD0hQJbDBh1DbA5QPfcgY4IFvtafcT7IsgCgcE4LbKQFLNJp9RHvw6Mdq7eU7Yby0xt
M4EcLJtcd0N7NMrhXFip13W3rkOc54XJyGRBjA7vGwo6Hm5uJ63IWynCn/KbLMnWiyeggy1I
l8wN/ilIO5IL5YlC3jftiayy6G1t73mptsbAzD8+wMwAun5uYDoF6+3Vw5jbdsIwGzHW0Vdd
kcKM+6vHU1TzxQWrb1BLAQIXAxQAAgAIAP11YTWHFR9UPQsAAE0gAAAMAA0AAAAAAAEAAACw
gQAAAAByZWZsZWN0aW9uLmRVVAUAA46lSEVVeAAAUEsBAhcDFAACAAgAQXBhNbQyIT67BwAA
oxIAAAUADQAAAAAAAQAAAKCBfAsAAGVsZi5jVVQFAAPKmkhFVXgAAFBLAQIXAxQAAgAIACR2
YTUwTD2wQwEAAGkCAAAKAA0AAAAAAAEAAACwgW8TAAByZWFkbWUudHh0VVQFAAPTpUhFVXgA
AFBLBQYAAAAAAwADAMwAAADvFAAAAAA=
--------------000909070804020005060602--

"Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:

Hi Thomas

Great, that you are on the way to bring reflection to work.

In the demo you call a c-function and a pascal-function. Is D equal to
pascal calling conventions?

Can I use this to call D functions?
Is there a way, to call an object method?

Frank

Thomas Kuehne <thomas-dloop kuehne.cn> writes:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Benoit (keinfarbton) schrieb am 2006-11-14:
 In the demo you call a c-function and a pascal-function. Is D equal to
 pascal calling conventions?

No.

 Can I use this to call D functions?
 Is there a way, to call an object method?

Not yet. I'm currently rewriting to support C, D and C++.
(I forgot how limited C++'s templates and variadic arguments are ...)

Adding support for D's calling convention is going to be the
next step. Though keep in mind that there are 3 different D calling
conventions: GDC, DMD-Linux and DMD-Windows.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFFWXy1LK5blCcjpWoRApvgAJ9l+n2rLueVeSogO656l58NYTWpKACfakXE
jl56lV8/Kaj/EjHataZvu4I=
=icmZ
-----END PGP SIGNATURE-----

Wolfgang Draxinger <wdraxinger darkstargames.de> writes:

Thomas Kuehne wrote:

 Is D's functions calling convention somewhere documented?
 
 I've been tinkering with a reflection module for D.
 Gaining access to all dynamic and static symbols is
 currently possible as well as calling C functions
 (see below) but calling functions with D linkage isn't
 yet implemented:

I'm currently working on a preliminary ABI, plattform neutral ABI
for D. Plattform neutral in the sense, that everything that is
plattform related is expressed by reference to additional
plattform specific structured. This ABI also differentiates
between compile time, linkage time and runtime level, which is
IMHO required to get reflection and introspection done in a
elegant way. Along with that I'm also working on a fork of the
GDC compiler and a custom set ot GNU binutils that follow that
ABI. The ABI itself is binary format neutral, though I'm also
working on a special version of the ELF format optimized for
that ABI, which uses DWARF to store reflection and introspection
information, instead of placing that in a additional .data
section.

I hope to have a relase candidate in late December.

Wolfgang Draxinger
-- 
E-Mail address works, Jabber: hexarith jabber.org, ICQ: 134682867

"John Reimer" <terminal.node gmail.com> writes:

On Tue, 14 Nov 2006 05:27:57 -0800, Wolfgang Draxinger  
<wdraxinger darkstargames.de> wrote:

 Thomas Kuehne wrote:

 Is D's functions calling convention somewhere documented?

 I've been tinkering with a reflection module for D.
 Gaining access to all dynamic and static symbols is
 currently possible as well as calling C functions
 (see below) but calling functions with D linkage isn't
 yet implemented:

 I'm currently working on a preliminary ABI, plattform neutral ABI
 for D. Plattform neutral in the sense, that everything that is
 plattform related is expressed by reference to additional
 plattform specific structured. This ABI also differentiates
 between compile time, linkage time and runtime level, which is
 IMHO required to get reflection and introspection done in a
 elegant way. Along with that I'm also working on a fork of the
 GDC compiler and a custom set ot GNU binutils that follow that
 ABI. The ABI itself is binary format neutral, though I'm also
 working on a special version of the ELF format optimized for
 that ABI, which uses DWARF to store reflection and introspection
 information, instead of placing that in a additional .data
 section.

 I hope to have a relase candidate in late December.

 Wolfgang Draxinger



Wow!  I'm interseted!

-JJR