D vs. C++

Apfelbirne schrieb:

Und die VM ist ein Gegenargument, weil die praktisch wie ne Blackbox ist und man keine Kontrolle über sie hat, was sie gerade tut oder zu tun hat.

Und noch etwas.

Bei der VM kommt dann auch noch das Problem der Garantie der bestmöglichen Fehlerfreiheit dazu.

Bei Assembler das, mit C ist es schwieriger aber nicht unmöglich.
Gleiches gilt für C++ oder D.

Aber Java ist für AKWs nicht zugelassen, die VM ist ne Blackbox über die du keine Kontrolle hast, da können tausende Bugs drin sein.
Das ist also unzureichend für die Anforderungen.

Und noch etwas.

Umso schwächer die Hardware, was bei HW unter Strahlungsbedingungen arbeitende HW aus obigen Gründen aufgrund der Auslegung der Fall ist, umso wichtiger wird echte Echtzeitfähigkeit.
Denn da hast du keinen hochgezüchteten Zig GHz Prozessor, dessen Taktrate hoch genug ist, um ein paar Taktzyklen Däumchen zu drehen.
Da kommt es noch wirklich auf die Software an.

Das Shuttle wird z.B. von 8086 CPUs betrieben, sie arbeiten bei ca. 4-10 MHz.
Moderne strahlungsresistente CPUs die man inzwischen für neue Sachen verwendet können ein klein bischen mehr, aber da wird man auch aus Stromversorgungsgründen, der weiterhin notwendigen großen Fertigungstechnik aus Strahlungsgründen und den daraus resultierenden hohen Stromverbrauch auch weiterhin kaum schneller als 33 MHz takten.

Korrektur, es sollte heißen

Apfelbirne schrieb:

Bei Assembler geht das,

volkard

Apfelbirne schrieb:

, aber eben nicht harte Echtzeitfähigkeit die gut genug ist, um z.B. auf physikalische Prozesse am LHC & Co im Nanosekundenbereich zu reagieren.

Du bist am Erkenntnisgewinn im Dialog doch gar nicht interessiert, sondern willst nur recht behalten.

Noch etwas zur Fehlerfreiheit.
Im Fall von Marsrobotern und Co muß die Software über Monate bis Jahre fehlerfrei ohne einen einzigen Absturz laufen, das kannst du mit einer VM im Hintergrund niemals garantieren.

Die Voyagersonden arbeiten schon seit über 35 Jahren, weil man da die Hardware noch mit Assembler programmiert hat.

35 Jahre ist ne lange Zeit, für eine Java VM würde ich nicht die Hand ins Feuer legen, daß sie so lange ohne Absturz funktioniert.

volkard schrieb:

Apfelbirne schrieb:

, aber eben nicht harte Echtzeitfähigkeit die gut genug ist, um z.B. auf physikalische Prozesse am LHC & Co im Nanosekundenbereich zu reagieren.

Du bist am Erkenntnisgewinn im Dialog doch gar nicht interessiert, sondern willst nur recht behalten.

Mir geht es nicht ums Recht behalten, sondern darum euch zu informieren und auch zu belehren.

Schau dir das mit den 35 Jahren und der VM an, glaubst du ernsthaft, daß das funktionieren würde und du als Entwickler diese Laufzeit garantieren kannst?

Apfelbirne schrieb:

Schau dir das mit den 35 Jahren und der VM an, glaubst du ernsthaft, daß das funktionieren würde und du als Entwickler diese Laufzeit garantieren kannst?

Klar, nicht weniger als bei Assembler. Die Java-VM ist natürlich relativ komplex, aber wie wäre es mit einer kleinen überschaubaren VM für eine kleine, überschaubare Sprache? Die VM dabei geschrieben in Assembler. Merkste was?

Apfelbirne schrieb:

Mir geht es nicht ums Recht behalten, sondern darum euch zu informieren und auch zu belehren.

Naja, du fischst dir ständig semiwahre Behauptungen und leere Argumente aus dem Nichts, nur um dir nicht einzugestehen, dass du falsch liegst.

