Welcher Programmiersprache gehört die Zukunft im Embedded Bereich? C++ oder Java

[this-*gt*that]

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?

[~fricky]

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.

[volkard]

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.

[~fricky]

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.

[DEvent]

volkard schrieb:

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. [...]

Zu was zaehlt dann Googles Android und das G1 Phone?

[this-*gt*that]

volkard schrieb:

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.

Ok, Danke.

Aber irgendwie ist so ein Beispiel doch schon bißchen gekünstelt. Immerhin ist das ja nicht nur unperformanter Code sondern schlichtweg falscher Code und sollte so nie ausgeliefert werden.

[Kennerio]

DEvent schrieb:

volkard schrieb:

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. [...]

Zu was zaehlt dann Googles Android und das G1 Phone?

Das eine ist ein Toaster und das andere eine Waschmaschine.
Und einen größeren Schwachsinn habe ich selten gelesen (@volkard).

[volkard]

this->that schrieb:

Aber irgendwie ist so ein Beispiel doch schon bißchen gekünstelt. Immerhin ist das ja nicht nur unperformanter Code sondern schlichtweg falscher Code und sollte so nie ausgeliefert werden.

nee, die __pure_call wird reingelinkt, auch wenn ich sie nicht aufrufe.

[volkard]

Kennerio schrieb:

Und einen größeren Schwachsinn habe ich selten gelesen (@volkard).

es würde dir gut anstehen, dir die geschichte von java ein wenig zu gemüte zu führen. kläre dabei doch mal die designziele von oak ab. in den alten jdks steht übrigens noch oak statt java in den dateikopfkommentaren.

[rapso]

volkard schrieb:

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.

neue prozessoren in waschmachinen? vielleicht auch noch druckern?
also fuer den fall muss man keine angst haben, da kannst du weiterhin einen 80186 bei intel bestellen

aber ich glaube du warst hier nur zu ueberzeugend mit deinem sarkasmus und ich bin drauf reingefallen :xmas1:

[Embedded Progger]

loks schrieb:

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.

Nein, die Annahme ist nicht falsch.

Denn wenn heute 512 MB Flashspeicher 50 Cent kosten und die Produktion von
4 MB RAM sich nicht mehr lohnt, warum sollte man dann noch 4 MB RAM Flashspeicher herstellen und als Kunde auf die 512 MB verzichten?

Und ganz ähnlich sieht es mit CPUs aus.
Einen MSP430 bekommst du schon für 2 € (bei hohen Stückzahlen) nachgeworfen und das ist schon bezogen auf die Herstellungskosten eigentlich so gut wie fast ganz unten.
Und die CPU selbst wird immer schneller und Leistungsfähiger.
Heute reicht es für Java noch nicht, aber in 10 Jahren ist auch ein billiger Embedded Chip wie der MSP430 schnell genug, um Java auszuführen.

Die Annahme, daß man immer die leistungsschwächsten Chips nehmen kann ist also falsch, weil sich die Produktion dieser Chips einfach irgendwann nicht mehr finanziell lohnt und dann nimmt man die schnellere Variante die dann vielleicht auch nur 2 € / Stück kostet.

Oder anders gefragt könntest du dich auch fragen, warum du einen 8 Bit Z-80 einsetzen sollst, wenn du heute einen 32 Bit MPS430 für das gleiche Geld bekommst.

[Embedded Progger]

~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.

Wieviel kosten 128 MB RAM heute? 2 €?

Und wann ist der Punkt errericht, bei dem sich die Produktion eines RAM Speichers, mag er eine noch so kleine Kapazität haben, allein von den Material und Herstellungskosten nicht mehr lohnt?
1,5 € vielleicht?

Also und wenn du heute 128 MB RAM für 2 € nachgeworfen bekommst, warum
solltest du dann auf eine JVM verzichten?
In 128 MB RAM paßt die gut rein.

Zur Not tut es auch JavaME.

[Embedded Progger]

vlad_tepesch schrieb:

also wir programmieren unsere µCs und DSPs in C. Warum?
geringere Größe weil, schlankere Runtime.
keine dynamische speicherallokierung erlaubt.
meist auch schneller.

Ja geringere Größe und schlankere Runtime.
Aber ihr arbeitet dann sicher noch mit Embedded Chips die noch nicht den Speicher und Leistung von heutigen aktuellen Embedded Chips liefern.

Also noch alte Technik, wegen langen in der Industrie üblichen Supportzeiten von 10 Jahren.
Aber DAS wird irgendwann aufhören, in 10 Jahren habt ihr sicher auf einen der neuen Embedded Chips umgestellt und ist Speicherplatzersparnis und schlankheit
der Routinen kein Argument mehr um auf Programmierfreundliche Programmiersprachen zu verzichten.

In diesem Kontext möchte ich das betrachtet sehen.

Außerdem kann man auf den GC und dynamische Speicherallokierung ja auch verzichten.
Das geht sowohl in C++ als auch in D.

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.

Ja, aber siehe oben.

Irgendwann gibt es die Leistungsschwachen 8 Bit CPUs nicht mehr oder sie lohnen sich nicht mehr, weil die 32 Bit CPUs genau das gleiche kosten.

Und die DSP wandern bei diesen Embedded CPUs sowieso mit auf den Chip.
Man denke z.B. an ARM oder MSP430 CPUs.

Edit:
außerdem ist c natärlich sehr Hardwarenah.

