Druckbare Version
Hallo,
ich konnte keinen Java Compiler oder Interpreter für Atmel uCs finden. Da ich gerne in Java programmiere, dachte ich daran einen Java Compiler selbst zu schreiben. Natürlich ohne die riesige API. Es wäre aber nett, wenn dieser Compiler über eine Bibliothek verfügt, die einen ähnlichen Funktionsumfang wie WINAVR bietet.
Nun würde mich interessieren, was ihr dazu meint. Wieviele Leute hier hätten gerne einen solchen Compiler oder wären auch daran interessiert einen zu schreiben?
Java-Compiler?
Soweit ich weiß läuft Java in erster Linie in einer Virtual Machine. Wenn man kompiliert, wäre der Vorteil der Plattformunabhängigkeit verschwunden.
Hm, da hast du dir ziemlich viel vorgenommen; bist du sicher, dass du den Aufwand nicht unterschätzt?
Ich kann nur für mich sprechen: Ich hätte vermutlich nicht so viel Interesse. Das Problem ist, dass Java-Programme eine VM benötigen. Diese VM belegt wahrscheinlich einen Großteil des Flash-Speichers. Wenn man die VM ignoriert und einen reinen (Maschinencode-)Compiler schreibt, wäre es evtl. schon eher möglich sowas zu bauen.
Bedenke aber, wie viele Leute an WinAVR mitwirkten, bis es zu dem wurde, was es jetzt ist. Ein Java-Compiler wäre mit Sicherheit nicht weniger Arbeit, eher mehr.
Es mag sein, dass Java ursprünglich für Haushaltsgeräte entwickelt wurde. Aber von diesem Ansatz hat sich die Sprache schnell entfernt. Normalerweise braucht man mindestens ein 32-Bit-System für Java.
Ich programmiere auch gern Java, aber meiner Meinung nach gehört Java nicht auf den 8-Bit-Mikrocontroller. OK, es gibt den "Javelin Stamp", der Java versteht - allerdings mit einer Menge Einschränkungen und Abweichungen vom Standard. Genauso würde es auch auf dem AVR aussehen, wenn die VM überhaupt in den Speicher passt. Am Ende wäre man trotzdem unzufrieden, weil man nicht alle Möglichkeiten der Hardware ausnutzen könnte.
Natürlich kann man einen Compiler schreiben, der Java-Syntax versteht und am Ende AVR-Maschinencode ausgibt. Aber das kostet enormen Aufwand und das Ergebnis hat nichts mit Java zu tun. Besser ist es wohl, C zu benutzen.
Achim.
Stimmt. Ich habe tatsächlich vor nur einen reinen Compiler zu schreiben und keine VM. Es wäre immer noch mindestens ganauso Plattform-unabhängig wie C, was für 8bit Microcontroller sicherlich ausreichend ist.
Die Plattformunabhängigkeit ist sowieso nicht der Hauptvorteil von Java.
Die grosse Java API könnte ich natürlich nicht übernehmen, lediglich ein paar grundlegende Klassen und zusätzlich einige speziell für den uC ausgelegte Klassen.
@voidpointer: Ein Compiler, der Java Syntax versteht und am Ende Maschinencode ausgibt ist doch ein Java Compiler. Wieso hat das deiner Meinung nach nichts mit Java zu tun? Solange er sich an die offizielle Spezifikation der Java Sprache hält (Java Sprache != Java VM).
Vorteile hat das schon. Zum einen bessere Unterstützung für OO Programmierung, was bei grösseren Projekten, z.B. auf einem Mega128 nützlich wäre. Damit kann man dann auch eine OO API bauen.
Event driven, sprich Interrupts, Programmierung wird auch übersichtlicher.
Genauso wie Threads. Java Threads lassen sich sicherlich über die Verwendung von Timern realisieren.
Gut - der Hauptgrund ist für mich natürlich einfach nur eine persönliche Vorliebe für Java, was aber meine Argumente nicht schwächt.
da man mit java keine schnittstellenpins einzeln (seriell,parallel) programmieren darf ( ist das oberste gebot von java), ist es von vorne rein schon nicht durchführbar , wenn es java genannt werden soll.
du entfernst dich damit von einem standart, da er keine sicherheiten mehr auf dem pc gibt.
mfg pebisoft
Der Java-Compiler (javac) erzeugt aus der Javasource einen Bytecode, den jede VM versteht. Für jede .java-Datei entsteht (mindestens) eine .class-Datei. Erst zur Laufzeit findet das Binding statt, nämlich bei der Interpretation des Bytecodes durch die VM. Dadurch bekommt Objektorientierung Sinn und wird das Konzept von Reflection erst möglich.Zitat:
Ein Compiler, der Java Syntax versteht und am Ende Maschinencode ausgibt ist doch ein Java Compiler. Wieso hat das deiner Meinung nach nichts mit Java zu tun? Solange er sich an die offizielle Spezifikation der Java Sprache hält (Java Sprache != Java VM)
Auf diese und viele andere Dinge (z.B. Threads) musst Du verzichten, wenn es irgendwie in den AVR reinpassen soll. Dadurch verliert sich aber der Sinn von Java. Wie gesagt - nichts gegen einen Java-Hex-Compiler - aber es ist eine Notlösung.
Die Syntax des Javelin-Stamps ist vielleicht ein Denkansatz. Darauf aufbauend könnte man etwas für den AVR entwickeln.
Achim.
Wieso bekommt Objektorientierung dadurch erst Sinn? C++ Programme laufen (in der Regel) auch nicht auf einer VM. Bedeutet das, dass bei C++ OO keinen Sinn macht?Zitat:
Der Java-Compiler (javac) erzeugt aus der Javasource einen Bytecode, den jede VM versteht. Für jede .java-Datei entsteht (mindestens) eine .class-Datei. Erst zur Laufzeit findet das Binding statt, nämlich bei der Interpretation des Bytecodes durch die VM. Dadurch bekommt Objektorientierung Sinn und wird das Konzept von Reflection erst möglich.
Es gibt eine Spezifikation für die Java Sprache und eine für die Java Runtime Environment. Diese beiden Spezifikationen sind unabhängig voneinander, heißen aber trotzdem beide Java. Bei C# haben beide unterschiedliche Namen. Die Sprache heißt C# und die Runtime Environment heißt .Net.
Mir geht es hier nur um die Sprache. Die RTE komplett auf einen Atmel uC zu übertragen wäre schwierig.
Man verliert dann natürlich die Vorteile einer JAVA VM, das ist für mich aber kein Problem. Auf Threads muss ich allerdings nicht verzichten. Selbst Reflections könnte man auch ohne VM realiseren. Ob das auf einem uC Sinn macht ist eine andere Frage.
Wie ich schon sagte sind Sprache und Runtime Environment zwei verschiedene unabhängige Dinge. Du beziehst dich auf die Java RTE, nicht auf die Sprache.Zitat:
Zitat von pebisoft
Gcc hat ein Frontend für Java ( http://gcc.gnu.org/java/). Da es auch ein Target AVR gibt, hättest du damit einen Compiler Java -> AVR Maschinencode.
Theoretisch zumindest, das Ansprechen der AVR spezifischen Hardware (UARTs, ADC usw.) müsste noch implementiert werden - weiss jetzt nicht was die Java Micro Edition dazu bietet und wie weit GCJ das wiederum unterstützt.
Trotzdem, wenn du objektorientiert auf den AVRs coden möchtest, ist C++ wohl die geschicktere Wahl, einfacher die Toolchain aufzubauen, besseres Ansprechen der Hardware, und ohne die ganze Classlib unterscheiden sich Java und C++ eh nicht besonders. Denk auch dran, dass ein im Hintergrund laufender Garbage Collector auf einem so kleinem Prozessor wie dem AVR, der üblicherweise zeitkritische Anwendungen steuern soll, sowieso nicht verwendbar ist.
Zum Implementieren von C++ auf AVR siehe auch http://www.nongnu.org/avr-libc/user-...#faq_cplusplus
Gruß, Karsten
So, habe nochmal mit einem Arbeitskollegen drüber gesprochen ;-) Man kann OO natürlich auch ohne dynamisches Binding haben. Letztlich kann man ein OO-Programm sogar in ein prozedurales transformieren. Auch gebe ich Dir recht, was den Unterschied zwischen Language- und Runtime-Spezifikation betrifft.
Dennoch bleiben viele Probleme; vor allem Resourcenverbrauch und Realtime-Verhalten. Threads schleppen üblicherweise Memory mit sich herum, das mit dem globalen Memory synchroniziert werden muss. Garbage Collection wurde auch schon als Problem genannt. Trotzdem scheint es ja mit Java Cards irgendwie zu funktionieren. Etwas Info dazu habe ich unter http://www.javaworld.com/javaworld/j...bedded-p3.html gefunden.
Aber nun das Wichtigste: Kennst Du schon simpleRTJ? Könnte das sein, was Du suchst? --> http://www.rtjcom.com/home.html
Gruß, Achim.
Stimmt, GCJ wäre einen Versuch wert.
SimpleRTJ sieht interessant aus, da steht aber, dass es mindestens 18kB Ram benötigt. Ausserdem ist es viel langsamer als C.
Hi ihrs,
ich mag zwar Java nicht so gerne wie Du, aber ich denke, mal von den Problemen abgesehen, ist es einer verdammt gute Idee. Das -aus meiner subjektiven Empfingung heraus- größte Problem bei Java ist das GUI erstellen. (Zeitaufwand und Umstände) Da das ja dann wegfällt kann man die ganzen Vorteile von Java nutzen, das finde ich einen absolut guten Ansatz!
Man stelle sich vor, durch drei, vier Zeilen kann man einen Thread bauen, der sonst ja nicht ganz so einfach wäre...
Also kurz und gut: Eine schöner Ansatz.
Aber...
Ich sehe da folgende Probleme:
Die VM kann man weglassen, das sehe ich nicht als Problem. Dann kann man Java ein bisschen in die Richtung anpassen, dass es besser auf dem System läuft und damit klar kommt, auch kein Problem (die Java Micro Edition machts nicht anders), aber hast Du schonmal daran gedacht, wie langwierig es ist, einen Compiler für OO-Sprachen zu entwickeln? Ich selbst hab das bereits zweimal gemacht und würde es in Zukunft gerne meiden 8-[
Ob Du einen Garbage Collector verwendest oder nicht, bleibt Dir überlassen, aber ich denke, in der ersten Version wird er fehlen :P
Also Fazit: Es ist eine tolle Idee, aber der Aufwand rechtfertigt nicht den Nutzen :-k
Aber falls Du es angehen möchtest und ein Team bilden willst, stehe ich zur Verfügung :-b
Viele Grüße,
wulfi
Danke nochmal für all eure Kommentare.
Nachdem ich etwas darüber nachgedacht habe bin ich mir jetzt sicher, dass ich den GCJ nicht verwenden werde.
Einer der Hauptgründe für dieses Projekt ist, dass ich schon seit längerem einen Compiler schreiben möchte und nicht dass ich einen portieren will.
Ausserdem möchte ich den Compiler in Java schreiben und er sollte in der Lage sein sich selbst zu compilieren(in dem Fall dann natürlich mit dem PC als Target).
Die erste Version, falls ich die jemals fertig bekomme, wird dann den GCC als Backend verwenden.
In der nächsten Version werde ich dann versuchen Threads und Garbage Collection einzubauen.
Ich hoffe nur, dass ich dieses Projekt nicht wieder fallen lasse bevor ich richtig begonnen habe, so wie bei meinem letzten.
Also die Beschreibung vom Anfang vor okay, aber das hier ist echt zu viel. Denk nochmal drüber nach. Du kannst doch keinen Compiler schreiben, der als Zielplattform den AVR hat und auch für den PC compilieren kann.... Überleg mal!!!
als target kann ich dir "win32forth" anbieten. schau mal unter google.
forth ist eine sprache die sich selber compiliert usw. 100% maschienennah. der compilierte code ist 100% asm.
diese sprache ist genauso gewöhnungsbedürftig wie java. also für dich richtig.
mfg pebisoft
Wie siehsts denn jetzt aus? Schläft das Projekt inzwischen?
Grüße
wulfi
Ich arbeite im Moment an einer Web Service Engine mit, die in Java implementiert ist (mit eigener XML/Query-Sprache für die Webservices) und die neben PCs und PDAs auch auf Haushaltsgeräten (zur Kommunikation untereinander und mit Steuerungsgeräten) laufen soll und bald in einem Versuchsaufbau auch laufen wird.Zitat:
Zitat von voidpointer
Java eignet sich hier eigentlich ganz gut :)
Ein Java Compiler für AVR hast du rein theoretisch mit gcc.
'avr' ist ein bekanntes backend für gcc und 'java' ein bekanntes frontend. Das bedeutet aber nicht notwendig, daß beides ohne Arbeit und Erweiterungen im gcc zusammen gestöpselt werden kann.
- Zieh dir die gcc-Quellen
- configure ... --enable-languages=c,c++,java ...
- Habe viel Spaß bis du nen avr-gcc gebuildet bekommst.
- Schreibe dir native interfaces um auf die Hardware (SFRs, IO) durchzugreifen und Interrupts abzubilden.
- Besorg dir ne libjava, die dir die Standard Java-Objekte liefert.
- Du wirst auch einen gc brauchen, zB den boehm-gc
- java wird eine Speicherverwaltung wollen.
- Und wie siehts mit Threads und Nebenläufigkeit aus?
gcc übersetzt java-Quellen klaglos nach obj, das Zeugs zu linken ist schon nicht mehr so einfach.
Java ist natürlich nett und wenn ich die Wahl hab, dann nehme ich Java und mach nen grossen Bogen um C und C++. Aber Entwicklung für Embedded ist was ganz anderes als auf einem PC zu arbeiten, der dir klaglos 20MByte per malloc() liefert. Zwar gibt es 32-Controller, die Java fahren, aber mit AVR spielt man da in einer anderen Liga.
Ein Großteil an Hardwareunabhängigkeit liefert dir auf dieser Ebene schon C.
Ist Java wirklich das was du willst?
Was ist so schlimm an C für einen 8-Bitter?
Da fällt mir grade ein, für den Lego Mindstorms RCX gibt es eine Java VM und Bibliotheken, mit denen man die Sensoren ansprechen kann...
Was hat Lego den für einen Controller? Bestimmt kein 32 Bit, oder?
Und das Java lief da recht ordentlich drauf :)
Das ganze heisst lejos, falls es jemanden interessiert
Hmmm *staun*.
Hab grad mal gegurgelt und LEGO im Weltraum gefunden. Schon erstaunlich!
In Mindstorms ist ein 8Bit Hitachi H8300, 32k Ram, 32k Flash, 16MHz.
Ich habe neulich mal 'was in diese Richtung gemacht:
www.harbaum.org/till/nanovm
EIn paar der hier genannten Einschränkungen treffen zu (keine Threads), manche nicht (Garbage Collection habe ich). Für grosse Programme reicht es sicher nicht, aber um mit dem Asuro ein paar Runden auf einer schwarzen Runde zu drehen reicht es allemal ...
Schaut gut aus. Leider funktioniert der Download nicht.Zitat:
Zitat von Harbaum
Und wie transferierst du eigentlich den Java-Bytecode auf den ASURO ?
Georg
Neue Java-Programme werden mit einem speziellen Java-Konverter entweder in ein Zwischenformat verwandelt oder wie im Fall des Asuro direkt hochgeladen. Der Konverter wirft ein paar nicht benötigte Daten aus den Classfiles und macht aus allen abhängigen Classfiles eine Datei zum Hochladen.
Und stimmt, der Link ist kaputt, den mache ich gleich heile, aber bis ich den Konverter dazugetan habe kann man da eh nicht soooo viel mit anfangen. Der Konverter kommt spätestens morgen abend auf die Seite.
Till