Zeus

Apfelbirne schrieb:

Mir geht es nicht ums Recht behalten, sondern darum euch zu informieren und auch zu belehren.

Du willst uns Scheiße belehren, redest von Zeug vom dem du keine Ahnung hast.

Braunstein

Hallo,

Bei den aktuell auf dem Mars aktiven Rovern war kein Java im Spiel.
Quelle: http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/37499/1/05-0539.pdf

Ausschnitt:

The Flight Software is coded primarily in ANSI C, with some targeted assembly code and some C++. The size of the system, in source lines of code (SLOC), is [300K] but this value does not include the operating system.
Although many aspects of the design are objected-oriented, the features of the language incorporating inheritance and polymorphism are not exploited. We have found that when implemented to their fullest extent in C++, these constructs result in detrimental code size and add the potential for non-deterministic behavior. These costs, especially in time and effort to achieve a robust implementation, outweigh the benefits.

muemmel

Hi,

rein von der Sache her ist vieles möglich, Wirth hat auch demonstriert, dass man ein Betriebssystem in Modula2 Schreiben kann. Soll angeblich sogar fehlersicher gewesen sein. Aber obs einen Sinn ergibt, das ist immer die andere Frage.

Einen über Jahrezehnte gehenden Betrieb kann man auch dadurch erreichen, dass man einen Hardware-Timer hat, der jeweils nach einer Vorwarnung (Zustand speichern wenn noch möglich) alle n Zeiteinheiten einen Hardware-Reset auslöst.

Auch könnte man sämtliche Funktionsaufrufe (oder zumindest die wichtigsten) in einem hardwareunterstützten Array mit hardwareunterstützter Zeitüberwachung anordnen, das bei nicht erfolgtem Rücksprung innerhalb einer vorgegebenen Maximalzeit einen Zwangsrücksprung auslöst.

All das sind aber sehr tiefe Eingriffe in die eigentliche Programmklogik, die um so problematischer werden, je komplexer die verwendete Programmiersprache und Laufzeitumgebung ist.

Auch ist bei einer Raumsonde kein allzu großer Verarbeitungsaufwand nötig, da man sich da auf das wirklich notwendige beschränkt. Es gibt also eigentlihc nichts, was mehr als ASM und C erfordert oder rechtfertigt.

Gruß Mümmel

muemmel schrieb:

Es gibt also eigentlihc nichts, was mehr als ASM und C erfordert oder rechtfertigt.

Bei 300k LOC (ohne OS) könnte man schon drüber nachdenken..

thread-leser schrieb:

Apfelbirne schrieb:

Schau dir das mit den 35 Jahren und der VM an, glaubst du ernsthaft, daß das funktionieren würde und du als Entwickler diese Laufzeit garantieren kannst?

Klar, nicht weniger als bei Assembler. Die Java-VM ist natürlich relativ komplex, aber wie wäre es mit einer kleinen überschaubaren VM für eine kleine, überschaubare Sprache? Die VM dabei geschrieben in Assembler. Merkste was?

Wir sind hier nicht beim Thema Neuerfindung einer Sprache um dafür dann erst eine VM in Assembler zu programmieren.
Das macht auch keinen Sinn, da es Schwachsinn ist.

Denn anstatt die VM zu programmieren kannst du gleich damit anfangen die eigentliche Software in Assembler für das Weltraumdings der ESA/NASA usw. zu schreiben.

Braunstein schrieb:

Hallo,

Bei den aktuell auf dem Mars aktiven Rovern war kein Java im Spiel.
Quelle: http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/37499/1/05-0539.pdf

Ausschnitt:

The Flight Software is coded primarily in ANSI C, with some targeted assembly code and some C++. The size of the system, in source lines of code (SLOC), is [300K] but this value does not include the operating system.
Although many aspects of the design are objected-oriented, the features of the language incorporating inheritance and polymorphism are not exploited. We have found that when implemented to their fullest extent in C++, these constructs result in detrimental code size and add the potential for non-deterministic behavior. These costs, especially in time and effort to achieve a robust implementation, outweigh the benefits.

