X-Received: by 10.13.221.84 with SMTP id g81mr9259594ywe.55.1505213741817; Tue, 12 Sep 2017 03:55:41 -0700 (PDT) X-Received: by 10.31.151.65 with SMTP id z62mr155790vkd.19.1505213741777; Tue, 12 Sep 2017 03:55:41 -0700 (PDT) Path: csiph.com!3.us.feeder.erje.net!feeder.erje.net!news.linkpendium.com!news.linkpendium.com!news.snarked.org!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!q8no2789688qtb.0!news-out.google.com!j49ni1191qtc.1!nntp.google.com!b1no1600881qtc.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: de.comp.lang.forth Date: Tue, 12 Sep 2017 03:55:41 -0700 (PDT) Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=88.67.26.136; posting-account=_xSPOgoAAADBmH0fzI0X_LYvC0mT510V NNTP-Posting-Host: 88.67.26.136 User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: =?UTF-8?Q?JVM_als_Killerapplikation_f=C3=BCr_Forth_Chips?= From: Manuel Rodriguez Injection-Date: Tue, 12 Sep 2017 10:55:41 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Lines: 56 Xref: csiph.com de.comp.lang.forth:444 Das Hauptproblem mit heute verf=C3=BCgbaren Forth CPUs wie der GA144 ist, dass es keine Hochsprachencompiler gibt. Einen C to Forth Konverter zu programmieren ist zwar m=C3=B6glich, aber anspruchsvoll. Als komplett unm= =C3=B6glich gilt hingegen der Versuch C++ auf einer Stackmachine auszuf=C3=BChren. Dies= e H=C3=BCrde hat dazu gef=C3=BChrt, dass Forth CPUs ein Nischendasein f=C3=BC= hren und f=C3=BCr den Mainstream nicht interessant sind. Daran =C3=A4ndert auch nich= ts die Tatsache, dass sie f=C3=BCr den Preis von 20$ das St=C3=BCck verkauft werde= n. Wenn kein Linux darauf l=C3=A4uft, kann man mit der Hardware leider nichts anfan= gen. Die Killerapplikation, welche Forth CPUs zu einem Durchbruch verhilt sind Bytecode Interpreter f=C3=BCr Stackmacchinen. Genauer gesagt geht es darum, die Java Virtual Maschine auf einem GA144 Prozessor zum Laufen zu bekommen. Java Bytecode liegt bereits als stackbased code vor, er l=C3=A4sst sich deutlich leichter in die Forth Syntax =C3=BCberf=C3=BChren = als jede andere Programmiersprache. Intel wei=C3=9F das und f=C3=BCrchtet sich vor d= em Tag wo jemand eine derartige Runtime Umgebung auf den Markt bringt. Weil das nichts anderes bedeutet, als dass man die hocheffizienten, energiesparenden und preiswerten Forth Chips welche f=C3=BCr 20 US$ das St=C3=BCck verkauft = werden, nutzen kann um leistungsstarke Intel Xeon Prozessoren die 10000 US$ das St=C3=BCck kosten zu ersetzen. Die Business Kunden k=C3=B6nnten ihre vorhan= denen Java-Appliaktionen dann auf physischen Stackmaschinen laufen lassen, welche standardm=C3=A4=C3=9Fig als Array angeordnet sind, clockless getakte= t sind und sich extrem preiswert fertigen lassen. Obwohl ich ein wenig bei Google rumgesucht habe, habe ich noch keine "JVM->Forth" Engine gefunden. Aber wirklich anspruchsvoll ist es nicht. Es w=C3=A4re ein Projekt, was in seiner Tragweite vergleichbar ist, als wenn m= an einen Linux Kernel ins Leben ruft. Diesmal hei=C3=9Ft der Gegner nicht Micr= osoft sondern diesmal soll Intel platt gemacht werden. Hat man erstmal einen "JVM->Forth" Compiler kann man den Sourcecode der heute schon existiert auf Forth Chips portieren, ohne dass auch nur ein Anwender sich mit der umgekehrten polnischen Notation herumplagen m=C3=BCsste. Wie man es verhindern kann, dass eine solche Engine jemals programmiert wird ist simpel. Indem man massiv Stimmung macht gegen Forth im Allgemeinen und Stackmachinen im Besonderen. Zuletzt geschehen in dem Arxiv Paper "A Performance Survey on Stack-based and Register-based Virtual Machines" https://arxiv.org/pdf/1611.00467.pdf bei dem selbstverst=C3=A4ndlich als Fa= zit zu lesen war, dass Registermaschinen schneller w=C3=A4ren und Stackmaschine= n eine Sackgasse darstellen. Wer sich etwas mit Forth auskennt dem wird diese Argumentation merkw=C3=BCrdig vertraut vorkommen. Es handelt sich um die Anti-Stackmaschinen-Verschw=C3=B6rung.