[Visionaries] Re: dotnet platform support / gnu config.sub (long)

[Guido Draheim]

Ben Elliston wrote:
> Hi.
>
> Cc's pruned a bit.
>
>
> > BJE, what do you get from the discussion?
>
>
> Sorry, I'm a little new to .net, having only read about it in a
> cursory manner in publications.  I am applying my understanding of
> Java, so if I am missing the point at all, please let me know.
>
> My understanding was that various compilers generate the .net IL and
> that it is executed in a virtual machine environment like Java.  So
> the question I have is: why do you need the target to encompass the
> language used at the front-end?  The tool, say, a GNU C compiler,
> would be built to target the .net VM and its corresponding machine
> specification and that would be that, right?  The triplets are used to
> identify hosts and specify targets.  I don't see how languages enter
> into it.

[why do you need the target to encompass the language used at the front-end?]
I do not want to - what looks like the language in the triplet (eg java)
is in fact the vm-machine that executes compiled code. For dotnet, the
vm-machine is commonly invoked by `ilrun <dotnet-application>`. There is
no language named either `dotnet` or `ilrun`.

[The tool, say, a GNU C compiler, would be built to target the .net VM and
its corresponding machine specification and that would be that, right?]
yes, and just like in general concepts we have a little difference
between the cpu (the vm machine in its direct sense) and the hosting
service / libraries - here it is called platform and its variants.

[The triplets are used to identify hosts and specify targets.  I don't see
 how languages enter into it.]
It doesnt, see above. Note that dotnet is a lot different than other vm-type
machines in that there is no 1:1 relation between input language and output
vm machine. A javac compiles .java to .jar, we see .py compiled to .pyc,
but basic/csharp/cplusplus language to ilrun'able cil'segment .exe container.

Note that there would be no need to add traditional vm type platforms
for their 1:1 relation - dotnet compilers however can use input languages
that would otherwise be compiled directly to a native cpu segment, even
some c/c++ variant that is common in opensource developments. The dotnet
target is yet another target platform, ifdef'd for its set of services.
The mono gtk bindings might be a little different that inti gtk bindings.

I took the task to incorporate traditional vm type languages in order to
create a common scheme that would hold even when we add other target
platforms of the variability of contemporary dotnet compiler suites. That
is far from hypothetics, the dotgnu compiler can use its variety of input
languages and output the same ilrun exe container but with a jvm segment
instead of a cil/ilvm segment.

In a way, I expect the world of vm, jit, and vmasm to get really
interesting and bind with / import from traditional opensource
libraries and environments - the same as compiling their source
code into jvm/ilvm/whatevervm containers. What's needed as a first
step however - that autoconfigure scripts can _see_ that target
in a canonic way _without_ relying on special hacks (looking for
platform variants and project names instead of a common category).

cheers,
-- guido                                  http://google.de/search?q=guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)