Das sage ich doch schon die ganze Zeit.

[quote="Zeus"]

Apfelbirne schrieb:

Mir geht es nicht ums Recht behalten, sondern darum euch zu informieren und auch zu belehren.

Du willst uns Scheiße belehren, redest von Zeug vom dem du keine Ahnung hast.

Ich gebe nur wieder wie es bei der NASA und ESA gesehen wird, wenn du also weiterhin glaubst es besser zu wissen, dann kannst du ja die NASA und ESA vollscheißen und versuchen da dein Javading durchzudrücken.

Ich aber sage dir, daß du dort gehörig auf Widerstand treffen wirst, manche werden dich auch für besonders doof halten oder dich nicht mehr ernst nehmen und ignorieren.

Ihr glaubt allen ernstes es besser zu wissen als ich, schön, aber habt ihr schonmal darüber nachgedacht, warum die NASA und ESA Java bei solchen Sachen nicht nutzt?

Recherchiert mal, dann werdet ihr auf all die Dinge stoßen, die ich hier schon mehrfach genannt habe.

dot

Was haben Spezialanwendungen aus Luft- und Raumfahrt jetzt eigentlich genau mit der Frage zu tun was eine Systemprogrammiersprache ist und was nicht

Weisst du überhaupt noch, wofür du eigentlich argumentierst? Du meintest, dass es eine strikte Trennung für Systemprogrammiersprachen gibt und darüber diskutieren wir. Keiner von uns will die Steuereinheit in den ICEs mit PHP programmiert sehen.

Deine Argumente:

Laut Definition keine VM oder APIs => Ist aber deine eigene Definition
Man muss den AVX-Befehlssatz einbetten können => Da gibt C/C++/D auch nichts vor
Vollständig bewiesene Fehlerfreiheit muss möglich sein => Kann man für alle "deterministischen" Sprachen oder für keine
Harte Echtzeitfähigkeit => Wenn für C möglich, dann auch für C, das in einer VM, die in C geschrieben ist, läuft
35 Jahre Laufzeitgarantie lassen sich mit Assembler aber nicht mit VM garantieren => Wenn du die VM in selber Qualität in Assembler programmierst und die Anwendungslogik in irgendeiner Skriptsprache mit selbiger Codequalität, nimmt sich das nichts

Dann diskutierst du manchmal von einem versuchten wissenschaftlichen Standpunkt und manchmal ziehst du de facto-Beispiele heran. Und dass du dich hier von Braunstein bestätigt fühlst, zeigt nur wie wenig du überhaupt unsere Posts verstanden hast.

dot

Und was das "Beweisen der Fehlerfreiheit" angeht ist C/C++ unbrauchbar. Das war zumindest die Take Home Message unserer Echtzeitsysteme Vorlesung...aber das nur am Rande, hat ja auch nichts mit dem Thema zu tun...

muemmel

Hi,

selbst wenn man die Fehlerfreiheit von C beweisen kann, so ists doch noch was anderes auch die Fehlerfreiheit des Compilers zu beweisen, und der ist immer bei jeder Übersetzung (selbst bei Assembler) mit im Boot.

Alternativ kann man aber das ganze in C (oder sonst einer Sprache) schreiben und nicht automatisch übersetzen, sondern ein Mensch mit ausreichender Erfahrung und Sorgfalt setzt sich hin und spielt selbst Compiler.

Gruß Mümmel

volkard

Bewiesen fehlerfreies Programm? Soll das heißen, daß es tut, was die Spezifikation verlangt? Dann muß ja die Spezifikation bereits in einer exakten Sprache niedergeschrieben werden. Und wer sagt uns dann, daß die so niedergeschriebene Spezifikation das ist, was wir eigentlich haben wollen? Irgendwo bleibt da immer eine Lücke, die bisher nur denkende Menschen ausfüllen können.

cooky451

volkard schrieb:

