libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Guido Draheim
Subject: Re: dotnet platform support / gnu config.sub (long)
Date: Tue, 23 Sep 2003 22:57:34 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313



Guido Draheim wrote:
* short

The world has changed - there are commandline tools for unixish systems
that take a C program (not C#!) and compile them into a MSIL binary or
library. This makes it a valid crosscompile target for free software.
The free projects for the dotnet platform - mono, dotgnu, portablenet
and others - have developed runtime services that are usable now. Very
soon now, these will be installed in parallel to JVM in distros.

Looking into config.sub, libtool, automake etc., you'll notice that
there is not even minimal support for that platform. This e-mail is
just asking a thing that sounds simple but may turn out controversial:
            How to name the platform in config.sub?
That will have consequences when support for that crosscompile target
platform is being added to libtool and friends.


Apart from some link-related discussions on the libtool-ML,
there was not more than a single reply about the configtype
name. No real interest in the canonic name of dotnet platforms
for free software? Well, let's push it with a specific proposal.

The first part gives there reasoning on a generalized approach
for VM-type bytecode target binaries and other binary format
being in an intermediate language encoding. Some terminology
stems from config.sub usage of the configtype triplet as being
broken into CPU-COMPANY-KERNEL-OS

The actual proposals are near the end - please comment.

* CPU

The current cil virtual machine can interpret (or compile) code in the
default 64bit format or some 32bit format. In other words, the VM is
assumed with 64bit pointers and `long` is 64bit as well. One can
reassemble the code into 32bit only but that will make dotnet binaries
to not run anymore on 64bit machines.

For the java machine, the term `jvm` is used universally. I do not
remember there were any dependency on pointer lengths, it runs in
managed mode always.

While the term `cil` itself might be ambigous, we can expect the
mnemonic names of cil32 and cil64 to point to the dotnet cil. However,
I would like to generalize the concept of 'vm's in the cpu type.
Therefore, we use 'ilvm' plus the variants of ilvm32 and ilvm64.

From now on, any cpu type containing 'vm' is thought to be a
virtual machine running with an interpreter. It can not be
ensured that the local build platform is capable of running
the type of vm binaries however - there may be dependencies
on the 32bit or 64bit type and dependencies on the byte order.

For the latter, gforth binaries are an example which can generate
relocatable bytecode which are theoretically portable to any of
its vm incarnations running on a similar address-type system. The
"le" and "be" suffixes may be used as indicators for endianess.

Since ilvm64 may be run on a 32bit system, we do set the two
cpu/vm types of "ilvm" and "ilvm32" for the dotnet binaries
and libraries. Alongside we use "jvm" for jar binaries.
Alternativly, if the interpreter input has text format
instead of bytecode then a universal "script" may be used.

* KERNEL

We generalize the assumption on the execution engine for a binary.
Theoretically, any input language may be compiled into any other
turing-complete execution format including scripting languages.
When there is an interpreter around for a target binary then the
name of that interpreter is pasted up front.

The idea includes a generalization for autoconf scripts  that may
try to uppercase the interpreter value and find a shell-variable
that points to the current interpreter binary on the build
platform. That makes a lot of tests easier. As another indicator,
any interpreter-value must be followed by an OS suffix which may
however be a service series indicator.

Therefore, for jvm we do usually paste 'java' as interpreter and
'jdk' as basic service series. Likewise the dotnet binaries are
given as 'ilrun' for the interpreter and 'mono' for the service
series (or something alike).

The same for the other interpreter types that may or may not
run bytecode of their scripts. A "python" interpreter can run
"script" code or "pyvm" bytecode, also across different real
cpu architectures. Similar for gforth bytecode "gfvm" or scripts.

* company

As always, that may be the one who did ship the series, possibly
a distributor in the linux world.

* summary

proposed are these canonic platforms:

ilvm-pc-ilrun-mono
ilvm32-pc-ilrun-mono
ilvm-pc-ilrun-pnet
ilvm32-pc-ilrun-pnet
ilvm-pc-ilrun-msvc
ilvm32-pc-ilrun-msvc
jvm-sun-java-jdk
jvm-sun-java-j2me
jvm-sun-java-j2se
jvm-sun-java-j2ee
pyvm-pc-python-2.2
script-pc-gforth-6.1
vm32be-pc-gforth-6.1
vm32le-pc-gforth-6.1

In the above list, only the "ilvm*-" type system may be seen
in the wild as target platforms since there are decent
compilers available that can convert c/c++ code into their
vm-formatted binaries. The other platforms use a specific
input language, so there is no similar thing of multiple
different input languages compiling to the same intermediate
object format that can be subject to further link/bind
operations independent from the input language. Theoretically
however, it is possible - compare especially the python
AST support within its core library to dynamically build an
execution tree from any parser of whatever input syntax.

* ACTION plan

I would like to see dotgnu/pnet to pick up the -milvm32
switch instead of the -m32bit_only flag. The variant of
config.sub should not say "cil-unknown-none" and switch
over to the ilvm-* type as above.

While the term cil has gained wider usage, it may be good
to pick up the the term ilvm more widely. The MONO websites
do have some "CIL virtual machine" or "CIL VM" references which
should be shortened to "ilvm" in many places.

The autoconf project may need to look at the current concept
of running test programs on the build platform and how that
can be connected with canonic-systemtype settings. It may be
possible to seek out additional values for vm-platforms and
set them as ilrun_vmbuild / ilrun_vmhost instead of build / host,
or just short vmbuild / vmhost, or even change autodetect
buildtype when a vm-target is detected, then setting it to
the related vmtype that can be executed on the build platform.

For config.sub, relevant detections and aliases should be
added to turn into canonic formats. It would be great to have
some way to express that cpu="*vm*" is reserved for bytecode
type binaries, which also require ENGINE-PACK in the place of
KERNEL-OS. Perhaps add config.guess targets can seek out the
local platform pack value of a `config.guess ilrun`? Hmmm.

Anyway, a PATCH is given that adds support for ilvm, jvm
and pyvm targets. I have tested it with various variants
including just saying `config.sub ilrun`. Please comment,
or in the lack of interest, just commit to gnu config cvs.

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)