Ja, das ist jetzt einer der Gründe, welche wirklich für C sprechen.
Aber dies wäre zumindest mit C++ und D auch möglich.

[Embedded Progger]

[quote="rapso"]

vlad_tepesch schrieb:

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.

Ja, wenn es um grafische Oberflächen geht.
Z.b. eine grafishes Menü mit Touchpad für eine Waschmaschine, dann wäre Java sicher eine Option.

Aber was Hardwarenaheprogrammierung betrifft, mit Realtime Code.
Da ist es ja nun wirklich nicht so, daß hier C++ oder D nicht gehen würde.

[Embedded Progger]

Nagila Hawa schrieb:

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.

Meinst du Newcomer wie D?

Ja, wenn die ersten Compiler für Embedded Platformen verfügbar sind, dann wäre D in der Tat sehr interessant.

[Gast]

Embedded Progger schrieb:

Aber DAS wird irgendwann aufhören, in 10 Jahren habt ihr sicher auf einen der neuen Embedded Chips umgestellt und ist Speicherplatzersparnis und schlankheit
der Routinen kein Argument mehr um auf Programmierfreundliche Programmiersprachen zu verzichten.

Auch in 10 Jahren wird es große und kleine µC geben, und auch in 10 Jahren wird der Große mehr kosten als der Kleine (Ausnahmen die diese Regel bestätigen gibt es auch heute). Da kannst du mit deinen "für 2€ hinterhergeschmissen"-µCs kommen wie du willst. Auch in 10 Jahren wird man eine Rechnung aufstellen und Abhängig von Stückzahl, Entwicklungskosten, Produktionskosten etc. entscheiden welcher µC genommen wird. Aber mit deinen letzten Worten schlägt bei mir auch der troll-o-meter an. "Programmierfreundliche Programmiersprachen" sorry, ernst nehmen kann ich dich nicht...

Und D? Hallo? Ich lach mich gleich weg...

[tfa]

volkard schrieb:

Kennerio schrieb:

Und einen größeren Schwachsinn habe ich selten gelesen (@volkard).

es würde dir gut anstehen, dir die geschichte von java ein wenig zu gemüte zu führen. kläre dabei doch mal die designziele von oak ab. in den alten jdks steht übrigens noch oak statt java in den dateikopfkommentaren.

Oje! Das ist wirklich schon mehr als 10 Jahre her, dass sich Sun von Oak und dem Gedanken verabschiedet hat, eine Programmiersprache für Toaster und Waschmaschinen zu entwickeln. Java hat sich in den letzten anderthalb Jahrzehnten weiter eintwickelt, falls du dir das mal zu Gemüte führen willst.
Und Java auf Handys ist nun mal Fakt. Ob einem das gefällt oder nicht.

[vlad_tepesch]

Embedded Progger schrieb:

Also noch alte Technik, wegen langen in der Industrie üblichen Supportzeiten von 10 Jahren.
Aber DAS wird irgendwann aufhören, in 10 Jahren habt ihr sicher auf einen der neuen Embedded Chips umgestellt und ist Speicherplatzersparnis und schlankheit
der Routinen kein Argument mehr um auf Programmierfreundliche Programmiersprachen zu verzichten.

Naja unser DSP ist nicht so alt: Blackfin 561 dualcore mit je 500MHz. und davon sinds 2.
Dennoch ist es recht wenig, für die vielzahl der Anwednungen, die er gleichzeitig berechnen soll.
hierbei handelt es sich um Bildverarbeitung mit komplexen matehmatischen Hypothesen und Modellen, die gebildet werden.
Zumal er keine FPU hat.

Das heißt man investiert bewusst einige Mannjahre an Ent-double-isierungsaufwand um dann ein paar Dollar einzusparen.
Es kommt halt auf die Stückzahlen an.

Ebendso mit der portierung nach C.
Wenn man sich die STL anschaut, ist das sehr nett, aber natürlich auch recht overhead-behaftet, der eingespart werden muss.

Außerdem kann man auf den GC und dynamische Speicherallokierung ja auch verzichten.
Das geht sowohl in C++ als auch in D.

Garbage Collector in C++?
D? lol, find mal ein embedded compiler für D.

[borg]

Embedded Progger schrieb:

Wieviel kosten 128 MB RAM heute? 2 €?

Soso, und du denkst 2€ sind wenig? Was glaubst du wie oft sich z.B. ein Controller der die Neigung von einem Scheinwerfer in Autos entsprechend der Lastverteilung im Auto anpasst verkauft? Für 2€ kannst du da ohne weiteres 5 Mannjahre (und mehr) investieren. Dazu kommt noch das die Kosten dafür verglichen mit den Kosten für Tests und Zertifizierungen gar nicht auffallen.

[Embedded Progger]

vlad_tepesch schrieb:

Garbage Collector in C++?
D? lol, find mal ein embedded compiler für D.

Ja, natürlich.
In C++09 wird der Garbage Collector dabei sein und ich versuche den Thread ja auf die Sicht aus "in 10 Jahren" zu betrachten.

Und in 10 Jahren wird es für D bestimmt auch brauchbare Compiler für embedded Chips geben, denn gerade D bietet sich ja für solche Embedded Chips an.
Es hat nicht die Nachteile von C++ oder C, aber ist genauso für die Systemprogrammierung geeignet wie C und bietet darüberhinaus noch eine gute STD API.