Womit programmiert die NASA

pale dog

Bashar schrieb:

Ob das Produkt absturzgefährdet ist oder nicht hängt in erster Linie davon ab, ob die Sprache unsichere Konstrukte anbietet und ob der Programmierer diese benutzt.

stimmt, das ist viel entscheidender als VM oder nicht-VM.
daher ist ja auch z.b. ADA in sicherheitskritischen bereichen so beliebt.

KasF schrieb:

Als ich Praktikum beim DLR gemacht habe, war die Satellitensoftware in C programmiert.

vielleicht war's ja kein handgefrickelter C-code, sondern irgendwas generiertes?

Handgefrickelter C-Code

Erhard Henkes

DLR hat auch den ASURO erfunden, und der werkelt ja auch munter in C.
http://www.henkessoft.de/Roboter/ASURO.htm

pale dog

Erhard Henkes schrieb:

DLR hat auch den ASURO erfunden, und der werkelt ja auch munter in C.

wen wundert es?
es gibt nun mal keinen ersatz für C

Erhard Henkes

... wen wundert es? es gibt nun mal keinen ersatz für C

C wird durch die zunehmende Bedeutung der Microcontroller sogar immer wichtiger. Atmel's µC wurden sogar während der Hardwareentwicklung auf die Programmierung mit C optimiert. Da Microcontroller ideale Schnittstellen zwischen Sensoren/Aktoren und einem Computer-Mainboard sind, kann C und Assembler (oder beides ineinander gemischt) in solchen Systemen eine bedeutende Rolle spielen. C++ wird für Microcontroller selten verwendet (Fehleranfälligkeit, bestehende Einschränkungen).

GNU avr-gcc: http://www.avrfreaks.net/index.php?module=FreaksTools&func=viewItem&item_id=145
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial

mastercpp

Erhard Henkes schrieb:

C++ wird für Microcontroller selten verwendet (Fehleranfälligkeit, bestehende Einschränkungen).

Wenn man auf RTTI, Exceptiones und dynamischen Speicher verzichtet, lassen sich µC wunderbar in C++ programmieren und das heute gar nicht mal mehr so selten. Mit namespaces und statischen Klassen lässt sich der Code wunderbar strukturieren, lesbarer und damit weniger fehleranfällig machen. Und templates sind entgegen der Meinung vieler µC-C-Programmieren sehr gut für µC geeignet, da nur der Code compiliert wird, der auch wirklich benötigt wird.

pale dog

mastercpp schrieb:

