Ja, ja, ja --- es war unter einer anderen Lizenz. :-)
Und die alte Homepage heißt http://www.xmission.com/~icvm/
Nun haben die Homepage etwas abgespeckter gestaltet.
Vorübergehend hatten die sogar einen eigenen Firmennamen gehabt. Ich gleube "Splended Software".
Es sieht so aus, als sehen sie langsam eine starke Konkurrenz zukommen. Java wird als freie Varianten nachprogrammiert und .NET wird ducrh mono:: ebenfalls als freie Variante nachprogrammiert. Und kaum einer interessierte sich noch für Internet C++.
Ein Nachtei von Internet C++ sollte man nicht außer Acht lassen: Die Virtuelle Maschine ist nahzu identisch mit einer realen IA32-Maschine - es wurden lediglich einige Assemblerbefehle bei ICVM zusammengefaßt. Ob die ICVM-Programme auch auf nicht-x86 Rechnern so schnell laufen, weiß ich nicht.
Das ist jedoch auch das Problem, weshalb viele dem ICVM-projekt skeptisch gegenüberstehen, denn die VM hat genauso wie IA32 eine nur sehr kleine Anzahl an Registern. Besser gesagt es sind genauso viele Register wie auch die Intel-Architektur hat, mit den selben Aufgaben. Und es sei sogar der selbe Endian-Typ (was auch immer das heißen mag).
Jedenfalls seien die Großrechner der andere Endian-Typ. Und wenn die VM eine beschränkte Zahl an Registern hat, könne angeblich auch nicht die volle Funktionalität des realen Rechners ausgenutzt werden. Außerdem sei eines RISC und das andere CISC.
Als Fazit hatte mir mal ein Entwickler gesagt, daß ICVM-Programme wohl auf Intel-Rechnern viel performater läuft als Java- oder .NET-Programme, jedoch auch Großrechnern ICVM-Programme wohl deutlich in der Geschwindigkeit Java-Programmen hinterherhinken würde.
Außerdem wurde gesagt, daß ein weiteres Problem sei, daß ICVM echte Pointer verwendet.
Aber ich stehe dem Internet C++ trotzdem positiv gegenüber, denn auf meinem Pentium laufen die Programme so schnell wie Native-Programme. :-)
Würde mich übrigens freuen, wenn jemand der einen anderen Rechner als einen x86 hat, einmal die Performace von ICVM auf dem nicht-Intel-Rechner testet.
Als ich schrieb, daß ICVM (bez. neuerdings heißt es IVM) den selben Endian-Typ hat wie ein Intel-Rechner, dann meinte ich damit den Assemblercode, den man durch "gcc -S program.c" erzeugen kann. Das letztendlich entstandene Binary enthält natürlich beide Endian-Typen. (Das ist ja gerade deren Clou dabei).
Von Tim Jansen am Mi, 12. September 2001 um 20:28 #
Freddy: die Performance auf nicht-x86 Plattformen ist eine Frage des Aufwandes. Wenn du zB ein Risc-System mit vielen Registern hast, musst du beim Optimieren schon groesseren Aufwand betreiben, um diese auch alle zu nutzen und somit eine mit Java oder MS's CLR vergleichbare Performance zu bekommen. Aber unmoeglich ist es nicht.
Das Benutzen von Pointern sehe ich nicht als Problem an, zumindest unter der Bedingung, dass solche Methoden als unsicher gekennzeichnet werden, aehnlich wie man es bei .Net manuell macht. Es ist vielmehr einer der groessten Nachteile von Java, dass es Pointer nicht erlaubt. Dadurch wird es fuer manche im Userspace laufende Programme notwendig, native Teile zu haben, weil sie ansonsten einfach viel langsamer als native Programme waeren. Dadurch verdirbt Java einen der Hauptvorteile von VMs, naemlich die Unabhaengigkeit von der Prozessorarchitektur. Selbst wenn nur 5% der Programme nativen CPU-abhaengigen Code benoetigen, wird es die Benutzer dazu bewegen sich fuer die Architektur zu entscheiden, auf denen saemtliche Software laeuft und nicht nur die 95% reinen Java-Programme.
Es gibt nun mal 2 Arten, Little Endian und Big Endian.
Diesem Problem kann man aber begngen, gerade bei Netzwerkanwendungen sogar aeusserst einfach. Man schaue sich das X-Protokoll an, das dreht den Endian-Type im Netzwerkprotokoll einfach um, und schon hast du mit X Window ein platformuebergreifendes Client Server Konzept.
Dabei handelt es sich hierbei noch um die einfachste Moeglichkeit. Es gibt auch moeglichkeiten den EndianType in den Bibliotheken automatisch bestimmen zu lassen, und dafuer entsprechende Teile anzupassen, also 2 mal vorhenden zu haben (if then sozusagen).
Erfordert etwas mehr mehr Programmieraufwand. Grundsaetzlich ist es aber gar nicht so einfach, da man sehr genau aufpassen muss, was man programmiert.
Yepp, habe "Internet C++" ungefähr vor einem Jahr mal getestet. Damals war die Lizenz ziemlicher Mist, warum sich auch viele gegen das Projekt gewendet haben. Jetzt ist es aber GPL und damit steht eigentlich der Verdrängung von Java und C# nichts mehr im Weg ;)
Doom war wohl das erste Game was auf der VM gelaufen ist (mit nahezu nativer Geschwindigkeit). Ich glaub das spricht für die Performance ;
Arni, der sich gleichmal das gcc-patch und die vm holt :))
Von Anonymous am Mi, 12. September 2001 um 17:52 #
Ob die gegen Java und C# eine Chance haben? Es zeigt doch, das viele Firmen auf 'professionelle' software stehen, die was kosten und wo man für den support was bezahlen muss.
Hier besteht der support aus dem Internet und eventl einer ml Liste. Gar nicht 'professionell' genug...
Und es sind am Ende die verborten Manager in den Softwareschmieden, die die Entscheidung treffen!
Nichtsdestotrotz wünsche ich den Entwicklern viel Erfolg und Spass!
Du schreibst doch, dass ein Free-Software-Projekt keine Chance gegen ein "professionelles" Programm, das etwas kostet. Das Gegenteil ist ja schon lange bewiesen (Apache, sendmail, Linux).
Es bleibt abzuwarten, ob der Bedarf nach einer weiteren plattformunabhängigen Sprache überhaupt vorhanden ist. Immerhin existiert mit Curl (www.curl.com) ja schon eine Sprache, die ähnliche oder sogar gleiche Ziele verfolgt und derzeit in der Erprobung steht. Die die beeindruckenden Ergebnisse mit Curl können sich derzeit mittels eines geeigneten Browser-Plugins betrachten lassen, ein schneller Rechner vorausgesetzt. Eine neue Sprache mit diesen hohen Anprüchen in breiter Front neu zu etablieren, stelle ich mir derzeit als recht langwierigen Prozess vor.
> Es bleibt abzuwarten, ob der Bedarf nach einer weiteren plattformunabhängigen Sprache überhaupt vorhanden ist.
Das besondere bei Internet C++ ist, daß die Sprache nicht neu ist. Es ist das übliche C++. Außerdem ist der Compiler (Internet C++) davon auch nicht so besonders. Es ist einbfach nur eine g++-Protierung. Das Interessante ist die Virtuelle Maschine auf der die kompilierten Programme laufen! Ob da nun Internet C++ oder Internet Basic als Sprache für benutzt wurde spielt keine Rolle.
Einige Fehler sind im Makefile der vm und im source.
ivm/vm/: im file proc.cc muss #include aufgenommen werden (für nanosleep erforderlich). im Makefile müssen folgende libraries in die Zeile ADDLLIBS mit aufgenommen werden: -lXi -lXmu -lbfd
Von Anonymous am Do, 13. September 2001 um 13:19 #
Und eine 30 Jahre alte Sprache die mit kranken Ideen immer mehr aufgepusht wurde soll die Zukunft sein. Keine integrierte Thread unterstuetzung, kein GC (heute eigentlich das KO Kriterium), keine benutzbare Mehrfachvererbung, etc.
Na ja das wird das naechste Project was den Bach runtergeht und unnoetige Programmierer Kapazitaet bindet.
So wird MS jedenfalls nicht gestoppt werden koennen.
Du hast die Sprache nicht verstanden. Gerade weil nicht alles von vornherein integriert ist, ist C/C++ immer noch die Sprache Nr.1. Wer GC oder Threading-Support benötigt kann das ohne Probleme integrieren. Wer Spracherweiterungen benötigt kann sich ohne Probleme einen kleinen Compiler bauen (z.b. mit Flex) wie z.B. bei der Qt geschehen.
Für alle anderen gibt es ja auch noch Ruby oder Java, die natürlich auch mit C/C++ geschrieben worden sind
Da JAVA ja auch von C abstammt, ist es dann auch eine kranker Ablkömmling? Was ist denn eine brauchbar Sprache? Eine Sache schlecht zumachen ist leicht, aber ohne Argumente oder Beispielen leider völlig unbrauchbar.
Und wo und wie Programmiekapazität gebunden wird ist doch sache der Programmierer, oder?
Mehrfachverbung sehe ich eher als Nachteil von C++. Wenn man da nicht hoellisch aufpasst, wird schnell das ganze Programm instabil und/oder unsicher. Das ist der Grund warum Java keine Mehrfachvererbung benuetzt.
Mehrfachverbung sehe ich eher als Nachteil von C++
Nur weil C++ diese Mäglichkeit bietet, muss man sie ja nicht nutzen. Die Sprache ist nur das Werkzeug, entscheidend ist was der Programmierer daraus macht.
Das gute an C++ ist, dass es einem einen grossen Freiraum in seiner Benutzung laesst. Wer will kann beispielsweise weiterhin C-style schreiben (wuerd ich nicht empfehlen). Features sind niemals ein Nachteil, solange man sie nicht benutzen muss! Fehlende Feature sind hingegen ein Nachteil, auch wenn mache Java-Anhaenger das gerne umdrehen moechten. In Java MUSS man beispielsweise den GC(garbage collector) benutzten, was es fuer real-time Programme disqualifiziert! C++ wird irgendwann einen OPTIONALEN GC bekommen! Trotzdem sehe ich kaum einen grund fuer einen GC, man kommt gut ohne einen aus: Stichwort auto_ptr.
Warten wir mal ab: Java ist noch lange nicht fertig, was scheinbar nicht sehr bekannt ist. Vielleicht, wenn es Templates bekommt und der GC optional wird hat es moeglicher weise eine Chance. Operator-overloading sollte man auch nicht vergessen!
>So wird MS jedenfalls nicht gestoppt werden koennen.
Darum geht es ja auch gar nicht :-)
@SJW
>Da JAVA ja auch von C abstammt, ist es dann auch eine kranker Ablkömmling?
Java stammt nicht von C ab, das ist lediglich ein allgemein verbreitetes Vorurteil, auch von SUN noch unterstützt. Es (OK, OK: Oak) wurde zwar geschrieben um in einem Projekt C++ zu ersetzen und gleicht C in seiner Syntax, aber das war's dann auch schon. Mehr Ähnlichkeiten hat es mit LISP (GC, Packages, Bytecode, late-binding Methoden ...).
@gnu128
>In Java MUSS man beispielsweise den GC(garbage collector) benutzten
Nicht ganz, in SUNs JVM lässt sich die Class Garbage Collection über die option -Xnoclassgc deaktivieren. Ist aber nicht sehr empfehlenswert.
Bereits der wohl größte Fehler von Java war diese unausrottbare C-Syntax. Und jetzt das! Es ist hinlänglich bekannt, daß C++ unverhältnismäßig lange Entwicklungszeiten produziert. Daß 90% der Programmierfehler, unter denen wir heute leiden, unter moderneren Sprachkonzepten nicht möglich gewesen wäre. Schon bei Java war die Kritik der Vordenker massiv: viel zu wenig von dem alten Kram losgelassen, weit hinter neueren Konzepten zurückgeblieben. Und nun noch einen Schritt zurück!
Und wofür? Weil mehr durch Zufall ein kaum durchdachtes Sprachkonzept die Basis einer überlegenen Computerarchitektur bildete und irgendwie niemand den Absprung schafft.
Sicher, es gibt heute Massen von C++-Programmierern, die man nicht von heute auf morgen auf etwas total anderes umschulen kann. Aber zumindest in der professionellen IT-Ausbildung ist C++ tot, vielleicht besinnt sich ja auch mal die OSS-Szene, bevor sie noch mehr Code produziert, den man später wegwerfen kann.
@WinStop: Ich glaube du uebertreibst ein wenig. Welche Sprachen gibt es denn sonst? Ada? Nee, das gabs schon vor C++ und konnte sich trotzdem nicht durchsetzten. Naja, oder gleich auf functionale Sprachen umsteigen? Nee, die sind auch schon lange aus.
Also was ist schlecht an C? Vor allem an dem, was Java uebernommen hat (was du ja so anprangerst)?
Von Haug Bürger am Fr, 14. September 2001 um 08:16 #
C und C++ über einen Kamm zu scheren ist ein schwerer Fehler. C ist ein hübscher Makroassembler aber keine höhere Programiersprache. C++ schreibt sich auf die Fahnen eine höhere Programmiersprache zu sein und muss sich mit diesen messen. Höhere Programmiersprachen sollen ein höheres Abstraktionsnivau ermöglichen und möglichst viele Fehlermöglichkeiten ausschließen. Und genau da liegt der Hund bei C++ begraben. Die Feldbehandlung und die Zeichenkettenbehandlung sind in C++ sicher nicht das was man unter einem höheren Abstraktionsgrad versteht und produzieren Fehler anstatt sie zu vermeiden. Ein ganz anderer Punkt ist die Verwendung von einer >20 Jahre alten Architektur als virtuelle Maschine für die Software der Zukunft. Im Moment auf meinem Pentium mag das super funktionieren, aber was ist in 5 oder 10 Jahren? Diese Architektur wird von Intel gerade zu Grabe getragen und sollte nicht als virtuelle Maschine verewigt werden. Eine Architektur für eine virtuelle Maschine sollte auf vielen Architekturen performant realisierbar sein und möglichst wenige Beschränkungen besitzen. Wenn dieses System einen gewissen Reifegrad erreicht hat, wird es die notwendige Hardware nicht mehr geben. Software die auf eine Architektur optimiert ist hat im Zeitalter der mobilen Geräte ausgedient. Wo bleibt also der Vorteil von Internet C++ gegenüber vorhandenen Systemen? Aber interessanterweise setzen sich selten die besseren Systeme durch, so hat Internet C++ vielleicht eine Chance.
Oder verwechsele ich da gerade etwas?
Und die alte Homepage heißt http://www.xmission.com/~icvm/
Nun haben die Homepage etwas abgespeckter gestaltet.
Vorübergehend hatten die sogar einen eigenen Firmennamen gehabt. Ich gleube "Splended Software".
Es sieht so aus, als sehen sie langsam eine starke Konkurrenz zukommen. Java wird als freie Varianten nachprogrammiert und .NET wird ducrh mono:: ebenfalls als freie Variante nachprogrammiert. Und kaum einer interessierte sich noch für Internet C++.
Ein Nachtei von Internet C++ sollte man nicht außer Acht lassen: Die Virtuelle Maschine ist nahzu identisch mit einer realen IA32-Maschine - es wurden lediglich einige Assemblerbefehle bei ICVM zusammengefaßt. Ob die ICVM-Programme auch auf nicht-x86 Rechnern so schnell laufen, weiß ich nicht.
Das ist jedoch auch das Problem, weshalb viele dem ICVM-projekt skeptisch gegenüberstehen, denn die VM hat genauso wie IA32 eine nur sehr kleine Anzahl an Registern. Besser gesagt es sind genauso viele Register wie auch die Intel-Architektur hat, mit den selben Aufgaben. Und es sei sogar der selbe Endian-Typ (was auch immer das heißen mag).
Jedenfalls seien die Großrechner der andere Endian-Typ. Und wenn die VM eine beschränkte Zahl an Registern hat, könne angeblich auch nicht die volle Funktionalität des realen Rechners ausgenutzt werden. Außerdem sei eines RISC und das andere CISC.
Als Fazit hatte mir mal ein Entwickler gesagt, daß ICVM-Programme wohl auf Intel-Rechnern viel performater läuft als Java- oder .NET-Programme, jedoch auch Großrechnern ICVM-Programme wohl deutlich in der Geschwindigkeit Java-Programmen hinterherhinken würde.
Außerdem wurde gesagt, daß ein weiteres Problem sei, daß ICVM echte Pointer verwendet.
Aber ich stehe dem Internet C++ trotzdem positiv gegenüber, denn auf meinem Pentium laufen die Programme so schnell wie Native-Programme. :-)
Würde mich übrigens freuen, wenn jemand der einen anderen Rechner als einen x86 hat, einmal die Performace von ICVM auf dem nicht-Intel-Rechner testet.
Grüße
Freddy
Als ich schrieb, daß ICVM (bez. neuerdings heißt es IVM) den selben Endian-Typ hat wie ein Intel-Rechner, dann meinte ich damit den Assemblercode, den man durch "gcc -S program.c" erzeugen kann. Das letztendlich entstandene Binary enthält natürlich beide Endian-Typen. (Das ist ja gerade deren Clou dabei).
Freddy
Plattformen ist eine Frage des Aufwandes. Wenn du zB ein Risc-System mit vielen Registern hast, musst du beim Optimieren schon groesseren Aufwand betreiben, um diese auch alle zu nutzen und somit eine mit Java oder MS's CLR vergleichbare Performance zu bekommen. Aber unmoeglich ist es nicht.
Das Benutzen von Pointern sehe ich nicht als Problem an, zumindest unter der Bedingung, dass solche Methoden als unsicher gekennzeichnet werden, aehnlich wie man es bei .Net manuell macht. Es ist vielmehr einer der groessten Nachteile von Java, dass es Pointer nicht erlaubt. Dadurch wird es fuer manche im Userspace laufende Programme notwendig, native Teile zu haben, weil sie ansonsten einfach viel langsamer als native Programme waeren. Dadurch verdirbt Java einen der Hauptvorteile von VMs, naemlich die Unabhaengigkeit von der Prozessorarchitektur. Selbst wenn nur 5% der Programme nativen CPU-abhaengigen Code benoetigen, wird es die Benutzer dazu bewegen sich fuer die Architektur zu entscheiden, auf denen saemtliche Software laeuft und nicht nur die 95% reinen Java-Programme.
also ./icvm gears hat gerade mal 50% der Leistung als das original gears.
Naja, aber wenn es Plattformübergreifend ist (wird) und die Entwickler arbeiten ja noch drann, könnte man es sich irgendwan mal näher angucken.......
Es gibt nun mal 2 Arten, Little Endian und Big Endian.
Diesem Problem kann man aber begngen, gerade bei Netzwerkanwendungen sogar aeusserst einfach. Man schaue sich das X-Protokoll an, das dreht den Endian-Type im Netzwerkprotokoll einfach um, und schon hast du mit X Window ein platformuebergreifendes Client Server Konzept.
Dabei handelt es sich hierbei noch um die einfachste Moeglichkeit. Es gibt auch moeglichkeiten den EndianType in den Bibliotheken automatisch bestimmen zu lassen, und dafuer entsprechende Teile anzupassen, also 2 mal vorhenden zu haben (if then sozusagen).
Erfordert etwas mehr mehr Programmieraufwand. Grundsaetzlich ist es aber gar nicht so einfach, da man sehr genau aufpassen muss, was man programmiert.
mad
MfG,
Hartmut
Jetzt ist es aber GPL und damit steht eigentlich der Verdrängung von Java und C# nichts mehr im Weg ;)
Doom war wohl das erste Game was auf der VM gelaufen ist (mit nahezu nativer Geschwindigkeit). Ich glaub das spricht für die Performance ;
Arni, der sich gleichmal das gcc-patch und die vm holt :))
Es zeigt doch, das viele Firmen auf 'professionelle' software stehen, die was kosten und wo man für den support was bezahlen muss.
Hier besteht der support aus dem Internet und eventl einer ml Liste.
Gar nicht 'professionell' genug...
Und es sind am Ende die verborten Manager in den Softwareschmieden, die die Entscheidung treffen!
Nichtsdestotrotz wünsche ich den Entwicklern viel Erfolg und Spass!
Eine neue Sprache mit diesen hohen Anprüchen in breiter Front neu zu etablieren, stelle ich mir derzeit als recht langwierigen Prozess vor.
Das besondere bei Internet C++ ist, daß die Sprache nicht neu ist. Es ist das übliche C++.
Außerdem ist der Compiler (Internet C++) davon auch nicht so besonders. Es ist einbfach nur eine g++-Protierung.
Das Interessante ist die Virtuelle Maschine auf der die kompilierten Programme laufen!
Ob da nun Internet C++ oder Internet Basic als Sprache für benutzt wurde spielt keine Rolle.
ivm/vm/:
im file proc.cc muss #include aufgenommen werden (für nanosleep erforderlich).
im Makefile müssen folgende libraries in die Zeile ADDLLIBS mit aufgenommen werden: -lXi -lXmu -lbfd
Na ja das wird das naechste Project was den Bach runtergeht und unnoetige Programmierer Kapazitaet bindet.
So wird MS jedenfalls nicht gestoppt werden koennen.
Wer GC oder Threading-Support benötigt kann das ohne Probleme integrieren. Wer Spracherweiterungen benötigt kann sich ohne Probleme einen kleinen Compiler bauen (z.b. mit Flex) wie z.B. bei der Qt geschehen.
Für alle anderen gibt es ja auch noch Ruby oder Java, die natürlich auch mit C/C++ geschrieben worden sind
Was ist denn eine brauchbar Sprache? Eine Sache schlecht zumachen ist leicht, aber ohne Argumente oder Beispielen leider völlig unbrauchbar.
Und wo und wie Programmiekapazität gebunden wird ist doch sache der Programmierer, oder?
Nur weil C++ diese Mäglichkeit bietet, muss man sie ja nicht nutzen. Die Sprache ist nur das Werkzeug, entscheidend ist was der Programmierer daraus macht.
Features sind niemals ein Nachteil, solange man sie nicht benutzen muss! Fehlende Feature sind hingegen ein Nachteil, auch wenn mache Java-Anhaenger das gerne umdrehen moechten.
In Java MUSS man beispielsweise den GC(garbage collector) benutzten, was es fuer real-time Programme disqualifiziert! C++ wird irgendwann einen OPTIONALEN GC bekommen!
Trotzdem sehe ich kaum einen grund fuer einen GC, man kommt gut ohne einen aus: Stichwort auto_ptr.
Warten wir mal ab: Java ist noch lange nicht fertig, was scheinbar nicht sehr bekannt ist. Vielleicht, wenn es Templates bekommt und der GC optional wird hat es moeglicher weise eine Chance. Operator-overloading sollte man auch nicht vergessen!
gnu, das trotzdem lieber Java als C# sieht
>So wird MS jedenfalls nicht gestoppt werden koennen.
Darum geht es ja auch gar nicht :-)
@SJW
>Da JAVA ja auch von C abstammt, ist es dann auch eine kranker Ablkömmling?
Java stammt nicht von C ab, das ist lediglich ein allgemein verbreitetes Vorurteil, auch von SUN noch unterstützt. Es (OK, OK: Oak) wurde zwar geschrieben um in einem Projekt C++ zu ersetzen und gleicht C in seiner Syntax, aber das war's dann auch schon. Mehr Ähnlichkeiten hat es mit LISP (GC, Packages, Bytecode, late-binding Methoden ...).
@gnu128
>In Java MUSS man beispielsweise den GC(garbage collector) benutzten
Nicht ganz, in SUNs JVM lässt sich die Class Garbage Collection über die option -Xnoclassgc deaktivieren. Ist aber nicht sehr empfehlenswert.
Und wofür? Weil mehr durch Zufall ein kaum durchdachtes Sprachkonzept die Basis einer überlegenen Computerarchitektur bildete und irgendwie niemand den Absprung schafft.
Sicher, es gibt heute Massen von C++-Programmierern, die man nicht von heute auf morgen auf etwas total anderes umschulen kann. Aber zumindest in der professionellen IT-Ausbildung ist C++ tot, vielleicht besinnt sich ja auch mal die OSS-Szene, bevor sie noch mehr Code produziert, den man später wegwerfen kann.
Mißmutiger Gruß, WinStop.
Ich glaube du uebertreibst ein wenig. Welche Sprachen gibt es denn sonst? Ada? Nee, das gabs schon vor C++ und konnte sich trotzdem nicht durchsetzten. Naja, oder gleich auf functionale Sprachen umsteigen? Nee, die sind auch schon lange aus.
Also was ist schlecht an C? Vor allem an dem, was Java uebernommen hat (was du ja so anprangerst)?
Ein ganz anderer Punkt ist die Verwendung von einer >20 Jahre alten Architektur als virtuelle Maschine für die Software der Zukunft. Im Moment auf meinem Pentium mag das super funktionieren, aber was ist in 5 oder 10 Jahren? Diese Architektur wird von Intel gerade zu Grabe getragen und sollte nicht als virtuelle Maschine verewigt werden. Eine Architektur für eine virtuelle Maschine sollte auf vielen Architekturen performant realisierbar sein und möglichst wenige Beschränkungen besitzen. Wenn dieses System einen gewissen Reifegrad erreicht hat, wird es die notwendige Hardware nicht mehr geben. Software die auf eine Architektur optimiert ist hat im Zeitalter der mobilen Geräte ausgedient.
Wo bleibt also der Vorteil von Internet C++ gegenüber vorhandenen Systemen?
Aber interessanterweise setzen sich selten die besseren Systeme durch, so hat Internet C++ vielleicht eine Chance.
Haug
Assembler rult immer noch am meisten :=)