Index: config.sub
===================================================================
RCS file: /cvsroot/config/config/config.sub,v
retrieving revision 1.288
diff -u -r1.288 config.sub
--- config.sub  18 Aug 2003 08:54:40 -0000      1.288
+++ config.sub  23 Sep 2003 20:45:37 -0000
@@ -3,7 +3,7 @@
 #   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
 #   2000, 2001, 2002, 2003 Free Software Foundation, Inc.
 
-timestamp='2003-08-18'
+timestamp='2003-09-23'
 
 # This file is (in principle) common to ALL GNU software.
 # The presence of a machine in this file suggests that SOME GNU software
@@ -218,6 +218,8 @@
                basic_machine=m68k-atari
                os=-mint
                ;;
+        -jdk | -j2*)
+                os="-java$os"
 esac
 
 # Decode aliases for certain CPU-COMPANY combinations.
@@ -600,6 +602,12 @@
                basic_machine=i386-unknown
                os=-vsta
                ;;
+        cil | ilvm | ilrun)
+                basic_machine=ilvm-pc
+                ;;
+        cil32 | ilvm32 | ilrun32)
+                basic_machine=ilvm32-pc
+                ;;
        iris | iris4d)
                basic_machine=mips-sgi
                case $os in
@@ -614,6 +622,10 @@
                basic_machine=m68k-isi
                os=-sysv
                ;;
+        jvm | java | jvm-java)
+               basic_machine=jvm-sun
+                os=`echo "-java$os" | sed -e 's/java-java/java/'`
+                ;;
        m88k-omron*)
                basic_machine=m88k-omron
                ;;
@@ -822,6 +834,10 @@
                basic_machine=i586-unknown
                os=-pw32
                ;;
+        pyvm | python)
+               basic_machine=pyvm-unknown
+                os=`echo "-python$os" | sed -e 's/python-python/python/'`
+                ;;
        rom68k)
                basic_machine=m68k-rom68k
                os=-coff
@@ -1141,7 +1157,8 @@
              | -storm-chaos* | -tops10* | -tenex* | -tops20* | -its* \
              | -os2* | -vos* | -palmos* | -uclinux* | -nucleus* \
              | -morphos* | -superux* | -rtmk* | -rtmk-nova* | -windiss* \
-             | -powermax* | -dnix* | -nx6 | -nx7 | -sei*)
+             | -powermax* | -dnix* | -nx6 | -nx7 | -sei* \
+             | -java* | -ilrun* | -python*)
        # Remember, each alternative MUST END IN *, to match a version number.
                ;;
        -qnx*)
@@ -1423,6 +1440,15 @@
        *-atari*)
                os=-mint
                ;;
+        ilvm-* | ilvm32-*)
+                os=`echo "-ilrun$os" | sed -e 's/ilrun-ilrun/ilrun/'`
+                ;;
+        jvm-*)
+                os=`echo "-java$os" | sed -e 's/java-java/java/'`
+                ;;
+        pyvm-*)
+                os=`echo "-python$os" | sed -e 's/python-python/python/'`
+                ;;
        *)
                os=-none
                ;;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]