[
Mit namespaces und statischen Klassen lässt sich der Code wunderbar strukturieren, lesbarer und damit weniger fehleranfällig machen.

geht auch mit 'struct' in C

mastercpp schrieb:

[
Und templates sind entgegen der Meinung vieler µC-C-Programmieren sehr gut für µC geeignet, da nur der Code compiliert wird, der auch wirklich benötigt wird.

...aber bei jeder instanziierung

Mr. N

pale dog schrieb:

...aber bei jeder instanziierung

Was stört dich?

mastercpp

pale dog schrieb:

mastercpp schrieb:

Mit namespaces und statischen Klassen lässt sich der Code wunderbar strukturieren, lesbarer und damit weniger fehleranfällig machen.

geht auch mit 'struct' in C

Aber nur sehr beschränkt. Folgendes geht z.B. in C nicht:

usart0::set_mode(usart0::uart, 9600, 8, 0, 1);

Man kann in C keine Memberfunktionen in structs packen

pale dog schrieb:

mastercpp schrieb:

Und templates sind entgegen der Meinung vieler µC-C-Programmieren sehr gut für µC geeignet, da nur der Code compiliert wird, der auch wirklich benötigt wird.

...aber bei jeder instanziierung

Nur einmal pro Datentyp..

pale dog

mastercpp schrieb:

pale dog schrieb:

mastercpp schrieb:

Mit namespaces und statischen Klassen lässt sich der Code wunderbar strukturieren, lesbarer und damit weniger fehleranfällig machen.

geht auch mit 'struct' in C

Aber nur sehr beschränkt. Folgendes geht z.B. in C nicht:
usart0::set_mode(usart0::uart, 9600, 8, 0, 1);
Man kann in C keine Memberfunktionen in structs packen

muss man ja nicht, in C:

USARTsetmode (usart, mode, 9600, 8, 0, 1);

wobei 'usart' ein pointer auf die register des gemeinten USART ist

mastercpp schrieb:

pale dog schrieb:

mastercpp schrieb:

Und templates sind entgegen der Meinung vieler µC-C-Programmieren sehr gut für µC geeignet, da nur der Code compiliert wird, der auch wirklich benötigt wird.

...aber bei jeder instanziierung

Nur einmal pro Datentyp..

nicht pro vorkommen im quellcode? wenn man ein z.b. ein function template instanziiert, packt man sich doch immer unüberschaubar viel code an diese stelle. so wie ein zwangs-inline...

rüdiger

pale dog, es lohnt sich eh nicht mit dir darüber zu diskutieren. Aber Templates sind sicher kein unkontrolierbareres Feature, als andere auch. Das man für zwei verschiedene Typen den Code doppelt hat (was so auch nicht stimmt, da nur Code angelegt werden muss der wirklich genutzt wird), hättest du ja auch wenn du den Code händisch für zwei Typen anlegst. Wie gesagt: Bei Templates kann der Compiler ohne Probleme toten Code aufräumen und ist viel freier in der Optimierung.

Aber egal was wir für Argumente bringen werden, wirst du es eh nicht einsehen wollen und auf C beharren. Meinetwegen mach das. Aber wie gesagt, es gibt Firmen die auf C++ für µC setzen und das sind zum Teil Industriegrößen. zB schreibt Lockheed Martin die Software für ihre Kampfflugzeuge mit C++ und ich glaube nicht, dass die total ahnungslose ineffiziente Deppen sind... Im Gegenteil glaube ich eher das dort ein haufen ziemlich kompetenter Ingenieure arbeitet, die sich nicht so leicht scheiß andrehen lassen...

Fye

pale dog schrieb:

mastercpp schrieb:

pale dog schrieb:

mastercpp schrieb:

Und templates sind entgegen der Meinung vieler µC-C-Programmieren sehr gut für µC geeignet, da nur der Code compiliert wird, der auch wirklich benötigt wird.

...aber bei jeder instanziierung

Nur einmal pro Datentyp..

nicht pro vorkommen im quellcode? wenn man ein z.b. ein function template instanziiert, packt man sich doch immer unüberschaubar viel code an diese stelle. so wie ein zwangs-inline...

Da wird nichts inlined:

template<typename T> T add(T a, T b)
{
  return a + b;
}

int main()
{
  return add(add(3, 5), add(5, 7));
}

a.out:     file format elf32-msp430

Disassembly of section .text:

[...]	

0000fc40 <main>:
  return a + b;
}

int main()
{
    fc40:	31 40 80 02 	mov	#640,	r1	;#0x0280
    fc44:	04 41       	mov	r1,	r4	;
  return add(add(3, 5), add(5, 7));
    fc46:	3e 40 07 00 	mov	#7,	r14	;#0x0007
    fc4a:	3f 40 05 00 	mov	#5,	r15	;#0x0005
    fc4e:	b0 12 6a fc 	call	#-918		;#0xfc6a
    fc52:	0b 4f       	mov	r15,	r11	;
    fc54:	3e 40 05 00 	mov	#5,	r14	;#0x0005
    fc58:	3f 40 03 00 	mov	#3,	r15	;#0x0003
    fc5c:	b0 12 6a fc 	call	#-918		;#0xfc6a
    fc60:	0e 4b       	mov	r11,	r14	;
    fc62:	b0 12 6a fc 	call	#-918		;#0xfc6a
}
    fc66:	30 40 8e fc 	br	#0xfc8e		;

0000fc6a <_Z3addIiET_S0_S0_>:
    fc6a:	05 12       	push	r5		;
    fc6c:	04 12       	push	r4		;
    fc6e:	05 41       	mov	r1,	r5	;
    fc70:	35 50 06 00 	add	#6,	r5	;#0x0006
    fc74:	21 82       	sub	#4,	r1	;r2 As==10
    fc76:	04 41       	mov	r1,	r4	;
    fc78:	84 4f 00 00 	mov	r15,	0(r4)	;
    fc7c:	84 4e 02 00 	mov	r14,	2(r4)	;
    fc80:	2f 44       	mov	@r4,	r15	;
    fc82:	1f 54 02 00 	add	2(r4),	r15	;
    fc86:	21 52       	add	#4,	r1	;r2 As==10
    fc88:	34 41       	pop	r4		;
    fc8a:	35 41       	pop	r5		;
    fc8c:	30 41       	ret			

[...]

:p

Mr. N

$ g++ -O3 -S -o - -x c++ - <<EOC
> template<typename T> T add(T a, T b) 
> { 
>   return a + b; 
> } 
> 
> int main() 
> { 
>   return add(add(3, 5), add(5, 7)); 
> }
> EOC
        .file   ""
        .text
        .align 2
        .p2align 4,,15
.globl main
        .type   main, @function
main:
.LFB3:
        movl    $20, %eax
        ret
.LFE3:
        .size   main, .-main
.globl __gxx_personality_v0
        .section        .eh_frame,"a",@progbits
.Lframe1:
        .long   .LECIE1-.LSCIE1
.LSCIE1:
        .long   0x0
        .byte   0x1
        .string "zPR"
        .uleb128 0x1
        .sleb128 -8
        .byte   0x10
        .uleb128 0x6
        .byte   0x3
        .long   __gxx_personality_v0
        .byte   0x3
        .byte   0xc
        .uleb128 0x7
        .uleb128 0x8
        .byte   0x90
        .uleb128 0x1
        .align 8
.LECIE1:
.LSFDE1:
        .long   .LEFDE1-.LASFDE1
.LASFDE1:
        .long   .LASFDE1-.Lframe1
        .long   .LFB3
        .long   .LFE3-.LFB3
        .uleb128 0x0
        .align 8
.LEFDE1:
        .ident  "GCC: (GNU) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)"
        .section        .note.GNU-stack,"",@progbits

Nochmal:

main:
.LFB3:
        movl    $20, %eax
        ret

oder in Intel-Syntax:

mov eax, 20
ret

Du musst nur Optimierung anstellen.

Fye

Mr. N schrieb:

Du musst nur Optimierung anstellen.

Cheater!

Nee, mal im Ernst: Klar, dass bei -O3 ge-inlined wird. Durch Wegfall des call/ret und dem stack-kram ist das ganze natürlich schneller:

0000fc40 <main>:
  return a + b;
}