Bewiesen fehlerfreies Programm? Soll das heißen, daß es tut, was die Spezifikation verlangt? Dann muß ja die Spezifikation bereits in einer exakten Sprache niedergeschrieben werden. Und wer sagt uns dann, daß die so niedergeschriebene Spezifikation das ist, was wir eigentlich haben wollen? Irgendwo bleibt da immer eine Lücke, die bisher nur denkende Menschen ausfüllen können.

Wenn man ein Programm in eine formale Sprache überführen könnte, könnte man dann nicht auch formal beweisen, dass das Programm das tut, was es tuhen soll?

(Ja, die Spezifikation muss natürlich weiterhin von einem Menschen geschrieben werden. Aber der muss sich dann nicht mit technisches Details auseinandersetzen.)

thread-leser schrieb:

Weisst du überhaupt noch, wofür du eigentlich argumentierst? Du meintest, dass es eine strikte Trennung für Systemprogrammiersprachen gibt und darüber diskutieren wir. Keiner von uns will die Steuereinheit in den ICEs mit PHP programmiert sehen.

Exakt, deswegen brauchst du keine neuen Sprachen mit völlig neuen VM erfinden, denn das ist nicht das Thema.
Es hieß, geht Java, Javascript oder C# und was kann man nehmen, von dem bestehenden was der Markt bietet.

Und zum Thema PHP, Javascript wurde ja von euch schon ins Feld geführt.

Deine Argumente:
[list][*] Laut Definition keine VM oder APIs => Ist aber deine eigene Definition

Ich habe APIs nicht generell ausgeschlossen, auch C hat eine Standard API.
Sondern ich sagte damit, daß bestehende APIs für so kleine HW fettes Zeugs sind deren Kontrolle oft in Dritter Hand liegt und man es deswegen besser nicht nutzt.

Und bei der VM muß man sich gänzlich auf die VM verlassen, die ebenfalls aus Dritter Hand ist. Die JVM von Sun ist für AKWs darüberhinaus nicht zugelassen, auch das habe ich bereits gesagt und trotzdem wollt ihr Raumsonden mit Java und einer JVM von Sun ausstatten und das ist eben ein Griff ins Klo, aber auch das sagte ich bereits.

[*] Man muss den AVX-Befehlssatz einbetten können => Da gibt C/C++/D auch nichts vor

Wie ich bereits schrieb, von C/C++/D kannst du sehr einfach auf bestehenden Objektcode zugreifen.

Java dagegen kennt nur Bytecode und braucht wieder das JNI und die Stütze von C/C++/D um auszubrechen.

[*] Vollständig bewiesene Fehlerfreiheit muss möglich sein => Kann man für alle "deterministischen" Sprachen oder für keine

Alles Theorie, Fakt ist, daß du es für die JVM von Sun nicht machst.
Ja du machst es auch nicht für den Javascript Interpreter von Firefox oder die .Net RE von MS.

C++ und D kann ich bereits schon JETZT für die HW nutzen.

[*] Harte Echtzeitfähigkeit => Wenn für C möglich, dann auch für C, das in einer VM, die in C geschrieben ist, läuft

Eine VM die speziell darauf angepaßt ist, ja vielleicht, aber das ist doch gar nicht das Theme, denn du behauptest doch, daß die JVM von Sun oder das .Net RE bereits genügt.

[*] 35 Jahre Laufzeitgarantie lassen sich mit Assembler aber nicht mit VM garantieren => Wenn du die VM in selber Qualität in Assembler programmierst und die Anwendungslogik in irgendeiner Skriptsprache mit selbiger Codequalität, nimmt sich das nichts

Noch einmal.
Ihr habt gesagt, daß man Java mit der JVM von Sun nehmen kann.
Ich habe gesagt, das ist nicht der Fall und jetzt kommst du mit einer aus der Luft gegriffenen neuen Sprache und VM.

Daher schließe ich nun aus deiner Antwort, daß du hiermit zu gibst, das man Java und C# nicht nehmen kann.
Es hat lange gebraucht, bis du mir endlich zustimmst.