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
;;
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