int main()
{
    fc40:	31 40 80 02 	mov	#640,	r1	;#0x0280
  return add(add(3, 5), add(5, 7));
}
    fc44:	3f 40 14 00 	mov	#20,	r15	;#0x0014
    fc48:	30 40 4c fc 	br	#0xfc4c		;

Aber wenn man Wert darauf legt, dass nicht tonnenweise Code ge-inlined wird, kopiliert man natürlich mit -Os!

0000fc40 <main>:
  return a + b;
}

int main()
{
    fc40:	31 40 80 02 	mov	#640,	r1	;#0x0280
  return add(add(3, 5), add(5, 7));
    fc44:	3e 40 07 00 	mov	#7,	r14	;#0x0007
    fc48:	3f 40 05 00 	mov	#5,	r15	;#0x0005
    fc4c:	b0 12 68 fc 	call	#-920		;#0xfc68
    fc50:	0b 4f       	mov	r15,	r11	;
    fc52:	3e 40 05 00 	mov	#5,	r14	;#0x0005
    fc56:	3f 40 03 00 	mov	#3,	r15	;#0x0003
    fc5a:	b0 12 68 fc 	call	#-920		;#0xfc68
    fc5e:	0e 4b       	mov	r11,	r14	;
    fc60:	b0 12 68 fc 	call	#-920		;#0xfc68
}
    fc64:	30 40 6c fc 	br	#0xfc6c		;

0000fc68 <_Z3addIiET_S0_S0_>:
    fc68:	0f 5e       	add	r14,	r15	;
    fc6a:	30 41       	ret

Mr. N

Fye schrieb:

Aber wenn man Wert darauf legt, dass nicht tonnenweise Code ge-inlined wird, kopiliert man natürlich mit -Os!

Ich will aber, dass tonnenweise Code ge-inlined wird.

Sonst wäre mein Programmierstil untragbar.

Artchi

Ich hatte ja auch mal eine Bericht gepostet, wo "BMW CarIT" über den Einsatz von C++ im CAN-Bus geschrieben hat. Hat pale dog auch als "Unsinn" abgetan. pale dog braucht man nicht ernst nehmen... weil er alle anderen für Idioten hält, selbst wenn es große bekannte Firmen sind.

Paddy82

Ich arbeite in einem großen Rüstungsunternehmen.

Bei uns nutzen wir sowohl C, C++, Ada und auch (sehr sehr selten) C#. Kommt immer auf die Projekte an.

Ich glaube, dass die NASA auch nur mit Wasser kocht und dass es ganz normale Ingenieure und Entwickler sind, die nur entsprechend viel Geld in ihren Projekten zur Verfügung gestellt bekommen um sehr viel zu testen. Unsere Flugsysteme werden ebenfalls sehr viel getestet und haben dementsprechend wenig Fehler.

Auch das CERN entwickelt mit C++ (die haben doch irgend so einen open source C++ interpreter rausgebracht). Bei CERN sehe ich mehr Know How und Kompetenzen als bei der NASA.

