I've reached the point in D.NET where I'm playing around with calling native D code from .NET.  I'm running into an interesting dilema, as I cannot figure out what D is expecting.  This is best demonstrated by a couple examples:

If I have a function in a native D DLL:
extern (D) void foo(int i) { printf("%i in foo", i); }

and I push a 32-bit integer onto the stack prior to the call to that function, it invariably is either printed as some address or as 0. However, if I do the same thing with a function that takes a float and I pass it a 4-byte floating point number, then it Just Works.

What does work, with ints, however, is if I do:
extern (D) void foo(int i, int j) { printf("%i in foo", i); }

and then pass two 32-bit integers.  Except that i works and j is that same address regardless of how many integers I push onto the stack.

Strings are a similar problem.  If foo takes a char[] and I pass it a 32-bit integer representing the length of the string and then I pass a valid pointer to the string, the D end sees the char[] as being empty.

I have none of these problems if I use extern (C) so it has to be something with the way that D expects its arguments, and I, for one, am dumbfounded.

Does anyone have any insight into this problem?

-Deja

In article <cf095i$inp$1@digitaldaemon.com>, Deja Augustine says...
>
>If I have a function in a native D DLL:
>extern (D) void foo(int i) { printf("%i in foo", i); }
>
>and I push a 32-bit integer onto the stack prior to the call to that function, it invariably is either printed as some address or as 0. However, if I do the same thing with a function that takes a float and I pass it a 4-byte floating point number, then it Just Works.

I really have no idea, but maybe DMD passes single ints as registers rather than on the stack? Have you tried playing around with disassembled D code?

Nick

For D functions, the last argument will be passed in EAX if it fits in EAX.

Walter wrote:

> For D functions, the last argument will be passed in EAX if it fits in EAX.
> 
> 

Well, that prevents .NET from directly interacting with D.  People will have to rely on extern (C) wrappers (which are already supported) since there's no way to work directly with registers using .NET

Maybe by D.NET 2.0 it'll be able to automatically generate the machine code wrapper, but for now there are too many things more important.

But that at least solves the mystery.  Thanks!

Deja

In article <cf0qdu$th6$1@digitaldaemon.com>, Deja Augustine says...
>
>Walter wrote:
>
>> For D functions, the last argument will be passed in EAX if it fits in EAX.
>
>Well, that prevents .NET from directly interacting with D.  People will have to rely on extern (C) wrappers (which are already supported) since there's no way to work directly with registers using .NET

Are you sure?  How does C++/CLI do the marshalling between managed and unmanaged code?

Sean

"Deja Augustine" <deja@scratch-ware.net> wrote in message news:cf0qdu$th6$1@digitaldaemon.com...
> Walter wrote:
>
> > For D functions, the last argument will be passed in EAX if it fits in
EAX.
> >
> >
>
> Well, that prevents .NET from directly interacting with D.  People will
> have to rely on extern (C) wrappers (which are already supported) since
> there's no way to work directly with registers using .NET
>
> Maybe by D.NET 2.0 it'll be able to automatically generate the machine code wrapper, but for now there are too many things more important.
>
> But that at least solves the mystery.  Thanks!

No problem, just use the extern (C) calling convention in your D code that you want to interface with .NET. No need for wrappers.

Sean Kelly wrote:
> In article <cf0qdu$th6$1@digitaldaemon.com>, Deja Augustine says...
> 
>>Walter wrote:
>>
>>
>>>For D functions, the last argument will be passed in EAX if it fits in EAX.
>>
>>Well, that prevents .NET from directly interacting with D.  People will have to rely on extern (C) wrappers (which are already supported) since there's no way to work directly with registers using .NET
> 
> 
> Are you sure?  How does C++/CLI do the marshalling between managed and unmanaged
> code?

The Managed C++ compiler cheats. :)

It has both a native and a managed code generator, so it can flip between one and the other at will, depending on the function it's compiling.

Making a D compiler that can do the same is certainly possible (we already have an x86 code generator in the form of DLI, after all) but a project in and of itself.

 -- andy

On Fri, 6 Aug 2004 12:24:19 -0700, Walter wrote:

> For D functions, the last argument will be passed in EAX if it fits in EAX.

I guess this only applies to the DMD compiler and 'D' - the language. Another D compiler might do it differently.

-- 
Derek
Melbourne, Australia

Derek wrote:
> On Fri, 6 Aug 2004 12:24:19 -0700, Walter wrote:
> 
> 
>>For D functions, the last argument will be passed in EAX if it fits in EAX.
> 
> 
> I guess this only applies to the DMD compiler and 'D' - the language.
> Another D compiler might do it differently.

I think that something like that should be compatible from compiler to compiler as much as possible (unless it's platform-dependent). I'm hoping that information will become part of the D standard, e.g. http://www.digitalmars.com/d/abi.html

At the minimum, it should be documented.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

J C Calvarese schrieb:

> I think that something like that should be compatible from compiler to compiler as much as possible (unless it's platform-dependent). I'm hoping that information will become part of the D standard, e.g. http://www.digitalmars.com/d/abi.html

It is platform-dependent. :)

> At the minimum, it should be documented.

I guess the docs say something about leaving the calling conventions, memory layouts, etc. unspecified, so that these can be tuned to performance in future.

Instead, all communication with other language runtimes should happen via extern(...) interfaces. However, one could think of disigning another extern interface to standardize a link-compatible interface to D features, where performance is not essential.

-eye