[Mono-list] Re: PInvoke:TNG

[Robert Deviasse]

>If I'm understanding this correctly, your proposal is to say
>"don't use this type here, use the other one over there",
>where "the other one over there" is in a system-specific
>namespace and/or assembly.  The VM would substitute
>the type behind the scenes when the assembly is loaded.
>
>This way, there would be one main "corlib.dll" that had
>the primary definitions in it, and then each system would
>have its own "native.dll" that re-defined the types to
>what the local system required.
>
>This "native.dll" could be generated automatically using
>some autoconf magic when the VM is built for a given
>system, and would probably be quite small.  Also, the
>VM itself doesn't need to know about "int_t", "off_t",
>"stat_t", etc, because all the knowledge is encoded into
>"native.dll", which is much easier to update.
>
>Am I understanding this correctly?

Almost. I was a bit too long winded so a few ideas got lost
in your summary. I think I have a more concise and precise
explanation.

We need to think at two levels, the C# and the IL level.
At the C# level, we don't have to choose a specific
implementation, but at the IL level, a specific
representation must be chosen and when PInvoke functions
use these implementations. Conversions are needed to convert
between the chosen implementation and the platform specific
implementation.

What I was proposing was a way to:
* optimize the representation for a given platform, but
  still provide enough conversions so any other platform
  with "close enough" representations could use it
* get rid of the complexity from the core VM or compiler
  and instead replace it by a platform specific native.dll
  which would provide all the conversions between the
  representation used in any DLL you use.

In your example, corelib.cs (not corelib.dll) contains the
logical types that's used by the application. The native.cs
(any any user define types in NativePosix.cs) would contain
the physical type that's actually used by the compiler when
compiling corelib.cs. When corelib.cs is compiled, it's
types would match those in native.dll. If the type isn't
present in NativePosix.cs, the logical type will be used
to generate a physical type, using the rules of the "default
compiler on the OS".

As you've stated, native.dll would be specific to a platform
and would not be deployed with applications.

When corelib.dll is deployed on a platform where the corelib.dll
type matches the native.dll type, no conversion is necessary
and PInvoke functions are called without any conversion overhead.
When they don't match, reflection would need to be used on the
corelib.dll and native.dll types to convert the corelib.dll type
into the native platform specific type. There's a speed penalty
(I don't see a way of avoiding this with any approach we take),
but it's still usable and it's still portable. There's probably
some way to optimize this so reflection is used only when the
DLL to generate actual conversions that will be used by the
application when it runs the first time, but I'll level that
optimization to the compiler experts.

Essentially, the situation is analogous to Pentium optimization.
If you optimize your application for the Pentium (but don't use
any Pentium specific calls) your application will run faster on
a Pentium, but it may run slower on a 386 or SledgeHammer. If
you optimize for a 386, the other two will probably suffer. In
of these cases, all platforms should still be able to run your
code.

Is this a bit clearer?

>Cheers,
>
>Rhys.
>

Take care,
	Robert


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp