vishia

C oder C++ sind als Implementierungssprachen in der Embedded Welt weit verbreitet oder genauer gesagt die Favoriten. C++ hat sich dabei in den letzten Jahren auch bei seltenen Prozessoren durchaus etabliert. Allerdings sprechen einige Gründe dafür, weiterhin auf C zu setzen.

Doch es gibt eine Nach-C-Ära. Diese ist spätestens mit Java eingeleitet. Java ist nicht nur der Favorit in Internet- verteilten Anwendungen- und PC-Programming, sondern ist auch in vielen Geräten als embedded Software präsent. Java ist konsequent objektorientiert und damit softwaretechnologisch besser. Ein Hauptpunkt ist die Sicherheit der Software. Sicherheit hat dabei zwei Aspekte:

Sicherheit bezüglich der Programmierung, Fehleranfälligkeit, TimeToMarket fehlerarm
Sicherheitsrelevante Software.

Java hat nur den Makel der Nicht-Echzeitfähigkeit. Dabei geht es nicht um Schnelligkeit (typisches Argument von Java-Kritikern: Die VirtualMachine wäre ein Interpreter daher langsam, stimmt nicht, JIT (Just In Time)-Compiler heben diesen Nachteil auf. Und etwas längere Startup/Ladezeiten sind woanders auch akzeptiert). Der Schwachpunkt ist das Prinzip der Garbage Collection, wasfür bestimmte Zeiten über -zig Millisekunden die Bearbeitung auch mal blockiert.

Nun gibt es in der JTRES (Java Technologies for Real-time and Embedded Systems) darauf Antworten:

Die Entscheidung für Java ist eine weitgehende Systementscheidung, die nicht überall gegangen werden kann. Eine Möglichkeit für den Einsatz von Java ist:

Entwickeln und Testen mit Java
Implementieren in C

Dann hat man in der Embedded Sphäre die gegebene Systemumgebung. Und kann dennoch von der Java-Softwaretechnologie profitieren. Entwickelt wird in Java am PC, meist unter Eclipse. Damit sind die Algorithmen getestet. Implementiert und maschinengetestet wird in C

Es gibt mehrere Ansätze für die Konvertierung von Java nach C oder C++. Hier wird ein eigener Ansatz vorgestellt. Dabei geht es nicht darum, beliebige Java-Programme nach C(++) zu konvertieren. Das wäre Eulen nach Athen zu tragen, denn Java sollte man dann original verwenden. Es geht darum, für typische Embedded-Software Java verwenden zu können, und dann nach C zu konvertieren. Dazu ist ein abgestimmter Leistungsumfang ausreichend. Dieser umfasst aber auch das Interfacekonzept und die wichtigsten Klassen aus java.lang und java.util.

Zwischenstände sind downloadbar, siehe vishia-downlaodPage

Stand des Projektes:

October 2010: It was happen many things, though it may not visible in the downloads.

I think, the english language should be used, because it is world-wide. I have some problems writing english still, but learning by doning. If you see any errors in grammer or writing, excuse me please ... :-)

I have had a presentation on the JTRES-Conference in august 2010, see paper. It was very nice in Prague.

I have done some experiencis with Linux. It works proper, Ubuntu 10.4. But it works not so fine which I would like. But Linux is good, any time, without doubt. The CRuntimeJavalike library, I have translated with Eclipse-CDT. The adaption of the operation system layer (OSAL) was necessary for Linux. It is done and pre-tested, but not tested in all constellations.

The garbage collector BlockHeap is completed with some test outputs, using the Message-Dispatcher.

The usage of the BlockHeap for nodes of LinkedList is tested, but not ready yet.

In the moment I'm busy with other things in profession, it is time to spend for Java2C, but it needs more time.
Mai 2010: Mittlerweile ist die String-Verarbeitung im deutschen Text ausführlich beschrieben und dabei nochmals überarbeitet: An der Veröffentlichung der nächsten Version wird gearbeitet.
Oktober 2009, Version 0.91: Diese Version führt das Multithreading in die Java2C-Übersetzung nun endgültig ein. Im Bereich der Javadoc:Test & Examples ist ein Beispiel mit drei Threads enthalten, 2 Threads arbeiten parallel mit synchronized, ein dritter Thread wartet auf ein notify. Alle drei Threads schalten im 10 ms-Raster um. Das läuft auf Windows im Standard-Java auch problemlos, weil der Garbage-Collector in diesem kleinen Beispiel nichts weiter zu tun hat. Die Compilerung der generierten C-Quellen unter Ms-Visual Studio zeigt die selben Resultate. Die Adaption des Betriebssystems ist beschrieben in CRuntimeJavalike-Thread.
Oktober 2009, Version 0.90: Die Darstellung der Strukturen mit UML war ein entscheidender Sprung. Das Programm wurde zu komplex, schlecht durchschaubar. Das Motto ''Hauptsache funkt'' reicht nicht. Umstrukturieren und Dokumentieren!

Die Version 0.87 hat dann erstmalig vollst�ndig das Vererben und Implementieren von Interfaces enthalten. Eine Funktionalit�t, die f�r embedded Systeme gar nicht so oft gebraucht wird. Aber wenn man in embedded sonst in C++ arbeitet, nutzt man solche Dinge auch.

Bereits im Januar 2009 hat sich ein Problem herausgestellt: Partielle �bersetzung. Ein Teil des nach C �bersetzen Codes ist bereits in Libraries eingebunden (konkret war das [[javasrc:_org/vishia/util/StringPart]]), ein anderer Teil geh�rt zu einem darauf aufbauenden Modul und ist daher in C in einer anderen Library anzusiedeln, konkert der MessageDispatcher. Die Idee mit den stc-Files war schon da, aber es gab Differenzen in der Anordnung der Files und Erkennung der richtigen stc-Files. Daher ist zur Version 0.90 die Packagezuordnung �berarbeitet und nun endg�ltig gel�st.

Beim Test zeigt sich die eine oder andere Seite. Die String-Verkettung sah in C nicht sch�n aus, funktioniert zwar, aber.... Die Verkettung insgesamt musste auf tempor�re Zwischenzeiger aufbauen, weil sonst �berladene Methoden nicht richtig funktionieren, Seiteneffekte wenn die zuvor gerufenen Methoden einer Verkettung nicht nur einfache Zugriffe enthalten. Damit war die Stringverarbeitung auch �berarbeitungsw�rdig. Da mittlerweile ein Package java2C.test entstanden ist, neben dem PositionControl-Example, war alles ganz gut testbar.

Was jetzt ansteht ist die Einf�hrung des Multithreadings. Es ist ja alles schon �berlegt und vorgetestet, aber noch nicht in Java2C so eingebunden, das es Andere auch nutzen k�nnen. Damit muss aber nicht der �bersetzer selbst erweitert werden, sondern die CRuntimeJavalike muss ordentlich angepasst werden. Das ist demn�chst zu tun.

Anfang Januar 2009: Um den Garbage Collector zu testen, habe ich ein Log-Message-Dispatching Konzept benutzt. Ein Einzelschritt-debug-stochern hilft wenig weiter, es müssen Massen an alloc und tests stattfinden und kontrolliert werden. Das ist zwar noch nicht erfolgt, man braucht dann auch ein Multithreading. Nur dann ist das Ganze sensitive. Aber die Grundlagen sind da. Derzeit entsteht ein File testLog/GC0105_1200.log, (mit Monat, Tag, Stunde, Minute im Filenamen), dem man die Extension .csv zusätzlich verpassen und dann mit MS-Excel anschauen kann. Dann ist es möglich, in den ersten Spalten filtern. nach GC-Ausgaben, nach bestimmten Speicherblöcken, nach anderen Ausgaben.

Das Message-Dispatcher-Konzept ist als Idee bei mir vor ca. 2 Jahren entstanden und successive eingesetzt worden. Hier bedeutet es, dass man mehrere Log-Ausgabefiles haben kann, und aufgrund Message-Ident-Nummern bestimmen kann, welche Ausgaben wohin geschrieben werden oder auch unterdrückt werden, auch mehrfach. Man kann in diesem Sinn beliebig viele Meldungen an allen möglichen Stellen erzeugen, verbraucht einige Nanosekunden für den Aufruf, bis der Message-Dispatcher die meisten dieser Meldungen in die Tonne kippt (nicht weiter leitet). Man kann dann mit Änderung der Message-Dispatching-List (textuell vorgebbar, wird geparst) zur Laufzeit bisher verborgene Meldungen gezielt scharf schalten, wenn man einen bestimmten Zusammenhang untersuchen möchte. Für das GC-Konzept bedeutet das, grundsätzlich erzeugt der GC und jedes alloc Messages, die aber normalerweise nicht ausgegeben werden - läuft alles verborgen, gut und sicher. Sucht man aber einen Fehler, möchte man wissen, wann etwas allokiert und freigegen wurde, dann kann man diese Messages scharf schalten und ausgeben.

Das Message-Dispatcher-Konzept ist ursprünglich in C++ entstanden. Die Idee, es auch in Java zu nutzen liegt nahe. Die Programmierung in Java ist einfacher, insbesondere weil die bereits getesteten und in Java2C erfolgreich behandelten StringPart,java-Parsing-Routinen gut genutzt werden konnten. Damit waren die Message-Dispatching-Routinen der nächste Kandidat, der sich für Java2C bewähren musste. Hier trat nun die Problematik der Implementierung von Interfaceroutinen auf. Das ist grundsätzlich gelöst, aber derzeit nur für das in C extern programmierte LogMessage.java-Interface benutzbar. Es gibt noch keine Übersetzung für Interfaces in Java, also noch ein wenig Arbeit für die Zukunft.
Anfang Dezember 2008: Die Stringverarbeitung ist etabliert. Die in Java verwendete Klasse org/vishia/util/StringPart.java war die erste, die nicht als Muster den Java2C-Translation-Test bestehen musste. Es ist viel Detailarbeit geleistet, der Java2C-Translator wird nunmehr nicht nur für das erste Example eingesetzt. Detailarbeit liegt auch in der Array-Verarbeitung. Beim praktischen Einsatz des übersetzten StringPartJc.c in einem embedded System ohne Garbage Collector und ohne Speicherallokierung zur Laufzeit hat es sich sehr schnell als notwendig erwiesen, auch Instanzen im Stack als embedded führen zu können. Das ist zulässig, wenn die Lebzeit nicht über der Ablaufzeit der instanziierenden Routine liegt. Es muss aber noch gesichert werden, dass nicht an irgendeiner Stelle die Stack-Instanz persistent referenziert wird. Das ist noch ein TODO der Sicherheit, nicht der Funktionsfähigkeit. Es soll dies über Annotationen an Methodenargumenten gelöst werden. Der Java2C-Translator kann feststellen, ob eine Referenz gesetzt wird, er muss einen Fehler melden, wenn eine Referenz als nicht-persistent bezeichnet ist. Im Standard-Java ist das alles kein Thema, aber bei embedded-realtime.
August 2008: Urlaubszeit, da kommt man etwas zu was. Das Ziel ist, die Stringverarbeitung zu etablieren. Zunächst ist aber die argumentsensitive Methoden-Erkennung (überladene Methoden) gelöst. Dabei ist in den Listen, in denen Identifier gespeichert und wiedergefunden werden, einiges umstrukturiert Eine andere wichtige Konsolidierung war das Erzeugen und die Einbindung von finalize() in den Garbage Collector. Ohne dieses wäre es so, dass gelöschte Instanzen (weil sie nicht referenziert werden) womöglich selbst etwas anderes referenzieren. Das wäre kein Problem, wenn es nicht die Rückwärtsreferenzen gäbe.Also muss jede Instanz ihre eigenen Referenzen erstmal auf null setzen, bevor sie gelöscht werden kann. Das wird automatisch in die finalize-Methode hinein generiert, weil der Java2C-Translator die Referenzen selbst kennt. Der Anwender braucht also nichts zu tun. Die Stringverarbeitung ist noch in Arbeit. Es ist aber wieder einiges vollständiger Dokumentiert.
Juni 2008: Die Version 0.82 ist schon länger bei Sourceforge, der Garbage Collector ist getestet.. Seit dem ist einiges in den Java-Sources kommentiert und verbessert. Die C-Sources von CRuntimeJavalike sind auch etwas überarbeitet.
April 2008: Der Zweitstand des java2C-Translators ist verf�gbar. In dieser Version 0.81 ist die Übersetzung des throw aus Java nach C implementiert, sowie die Abarbeitung von try/catch/throw in C, wie es auch in ExceptionJc.c beschrieben ist.