Ich denke, dass es total egal ist, ob man nun mit C, C++ oder Ada programmiert. Die Hauptsache ist, dass genügend Geld zum Testen und Entwickeln da ist.

Dass bei der Microcontrollerprogrammierung nicht auf C#, Java oder eine andere interpretierte Sprache gesetzt wird, wird hier doch allen genauso klar sein, wie dass in den meisten Bereichen des Shuttle kein Windows Xp laufen wird.

Gruß Paddy

Artchi schrieb:

Ich hatte ja auch mal eine Bericht gepostet, wo "BMW CarIT" über den Einsatz von C++ im CAN-Bus geschrieben hat. Hat pale dog auch als "Unsinn" abgetan. pale dog braucht man nicht ernst nehmen... weil er alle anderen für Idioten hält, selbst wenn es große bekannte Firmen sind.

Du bleibst es aber bis heute schuldig mir den großen Sinn hinter dem Artikel zu nennen. Gebetsmühlenartiges Wiederholen der Existenz dieses Artikels bringts nicht. Dass es prinzipielll geht wundert niemand. So what?

pale dog

rüdiger schrieb:

Aber egal was wir für Argumente bringen werden, wirst du es eh nicht einsehen wollen und auf C beharren. Meinetwegen mach das. Aber wie gesagt, es gibt Firmen die auf C++ für µC setzen und das sind zum Teil Industriegrößen. zB schreibt Lockheed Martin die Software für ihre Kampfflugzeuge mit C++ und ich glaube nicht, dass die total ahnungslose ineffiziente Deppen sind... Im Gegenteil glaube ich eher das dort ein haufen ziemlich kompetenter Ingenieure arbeitet, die sich nicht so leicht scheiß andrehen lassen...

naja, wir wissen nicht, was sie dazu bewogen hat auf C++ zu setzen, aber wir sollten mal davon ausgehen, dass sie auch wissen, dass es sowas wie ADA gibt.
wenn's um 'bugfestigkeit' geht, beharre ich übrigens nicht auf C. beide, C und C++ sind in dieser hinsicht nicht das gelbe vom ei
ich glaube allerdings kaum, dass lockheed C++ in kritischen bereichen einsetzt, in denen programmierfehler menschenleben kosten können. wenn doch, dann sind es wirklich deppen oder sie treiben einen irren aufwand, um fehler im vorfeld auszuschliessen.

@templates:
optimierung ist fein, aber C compiler für µC optimieren ohnehin sehr aggressiv d.h. ein codewarrior z.b. hätte genau das gleiche getan mit eurer 'add'-funktion, nämlich einen konstanten wert eingesetzt und fertich
aber es gibt auch template-funktionen, für die ein compiler handfesten code erzeugen *muss*, weil erst zur laufzeit verschiedene bedingungen auftreten können und diesen code erzeugt er ja wohl immer, wenn das template instanziiert wird, oder liege ich da falsch?

btw: ich find templates übrigens gut. in C benutze ich oft #defines und manchmal wünsche ich mir, dass die so mächtig wie templates wären...

Tim schrieb:

Artchi schrieb:

Ich hatte ja auch mal eine Bericht gepostet, wo "BMW CarIT" über den Einsatz von C++ im CAN-Bus geschrieben hat. Hat pale dog auch als "Unsinn" abgetan. pale dog braucht man nicht ernst nehmen... weil er alle anderen für Idioten hält, selbst wenn es große bekannte Firmen sind.

Du bleibst es aber bis heute schuldig mir den großen Sinn hinter dem Artikel zu nennen.

einfach nur werbung, public relations. die firmen wollen damit zeigen, was sie für tolle entwicklungsmannschaften mit viel know-how haben.

Mr. N

pale dog schrieb:

@templates:
optimierung ist fein, aber C compiler für µC optimieren ohnehin sehr aggressiv d.h. ein codewarrior z.b. hätte genau das gleiche getan mit eurer 'add'-funktion, nämlich einen konstanten wert eingesetzt und fertich

Es geht darum, dass Templates die Optimierung nicht verhindern.

pale dog schrieb:

aber es gibt auch template-funktionen, für die ein compiler handfesten code erzeugen *muss*, weil erst zur laufzeit verschiedene bedingungen auftreten können und diesen code erzeugt er ja wohl immer, wenn das template instanziiert wird, oder liege ich da falsch?

Und wo wird da bitte mehr Code erzeugt als im Nicht-Template-Fall?

pale dog schrieb:

btw: ich find templates übrigens gut. in C benutze ich oft #defines und manchmal wünsche ich mir, dass die so mächtig wie templates wären...

Wenn du kein C++ einsetzen kannst, ist das wohl Pech.