Welcher Programmiersprache gehört die Zukunft im Embedded Bereich? C++ oder Java
-
Embedded Progger schrieb:
Das Ziel dürfte klar sein, der Embedded Markt gehört bald den großen dicken Programmiersprachen wie C++ und Java.
Auch wenn mein Trollmeter hier stark ausschlägt...
Diese Annahme ist einfach falsch. Im embedded Markt geht es vor allem um Kostenminimierung. Egal wie Leistungsfähig die Hardware auch sein mag, kein Hersteller wird Resourcen verschwenden wenn es nicht sein muß. Hier wird dann eher bei steigernder Leistungsfähigkeit einfach weniger Hardware eingesetzt -> Kostenersparnis.
Im Konsumermarkt klappt das nur deswegen weil die Kunden dumm sind und jeden Scheiß kaufen wenn nur schöne Zahlen draufstehen. Aktuelles Beispiel: 480Hz Bildschirme... Klar, aber sicher doch...
-
Embedded Progger schrieb:
Das Ziel dürfte klar sein, der Embedded Markt gehört bald den großen dicken Programmiersprachen wie C++ und Java.
es gibt seit jahren betrebungen in diese richtung wie z.b. http://www.caravan.net/ec2plus/
und http://www.harbaum.org/till/nanovm/index.shtml
aber das ist alles exotischer kram, den kaum jemand verwendet.
-
den chip gibt es doch, arm jazelle oder so?
-
rapso schrieb:
den chip gibt es doch, arm jazelle oder so?
klar, der kann 'native' java byte code ausführen. ist aber trotzdem relativ witzlos, weil zu java mehr gehört, z.b. ein GC und viele library-funktionen. und schon braucht man wieder unmengen an speicher.
-
müss euch noobs leider enttäuschen. die realität heißt c und das wird auch so bleiben, die anderen sprachen sind einfach zu hässlich. und ich bin hier wahrscheinlich einer der wenigen im thread, die auch wirklich in diesem bereich tätig sind und nicht nur von was rumlabern, womit sie noch nie was gemacht haben.
-
~fricky schrieb:
rapso schrieb:
den chip gibt es doch, arm jazelle oder so?
klar, der kann 'native' java byte code ausführen. ist aber trotzdem relativ witzlos, weil zu java mehr gehört, z.b. ein GC und viele library-funktionen. und schon braucht man wieder unmengen an speicher.
Zu Java gehören weder zwingend GC noch viele Library-Funktionen. Wenn diese nicht nötig sind (wie z.B. embedded Bereich) lässt man sie halt weg.
Java läuft sogar auf Smart-Cards. Die haben wirklich nur ein paar 100 Bytes Speicher. Die VM kann fast überhaupt nichts, kein GC, keine Lib; nur byte, short und Kontrollstrukturen.
Natürlich gibt es auch "vernünftige" JVMs für Embedded. Warum auch nicht? Speicher ist billig.
-
Hacker23 schrieb:
muess euch noobs leider enttaeuschen. die realitaet heisst c und das wird auch so bleiben, die anderen sprachen sind einfach zu haesslich. und ich bin hier wahrscheinlich einer der wenigen im thread, die auch wirklich in diesem bereich taetig sind und nicht nur von was rumlabern, womit sie noch nie was gemacht haben.
ich denke nicht, dass die "Schoenheit" einer Sprache bei sowas ein allzu wichtiges Kriterium ist (und vor allem nicht das einzige). Vor allem wuerde C da auch nicht unbedingt toll dastehen.
Aber das weisst du ja als "Profi" natuerlich bereits
-
also wir programmieren unsere µCs und DSPs in C. Warum?
geringere Größe weil, schlankere Runtime.
keine dynamische speicherallokierung erlaubt.
meist auch schneller.Wenn man so durch Portierung vom Prototypencode in c++ nach c einen DSP einsparen kann, oder einen kleineren verwenden kann, lohnt sich bei entsprechenden Stückzahlen natürlich auch ein Portierungsaufwand von 2-3 Mannjahren.
Ich glaub das wird in vielen anderen Firmen ähnlich gehandhabt.
Edit:
außerdem ist c natärlich sehr Hardwarenah.
-
tfa schrieb:
Zu Java gehören weder zwingend GC noch viele Library-Funktionen. Wenn diese nicht nötig sind (wie z.B. embedded Bereich) lässt man sie halt weg.
ohne viel drumherum ist java praktisch unbrauchbar. kannst ja mal gucken was man für jazelle oder j2me in der minimalkonfiguration schon alles braucht. das sprengt den rahmen eines billig-µCs um dimensionen.
-
vlad_tepesch schrieb:
außerdem ist c natärlich sehr Hardwarenah.
das war auch mit die wichtigste grundlage beim design von c. compiler sollten relativ leicht guten assembler code generieren koennen, das hat c auch so einige weak points bescherrt.
ich muss zu meinem erstaunen noch heute feststellen dass c code schneller laeuft als c++ code
ich denke das liegt aber nicht an schlechteren compilern, sondern an mehr restriktionen an die sie sich halten muessen bei c++.ich denke java hat eine chance wenn es hauptsaechlich um die anwendung geht und nicht die hardware. wenn die software aber nur das mittel zum zweck ist (weil es um die hardware geht), wird c weiter standard bleiben.
-
rapso schrieb:
vlad_tepesch schrieb:
außerdem ist c natärlich sehr Hardwarenah.
das war auch mit die wichtigste grundlage beim design von c. compiler sollten relativ leicht guten assembler code generieren koennen...
ja, c ist eigentlich eine prozessorunabhängige assemblersprache.
rapso schrieb:
ich muss zu meinem erstaunen noch heute feststellen dass c code schneller laeuft als c++ code
ich denke das liegt aber nicht an schlechteren compilern, sondern an mehr restriktionen an die sie sich halten muessen bei c++.wenn du aber in c++ wie in c programmierst (also ohne klassen, templates etc. zu benutzen), dürfteste da kaum unterschiede feststellen.
-
~fricky schrieb:
wenn du aber in c++ wie in c programmierst (also ohne klassen, templates etc. zu benutzen), dürfteste da kaum unterschiede feststellen.
Wenn Du in C++ wie in C programmierst dann nennt man das C++ ohne Klassen, oder in der bekannten Kurzform: C
-
Embedded ist nicht gleich Embedded.
Java- und Python- Programme laufen immer häufiger auf eingebetteten Systemen, das ist schon richtig. Oftmals laufen aber ihre Laufzeitumgebungen auf einem vollwertigen Betriebssystem, da würde ich die doch eher Anwendugsprogramme nennen.
Die verwendete Sprache hängt vom Einsatzgebiet ab. Die Software einer Stoppuhr in Ada zu schreiben ist wohl genauso sinnlos wie die komplette Software eines Kampfflugzeugs in Assembler zu schreiben. Wer auf einem kleinen Controller unbedingt eine Java-Umgebung oder einen Python-Interpreter laufen lassen will - bitte schön, falls sie überhaupt drauf passen. Sinnvoll ist das nicht.
Die Stückzahlen sind natürlich auch interessant. Bei einem Einzelstück doppelt so viel Geld für Speicher und Rechenleistung auszugeben und dafür die Hälfte der Entwicklungskosten zu sparen ist sinnvoll. Bei einer sehr großen Auflage sollte man eher den umgekehrten Weg wählen.
Mobile Geräte müssen natürlich auch Energie sparen. Der effizienteste Energiesparprozessor bringt nichts, wenn die Software die zehnfache Rechenleistung benötigt, wie eine alternative Lösung für die gleiche Aufgabe.
Ich würde sagen Assembler und C werden weiterhin für kleine Programme verwendet, C++ für größere Systeme, Ada für sicherheitskritische Systeme. Zumindest tendenziell.
Ein Newcomer würde mich natürlich brennend interessieren.
-
~fricky schrieb:
wenn du aber in c++ wie in c programmierst (also ohne klassen, templates etc. zu benutzen), dürfteste da kaum unterschiede feststellen.
leider doch, viele dinge die im c code gaengig sind, gehen in c++ nicht. und waehrend ein c compiler manche dinge sehr gut optimiert (immer mit dem hintergedanken: der coder wird schon wissen wozu er mich treibt), unterlaesst ein c++ compiler das (oder compiliert erst garnicht), weil c++ eben sichereren code generieren soll (du kannst natuerlich auf umwegen fast genau den selben code generieren lassen, das bestreit ich nicht).
aber c++ ist eben fuer large scale dinge, durch bessere algorithmen kann man oft viel mehr gewinnen als durch perfekten assembler. bei embeded wuerde ich meinen sind die dinge oft simpler und brauchen viel handarbeit um das potential der hardware auszunutzen. (simpler nicht im abwertenden sinne).
das ist auch das schoene an c++ (bzw c), in kleinen, kritischen dingen kann man c oder assembler teile einbauen die das letzte bisschen rausholen.
ich kenne leute die java bytecode-assembler schreiben um einige embeded dinge schneller zu machen
(oldskool meets borg). mir entgeht der sinn davon java zu nutzen wenn man hardwarenah arbeiten will/muss."The right tool for the right job".
-
Nagila Hawa schrieb:
Embedded ist nicht gleich Embedded.
Der wahrscheinlich erste wirklich sinnvolle Satz im Thread
-
Embedded Progger schrieb:
Das Ziel dürfte klar sein, der Embedded Markt gehört bald den großen dicken Programmiersprachen wie C++ und Java.
java hat gute chancen in den sektoren, wofür java erfunden wurde. also waschmaschinen und toaster. einfache programme, man kann auch laien zum coden einstellen, man kann fette prozessoren und kann viel elektrische leistung verbruzzeln. für handies und settop-boxes sehe ich eher keinen sinn in der verwendung von java. bei den waschmaschinen ist sehr toll, daß man nur ne neue VM braucht, wenn es den nächsten prozessor gibt, und die braucht man nicht selber zu bauen. die waschprogramme laufen dann einfach weiter.
c++ hat ein dickes problem damit, daß man im embedded-sektor recht feste daran glaubt, c++-programme seinen teuerer als welche in c und assembler. das ist überhaupt nicht der fall, allerdings muß man sehr sauber programmieren und nicht für jeden mist std::string nehmen. sehr nett verkackt hat man, wenn bei der allerersten deklaration einer virtuellen funktion die __pure_call und dadurch die __terminate und dadurch cout gelinkt werden und die datei auf einmal 500k groß ist. da muß man halt ein wenig aufpassen.
-
volkard schrieb:
sehr nett verkackt hat man, wenn bei der allerersten deklaration einer virtuellen funktion die __pure_call und dadurch die __terminate und dadurch cout gelinkt werden und die datei auf einmal 500k groß ist. da muß man halt ein wenig aufpassen.
Nur aus Interesse: Könntest du das etwas näher erläutern was du mit __pure_call etc. meinst?
-
volkard schrieb:
da muß man halt ein wenig aufpassen.
'ein wenig' ist ein wenig untertrieben. du musst höllisch aufpassen, sonst reiht sich ein 'bloat' an den anderen.
-
this->that schrieb:
Nur aus Interesse: Könntest du das etwas näher erläutern was du mit __pure_call etc. meinst?
eine funktion, die aufgerufen wird, wenn man es schafft, eine pur virtuelle funktion aufzurufen. kann man zum beispiel schaffen, wenn man im konstruktor eine pur virtuelle funktion aufruft. diese __pure_call schreibt dann auf die standardausgabe "abnormal programm termination: pure virtual function called" und beendet das programm. sie muß natürlich nicht genau __pure_call heißen, sie ist auch im standard nicht gefordert, aber sie ist. komisch eigentlich, mit heutzutagigen debuggern könnte man einfach eine 0 in die vtbl schreiben.
-
rapso schrieb:
das ist auch das schoene an c++ (bzw c), in kleinen, kritischen dingen kann man c oder assembler teile einbauen die das letzte bisschen rausholen.
an Java ebenso. du kannst 'ne JNI-dll in assembler schreiben, wenn's sein muss. aber die plattformunabhängigkeit geht dabei vor die hunde.