Hallo,
in einer Applikation erhalte ich über den CAN-Bus ein Datenpacket von
256 Bytes. Sobald die Daten auf dem Mikrocontroller anliegen wird die
CallBack Funktion "DataRecv" ausgeführt. Nun möchte ich die empfangenen
Daten "Data" der Funktion "FlashWritePage" übergeben. Wie müsste ich die
Übergabe von Data realisieren ? Mit *Data funktioniert dies nicht.
Techniker schrieb:> Mit *Data funktioniert dies nicht.
Data ist doch schon ein Pointer. Du uebergibst bei dir die Addresse auf
einem Pointer.
Einfach so:
FlashWritePage(Data);
guennie schrieb im Beitrag #2856234:
> Würdest Du statt des C-Gefrickels eine richtige Programmiersprache> verwenden, sollte sich die geschilderte Frage nicht stellen.
Hast du noch weitere derart hilfreiche Antworten parat?
Falls ja: behalt' selbige bitte für dich. Außer dir benötigt sie keiner.
Helmut Lenzen schrieb:> Du uebergibst bei dir die Addresse auf> einem Pointer.
Meinte den Wert wo der Pointer draufzeigt.
guennie schrieb im Beitrag #2856234:
> Würdest Du statt des C-Gefrickels eine richtige Programmiersprache> verwenden, sollte sich die geschilderte Frage nicht stellen.
C ist eine Richtige Programmiersprache.
guennie schrieb im Beitrag #2856234:
> Datenpaket mit 256 Bytes?Ein CAN-Frame bietet Platz für 8 Bytes.
Vielleicht wird zuerst gebuffert oder was weiß ich.
> Würdest Du statt des C-Gefrickels eine richtige Programmiersprache> verwenden, sollte sich die geschilderte Frage nicht stellen.
C-Bashing? GäähhnTechniker schrieb:> Nun möchte ich die empfangenen> Daten "Data" der Funktion "FlashWritePage" übergeben. Wie müsste ich die> Übergabe von Data realisieren ? Mit *Data funktioniert dies nicht.
Hierzu sollte dir klar sein, dass in C ein Array schon ein Pointer auf
das erste Element (Data[0]) ist.
Schreibst du z.B. Data[1] behandelt dein Compiler das wie ein
*(Data+sizeof(char)).
Dominik S. schrieb:> Hierzu sollte dir klar sein, dass in C ein Array schon ein Pointer auf> das erste Element (Data[0]) ist.
Jein. Ein Array ist natürlich schon ein Array, aber sowie man
den Namen eines Arrays ohne Dereferenzierungsoperator ("[...]")
benutzt, wird der Zeiger auf den Anfang gebildet. Gleiches für
das Nennen einer Funktion ohne die runden Klammern.
>void DataRecv (char Data[Len], int* pLen)>{> FlashWritePage(*Data);>}
Die Funktion muesste eigentlich so definiert sein:
1
voidDataRecv(charData[],int*pLen)
2
{
3
FlashWritePage(Data);
4
}
Dann ist Data ein Pointer bzw. ein Element eines
Arrays, was ja auch nur ein Pointer ist.
Allerdings wird dir der C Compiler wohl ein
paar Warnungen um die Ohren hauen.
Ralf
guennie schrieb im Beitrag #2856622:
> es gibt keine> auch nur halbwegs brauchbare Stringverarbeitung
Genau, das ist gerade in Assembler viel besser.
Du, troll Dich einfach woanders.
guennie schrieb im Beitrag #2856622:
> Der Guenni programmiert in Assembler und umgeht damit den Schwachsinn,> den die bastel- und frickel-Compiler liefern.
Aha du schreibst also Programme mit 100000 Zeilen Code in Assembler
fehlerfrei?
guennie schrieb im Beitrag #2856622:
> häufig benötigte Zeichen sind auf> Tastaturen mit deutschem Layout besch...en zu erreichen,
Dann kauf dir eine US Tastatur. So teuer sind die nicht.
guennie schrieb im Beitrag #2856622:
> Wer> darauf angewiesen ist, mit seinen Produkten Geld zu verdienen bzw. diese> in sicherheitskritischen Bereichen einsetzt und nicht auf> hobby-frickler-Niveau herumlaboriert, wird den Quatsch meiden wie der> "Teufel das Weihwasser"!
Und wann wirst du mit deinen riesen Assemblerprogrammen fertig? Dann
wenn die Hardware schon laengst im Museum steht?
guennie schrieb im Beitrag #2856622:
> Der Sprachkonstrukt ist inhärent> fehleranfällig
Noe. Das trifft eher auf Assembler zu.
Müll von "guenni" entsorgt. Wer so eklatant gegen Forenregeln verstößt,
darf nicht damit rechnen, daß seine Absonderungen nicht entsorgt werden.
Nein, dieses Forum ist keine Provokationsplattform.
Helmut Lenzen schrieb:> guennie schrieb im Beitrag #2856622:>> Der Guenni programmiert in Assembler und umgeht damit den Schwachsinn,>> den die bastel- und frickel-Compiler liefern.>> Aha du schreibst also Programme mit 100000 Zeilen Code in Assembler> fehlerfrei?>
Nein. 180000 Zeilen. Läuft seit 1994 in einer Anlagensteuerung.
Unterbrechung bisher nur durch Stromausfall bzw. Wartungsarbeiten.
> guennie schrieb im Beitrag #2856622:>> häufig benötigte Zeichen sind auf>> Tastaturen mit deutschem Layout besch...en zu erreichen,>> Dann kauf dir eine US Tastatur. So teuer sind die nicht.
Wozu? Ich "programmiere" nicht mit dem Mist.
>> guennie schrieb im Beitrag #2856622:>> Wer>> darauf angewiesen ist, mit seinen Produkten Geld zu verdienen bzw. diese>> in sicherheitskritischen Bereichen einsetzt und nicht auf>> hobby-frickler-Niveau herumlaboriert, wird den Quatsch meiden wie der>> "Teufel das Weihwasser"!>> Und wann wirst du mit deinen riesen Assemblerprogrammen fertig? Dann> wenn die Hardware schon laengst im Museum steht?
Nein. Im laufe der Zeit sammeln sich Funktionen bzw. Prozeduren an,
welche mann problemlos in Bibliotheken sammeln kann...
>> guennie schrieb im Beitrag #2856622:>> Der Sprachkonstrukt ist inhärent>> fehleranfällig>> Noe. Das trifft eher auf Assembler zu.
Erneut unfug. Jeder Befehl ist eindeutig und wird 1:1 umgesetzt. Kein
"Kaputt-Optimieren" durch den Compiler...
Rufus Τ. Firefly schrieb:> Müll von "guenni" entsorgt. Wer so eklatant gegen Forenregeln verstößt,> darf nicht damit rechnen, daß seine Absonderungen nicht entsorgt werden.>> Nein, dieses Forum ist keine Provokationsplattform.
Spielverderber.
Helmut Lenzen schrieb:>> häufig benötigte Zeichen sind auf>> Tastaturen mit deutschem Layout besch...en zu erreichen,>> Dann kauf dir eine US Tastatur.
Was ich nun seit 22 Jahren mache: die Tasten ÄÖÜ liefern ohne
weitere Umschaltungen die Zeichen [\], mit Shift dann {|}, und
erst zusammen mit AltGr die Umlaute. Auch wenn das nicht der
Reinen Schreibmaschinenlehre[TM] entspricht :), die AltGr-Taste
lässt sich prima gemeinsam mit diesen Tasten drücken.
Auf diese Weise habe ich beide Welten bequem zur Hand: die fürs
Programmieren wichtigen Klammern und die deutschen Umlaute, damit
meine Mitmenschen meinen Text auch flüssig lesen können.
Solange man nicht in APL programmieren will, ist das alles kein
Problem.
guennie schrieb:> Nein. 180000 Zeilen. Läuft seit 1994 in einer Anlagensteuerung.> Unterbrechung bisher nur durch Stromausfall bzw. Wartungsarbeiten.
Und was machst du wenn die Hardware in die Jahre kommt und es keine
Ersatzteile mehr gibt?
guennie schrieb:> Erneut unfug. Jeder Befehl ist eindeutig und wird 1:1 umgesetzt. Kein> "Kaputt-Optimieren" durch den Compiler...
Warum sollte der Compiler was kaputt optimieren?
@guenni, egbert oder wie immer du dich morgen nennen magst:
Den einzigen Nachteil von C sehe ich darin, dass diese Sprache es dir
ermöglicht, deine seltsamen Ansichten hier zu eröffentlichen.
In welcher Sprache ist wohl der Web-Browser geschrieben, den du zum
Posten benutzt?
In welcher Sprache ist wohl das Betriebssystem geschrieben, auf dem dein
Web-Browser läuft?
In welcher Sprache ist wohl der Web-Server geschrieben, mit dem sich
dein Web-Browser verbindet?
Glaubst du im Ernst, die Informationstechnik hätte sich so rasant bis
zum heutigen Stand entwickeln können, wenn sämtliche Software immer noch
in Assembler geschrieben würde?
Assembler programmiert man heute zu 99% nicht mehr selber, sondern
lässt programmieren, nämlich den Compiler.
guennie schrieb:> 180000 Zeilen.
In C wären es höchtens 9000 gewesen.
Helmut Lenzen schrieb:> guennie schrieb:>> Nein. 180000 Zeilen. Läuft seit 1994 in einer Anlagensteuerung.>> Unterbrechung bisher nur durch Stromausfall bzw. Wartungsarbeiten.>> Und was machst du wenn die Hardware in die Jahre kommt und es keine> Ersatzteile mehr gibt?>
Solange noch irgendwo ein funktionsfähiger 80x86 aufzutreiben ist, sehe
ich da keine Probleme... Und da ich für das Unternehmen nicht mehr tätig
bin...
> guennie schrieb:>> Erneut unfug. Jeder Befehl ist eindeutig und wird 1:1 umgesetzt. Kein>> "Kaputt-Optimieren" durch den Compiler...>> Warum sollte der Compiler was kaputt optimieren?
Aus eigener Erfahrung mit den verschiedenen C-Compiler für
Mikrochip-Produkte kann ich ein langes Klagelied auf z.B. die
unterschiedlich Behandlung von Arrays in MPLAB-C und C18 singen... Der
C18 hat die Eigenart, zwar Indizies größer als 255 zuzulassen, jedoch
nur auf die ersten 256 Byte-Elemente zugreifen zu können... Stundenlange
Fehlersuche - wo? Na klar, im erzeugten Assembler-Listing. Dann kann
ich's auch gleich in Assembler schreiben!
Und: Eine "Programmiersprache", die sowas hier ernsthaft zulässt:
inv v,i,j,k,l,s,a[99];
main ()
{for(scanf("%d",&s);*a-s;v=a[j*=v]-a[i],k=i<s,j+=(v=j<s&&(!k&&!!printf(2
+"\n\n%c"-(!1<<!j),"
#x"[1^v=(1^j)&1:2])&&++1||a[i]<s&&v&&v-i+j&&v+i-j))&&!(1%=s),v||(i==j?a[
i+=k]=0:++a[i])>=s*k&&++a[--i]);}
Kann nicht ernst gemeint sein.
Helmut Lenzen schrieb:> guennie schrieb:>> Erneut unfug. Jeder Befehl ist eindeutig und wird 1:1 umgesetzt. Kein>> "Kaputt-Optimieren" durch den Compiler...>> Warum sollte der Compiler was kaputt optimieren?
Vielleicht weil/wenn man als Anwender unfähig ist ihn richtig zu
benutzen? duckundweg
Helmut Lenzen (helmi1) schrieb:
guennie schrieb:
>> Nein. 180000 Zeilen. Läuft seit 1994 in einer Anlagensteuerung.>> Unterbrechung bisher nur durch Stromausfall bzw. Wartungsarbeiten.> Und was machst du wenn die Hardware in die Jahre kommt und es keine> Ersatzteile mehr gibt?
Und was macht das "180.000 Zeilen Projekt" erst wenn Wartende mal
vorzeitig aus dem Leben scheidet? Die Hinterlassenschaft soll wohl der
Nachwuchs dann am Leben halten? Der wird "sich freuen". In diesem
Zusammenhang einfach mal an Dirk Bach denken ..
Yalu X. schrieb:> @guenni, egbert oder wie immer du dich morgen nennen magst:>> Den einzigen Nachteil von C sehe ich darin, dass diese Sprache es dir> ermöglicht, deine seltsamen Ansichten hier zu eröffentlichen.>> In welcher Sprache ist wohl der Web-Browser geschrieben, den du zum> Posten benutzt?>> In welcher Sprache ist wohl das Betriebssystem geschrieben, auf dem dein> Web-Browser läuft?>> In welcher Sprache ist wohl der Web-Server geschrieben, mit dem sich> dein Web-Browser verbindet?
Was tut das zur Sache?
> Glaubst du im Ernst, die Informationstechnik hätte sich so rasant bis> zum heutigen Stand entwickeln können, wenn sämtliche Software immer noch> in Assembler geschrieben würde?
Ja, mit Sicherheit sogar weiter und schneller. Dann hätten wir uns
nämlich nicht jahrelang mit nicht-funktionierender Bluescreen-Software
von Microsoft rumärgern müssen, mit Buffer-Overflows, u.s.w.
> Assembler programmiert man heute zu 99% nicht mehr selber, sondern> lässt programmieren, nämlich den Compiler.
In sicherheitskritischen Bereichen: NEIN.
>> guennie schrieb:>> 180000 Zeilen.>> In C wären es höchtens 9000 gewesen.
Auch hier: Sicherlich nicht, vielleicht 40.000. Aber 40.000
unverständliche und unübersichtliche Zeilen.
guennie schrieb:> Und: Eine "Programmiersprache", die sowas hier ernsthaft zulässt:>> ...>> Kann nicht ernst gemeint sein.
Aha, da sieht man mal, wieviel Ahnung du von C hast:
1
$ gcc -c guenni.c
2
guenni.c:1:1: error: unknown type name ‘inv’
3
guenni.c: In function ‘main’:
4
guenni.c:3:6: warning: incompatible implicit declaration of built-in function ‘scanf’ [enabled by default]
5
guenni.c:3:65: warning: incompatible implicit declaration of built-in function ‘printf’ [enabled by default]
6
guenni.c:4:20: warning: missing terminating " character [enabled by default]
7
guenni.c:4:1: error: missing terminating " character
Proxxon schrieb:> Helmut Lenzen (helmi1) schrieb:>> guennie schrieb:>>> Nein. 180000 Zeilen. Läuft seit 1994 in einer Anlagensteuerung.>>> Unterbrechung bisher nur durch Stromausfall bzw. Wartungsarbeiten.>>> Und was machst du wenn die Hardware in die Jahre kommt und es keine>> Ersatzteile mehr gibt?>> Und was macht das "180.000 Zeilen Projekt" erst wenn Wartende mal> vorzeitig aus dem Leben scheidet? Die Hinterlassenschaft soll wohl der> Nachwuchs dann am Leben halten? Der wird "sich freuen". In diesem> Zusammenhang einfach mal an Dirk Bach denken ..
Obsoleszens ist ein generelles Problem aller technischen
Errungenschaften. Die Wartungsarbeiten beziehen sich auf
elektromechanische Anlagenteile, nicht auf die Software. Da ich nicht
mehr für das Unternehmen tätig bin, stellt sich mir die Frage auch
nicht.
Yalu X. schrieb:> guennie schrieb:>> Und: Eine "Programmiersprache", die sowas hier ernsthaft zulässt:>>>> ...>>>> Kann nicht ernst gemeint sein.>> Aha, da sieht man mal, wieviel Ahnung du von C hast:>> ...> guenni.c:6:5: error: expected ‘)’ before ‘]’ token> guenni.c:6:5: error: expected ‘)’ before ‘]’ token> guenni.c:6:5: error: expected ‘)’ before ‘]’ token> guenni.c:6:5: error: expected ‘)’ before ‘]’ token> guenni.c:6:5: error: expected statement before ‘]’ token> guenni.c:6:6: error: expected expression before ‘=’ token> guenni.c:6:15: error: expected statement before ‘)’ token> guenni.c:6:16: error: expected expression before ‘>=’ token> guenni.c:6:31: error: expected statement before ‘)’ token>> :D
Aber, aber. Ich habe nie behauptet, tiefergehende Kenntnisse von C zu
haben, geschweige denn - solange mir nicht irgendetwas schweres auf den
Kopf fällt - mir ebendiese aneignen zu wollen.
Ich muss den Quatsch nicht verstehen, der Kompiler tut es offensichtlich
auch nicht; Die Fehlermeldungen sind wenig hilfreich und welche Funktion
das "Programm" - trotz des wohl tatsächlich vorhandenen
Übertragungsfehlers - aufweist, hat noch keiner herausbekommen.
guennie schrieb:> So, jetzt hat der Onkel Guenni aber noch wichtigere Dinge zu erledigen.
Das Assemblerprogramm fertig schreiben das er 1994 begonnen hat und
immer noch nicht fertig ist :=)
guennie schrieb:> Ja, mit Sicherheit sogar weiter und schneller. Dann hätten wir uns> nämlich nicht jahrelang mit nicht-funktionierender Bluescreen-Software> von Microsoft rumärgern müssen, mit Buffer-Overflows, u.s.w.
Jepp, dann wuerde der Computer sich noch so melden:
C:>
> Und was machst du wenn die Hardware in die Jahre kommt und es keine> Ersatzteile mehr gibt?
so ganz unrecht hat Günni nicht.
Die Hardware sollte abwärtskompatibel sein, dann ergibt sich kein
Problem bei Assembler.
Besser wie Assembler geht es nun mal nicht, dafür natürlich auch
komplizierter.
Alternativen wären ja auch noch Ada oder ein paar andere exotische
Sprachen.
Außerdem: Die Wiederverwendbarkeit von Code ist auch so eine Mär, wie
man ja beim Arieneabsturz mitbekommen haben sollte.
why not schrieb:> Außerdem: Die Wiederverwendbarkeit von Code ist auch so eine Mär, wie> man ja beim Arieneabsturz mitbekommen haben sollte.
Da war aber schon in der Originalsoftware ein Bug drin. Der ist bloss
nicht aufgefallen weil deren Wertebereich bei der 4 nicht ueberschritten
wurde.
Wenn man das Zeug nie richtig testet ...
why not schrieb:> Die Hardware sollte abwärtskompatibel sein, dann ergibt sich kein> Problem bei Assembler.
Dann sag das mal den Halbleiterherstellern. Wenn das Chip keinen Gewinn
mehr bringt wird es abgekuendigt. (65er,68000 etc) Mag zwar noch ein
paar Teile davon geben.
guennie schrieb:> Obsoleszens ist ein generelles Problem aller technischen> Errungenschaften. Die Wartungsarbeiten beziehen sich auf> elektromechanische Anlagenteile, nicht auf die Software. Da ich nicht> mehr für das Unternehmen tätig bin, stellt sich mir die Frage auch> nicht.
Ja das kennen wir schon.
Erst sein Softwaresystem möglichst exotisch aufbauen und dann: Hinter
mir die Sintflut. Soll sich doch wer anderer mit dem unwartbaren Kram
rumärgern.
guennie schrieb:> Aber, aber. Ich habe nie behauptet, tiefergehende Kenntnisse von C zu> haben
Warum nimmst du dir dann das Recht heraus, C Programme als Mist zu
bezeichnen?
Nur weil >>>DU<<< C nicht gut genug kannst um damit Projekte
abzuwickeln? Sorry, aber das ist kein Massstab. Andere können das
nämlich.
> Dann sag das mal den Halbleiterherstellern. Wenn das Chip keinen Gewinn> mehr bringt wird es abgekuendigt. (65er,68000 etc) Mag zwar noch ein> paar Teile davon geben.
jetzt haben wir aber im PC-Bereich eine Vereinheitlichung der Hardware,
nur noch Intel oder AMD und die gestalten Ihre CPUs ja auch
abwärtskompatibel.
Die Frage ist nur noch welche Programmier-Software sich langfristig
durchsetzen wird.
Reines Ansi C ist m.E. nicht schlecht, d.h. aber im Umkehrschluß
bedeutet das nicht auch noch neue Sprachen auf Assemblerbasis möglich
wären, die C Paroli bieten könnten. Ansätze sind ja da, aber gehen
leider unter, da C erst einmal geschlagen werden muß - C hat nun einmal
auch viele Tücken und deshalb gabs ja die angeblichen Verbesserungen C++
und C#
Zur Not reichen aber die Ursprachen (also Assembler) oder neuerdings
Basic-Derivate völlig aus (auch für Mikrocontroller-Programmierung,
sonst gäbe es kein Bascom-Basic, etc.).
Softwaremäßig gibt es noch keine Vereinheitlichung, alles ist noch
möglich.
why not schrieb:> Reines Ansi C ist m.E. nicht schlecht, d.h. aber im Umkehrschluß> bedeutet das nicht auch noch neue Sprachen auf Assemblerbasis möglich> wären, die C Paroli bieten könnten.
Du kannst es drehen und wenden wie du willst. Assembler ist im
industriellen Umfeld de facto tod. Zu fehleranfällig, zu langsam in der
Entwicklung. Und wenn du ein Team von Leuten hast, dann geht ohne
entsprechende Compilerunterstützung erst mal gar nichts. Sorry, aber
180000 Lines of Code ist für ein industrielles Projekt nicht wirklich
viel. Häng noch eine 0 an, und wir haben realistische Größen. Und ich
mein damit Hochsprachencode, nicht Assemblercode mit einer LOC Explosion
von 1:10 nach der Compilierung.
> Ansätze sind ja da,
So, welche denn?
> aber gehen> leider unter, da C erst einmal geschlagen werden muß
Nicht C ist zu schlagen. Der Wegfall der kleinen Fehlerquellen, mit
denen man sich als Assemblerprogrammierer rumschlagen muss ist es, der
einen zur Hochsprache treibt. Während ein Assembler Programmierer noch
seine Push und Pop zählt und versucht rauszukriegen, wo und wie er sich
wieder das Carry Flag zerschossen hat, unterhalten sich Hochsprachen
Programmierer lieber über den Aufbau von dynamischen Datenstrukturen.
Da hast du noch gar nicht die Stellen gefunden, an denen du bei der
indirekten Adressierung eingreifen musst, hab ich schon in eine Struktur
ein neues Member eingefügt und den Compiler über den Code gejagt um eine
Datenstruktur zu erweitern.
> - C hat nun einmal> auch viele Tücken und deshalb gabs ja die angeblichen Verbesserungen C++> und C#
JEDE Programmiersprache hat ihre Tücken. Wieviele kennst du denn? Ich
glaube ich lehn mich nicht zu weit aus dem Fenster wenn ich sage: die
meisten Profis hier kennen mehr Sprachen zumindest soweit, dass sie
darin programmieren können, als du überhaupt (oder guennie) kennst. Oder
hast du schon mal APL programmiert. Was ist mit LISP, Prolog, F#, ...
> Zur Not reichen aber die Ursprachen (also Assembler)
Assembler reicht schon lange nicht mehr. Die Anforderungen in der
Industrieprogrammierung haben sich geändert. Die 5% Laufzeitpenalty
interessieren heute keinen mehr, den man sich mit einer Hochsprache
einhandelt. Heutzutage sind Entwicklungskosten die treibende Kraft. Und
weitgehende Fehlerfreiheit von Anfang an. Bei beidem hat Assembler das
nachsehen. Nur darfst du das, was hier im Forum passiert nicht mit dem
da draussen verwechseln, was in den Firmen gemacht werden muss.
Hier sind Amateure am Werk (nicht negativ gemeint). Diejenigen, die hier
mit C Problemen aufschlagen (und vor allen Dingen mit welchen Problemen
sie aufschlagen), haben in der Industrieprogrammierung nichts verloren.
Dort muss man erst mal sein Handwerkszeug beherrschen, sonst bist du
schneller weg vom Fenster als du Muh sagen kannst.
troll schrieb:> Karl Heinz wie er leibt und lebt. :-)>> Trotzdem, ich mag Assembler (und C).
Ist ja auch nix dagegen einzuwenden.
Nur kriegt man große Projekte damit einfach nicht mehr gebacken. Nicht
mit einer vorgegebenen Menge Zeit und Geld.
Die Zeiten, in denen man ein Programm irgendwie zum Laufen bringen muss
und das reicht dann schon, sind lange vorbei. Hacker haben in der
Industrie einen schweren Stand.
guennie schrieb:>> Assembler programmiert man heute zu 99% nicht mehr selber, sondern>> lässt programmieren, nämlich den Compiler.>> In sicherheitskritischen Bereichen: NEIN.
Witzig, dass du das erwähnst. Assembler ist da eher hinderlich als
förderlich -- für formale Verifikation eignen sich Hochsprachen besser,
gerade wegen der höheren Abstraktionsebene. Da will man ja gerade weg
von der Hardwareebene und möglichst funktional beschreiben.
Dazu gibt es dann C-Compiler, die verifiziert sind, d.h. es ist
mathematisch bewiesen, dass das, was der Compiler ausspuckt, exakt die
Funktion erfüllt, die das Quellprogramm in Kombination mit der Semantik
von C vorschreibt.
Andererseits wird noch nicht einmal auf die Maschinensprache vertraut --
da wird auch verifiziert, dass ein Maschinenbefehl unter allem Umständen
und Randbedingungen (auch unter abnormalen Bedingungen!) das tut, was
für ihn dokumentiert ist, inklusive Zeitverhalten. Eine
rückwärtskompatible Architektur ist da irrelevant -- man denke da nur an
die Peinlichkeiten, die es über die Jahrzehnte in der x86-Architektur
gab, z.B. der FDIV-Bug, F00F, und andere. So einen unverifizierten
Prozessor würde man in wahrhaft sicherheitskritischen Bereichen niemals
einsetzen.
Zu den praktischen Aspekten von Hochsprachen hat Karl Heinz ja schon
genug gesagt.
Karl Heinz Buchegger schrieb:> Hacker haben in der> Industrie einen schweren Stand.
Ausser bei Siemens :p
Ne mal im Ernst, Sicherheit ist für Konzerne doch auch nur ein
Bilanzposten.
Regressforderungen =
Durchschnitts-Regresskosten mal Wahrscheinlichkeit für einen
Regressfall
Genau so viel wird in Sicherheitsmaßnahmen investiert. Ein
Betriebswirtschafter, der wesentlich davon abweicht (in beide
Richtungen) macht seinen Job nicht richtig. Traurig, aber wahr. Traurig
auch, dass er eher gefeuert wird, wenn er zu viel in Sicherheit
investiert, weil sich diese Kosten sofort zeigen, während man die
Verantwortung für zu wenig Sicherheit nach unten weitergeben kann.
Lustig, dass hier über Programmiersprachen statt über den
Code-Ausschnitt diskutiert wird.
Da gäbe es nämlich genug Diskussionspotential. Scheint nicht so, als
wüsste der TE so genau was er da eigentlich tut.
Jedenfalls ergeben sich eine ganze Menge Annahmen:
- die pagesize soll vermutlich 256 Byte sein
- pLen wird schon immer genau 256 Byte sein
- irgendein CAN-Layer kümmert sich scheinbar schon um das Zusammensetzen
der 256 Byte aus einzelnen CAN-Daten
- die Zielpage wird schon irgendwie vorher irgendwo initialisiert
- um das page erase kümmert sich schon jmd. anders vorher, bzw.
FlashWritePage selbst
void DataRecv (char Data[Len], int* pLen) { FlashWritePage(Data); }
klingt viel zu einfach als dass da nicht ein ungutes Gefühl bei mir
entstünde.
guennie schrieb:
>> Assembler programmiert man heute zu 99% nicht mehr selber, sondern>> lässt programmieren, nämlich den Compiler.>> In sicherheitskritischen Bereichen: NEIN.> Witzig, dass du das erwähnst. Assembler ist da eher hinderlich als> förderlich -- für formale Verifikation eignen sich Hochsprachen besser,> gerade wegen der höheren Abstraktionsebene.
wieso da hat er doch indiret recht - in sicherheitskritischen Bereichen
(Militär,u.a.) wird ADA verwandt ... deshalb ist diese Sprache auch
heute noch auf dem Markt.
zu Karl Heinz Buchegger Post sag ich nachher noch was.
> Lustig, dass hier über Programmiersprachen statt über den> Code-Ausschnitt diskutiert wird.
es ist eben nur ein Ausschnitt, dazu ist auch schon alles gesagt worden
... und mehr hat der TO offenbar nicht zu bieten, soll er seine
Hausaufgaben ruhig selber machen.
Why not schrieb:> guennie schrieb:>>> Assembler programmiert man heute zu 99% nicht mehr selber, sondern>>> lässt programmieren, nämlich den Compiler.>>>> In sicherheitskritischen Bereichen: NEIN.>>> Witzig, dass du das erwähnst. Assembler ist da eher hinderlich als>> förderlich -- für formale Verifikation eignen sich Hochsprachen besser,>> gerade wegen der höheren Abstraktionsebene.> wieso da hat er doch indiret recht - in sicherheitskritischen Bereichen> (Militär,u.a.) wird ADA verwandt ... deshalb ist diese Sprache auch> heute noch auf dem Markt.
Die aufgeworfene Argumentation war aber nicht
ADA oder C
sondern sie war
C oder Assembler.
Wobei hier (zugegebenermassen als künstlerische Freiheit aufgefasst) die
Erweiterung der Fragestellung zu "Hochsprache oder Assembler" vollzogen
wurde.
Ich kenn natürlich nicht alle sicherheitskritischen Projekte. Trotzdem
würde es mich dann doch sehr wundern, wenn irgendeines davon in den
letzten 10 Jahren (mit nennenswertem Umfang, also nicht unbedingt einen
Tiny13 der ein Relais schaltet) in Assembler realisiert worden wäre.
> Ich kenn natürlich nicht alle sicherheitskritischen Projekte.
wer kennt die schon, Insider werden auch nicht unbedingt auspacken.
Keiner weiß es, da Geheimhaltung herrscht.
Gerade in Sicherheitsbereichen halten sich Uralt-Programme sehr sehr
lange, weil Neuerungen aufgrund von Haftungsfragen 100% stimmen müssen,
d.h. es gibt dann keine komplette Neuentwicklung, sondern nur ein
kleines Update bevor nicht wirklich alles getestet wurde.
Typisches Beispiel, daß sich Tradition hält ist SPS - könnte man
komplett verbessern, aber zu wenig Nachfrage bzw. sicherheitstechnisch
viel zu bedenklich.
> Trotzdem> würde es mich dann doch sehr wundern, wenn irgendeines davon in den> letzten 10 Jahren (mit nennenswertem Umfang, also nicht unbedingt einen> Tiny13 der ein Relais schaltet) in Assembler realisiert worden wäre.
also ich kenne z.B. Pascalprogramme, da wurden dann einfach
Inline-Assemblerroutinen aufgerufen.
Das kann ich in C oder ADA auch machen.
Assembler ist die traditionelle Sprache und Dein Denkfehler ist, daß
jedes Gui, usw. unbedingt mit Assembler programmiert werden muß - nein,
das war nie Sinn und Zweck von Assembler und damals war die
Programmbedienbarkeit ohne Gui eben komplizierter für den Anwender bzw.
aufgrund der Rechenleistung auch nie angedacht.
Deswegen sind als erstes Interpreter und später Compilersprachen
entstanden, weil der Programmieraufwand für die ganzen Gadgets zu hoch
wurde und die Programmierung für die Einfach-Programmierer nicht
nachvollziehbar war.
Es spricht nichts dagegen, daß man sinnvollerweise den Weg der
Vereinfachung für den reinen Anwender bzw. überforderten Programmierer
wählt - denn Programmbedienung und Programmierung kostet Anlernzeit und
Zeit ist Geld.
Früher kam das fertige Programm aus einem Guß (von einem Programmierer)
und heute werden die Aufgaben aufgeteilt, Programmieren am Fließband
sozusagen - deshalb wohl auch der Hype zum Retrocomputing und
Exotensprachen.
Ich geb Dir recht, daß Assembler so gut wie tot ist. Andererseits
solltest Du bedenken, daß eine vernünftige Compilersprache nur aus
Assembler entstehen kann, alles anderes wird mit
Geschwindigkeitseinbußen erkauft.
Why not schrieb:> daß eine vernünftige Compilersprache nur aus Assembler entstehen kann,
Hä? Ich verstehe diesen Satz nicht. Compiler selbst sind in Hochsprache
(fast immer C) geschrieben, und das was der Compiler aus einem
Quellprogramm (C oder sonstewas) erzeugt ist "natürlich" irgendwas
assemblerisches ..
Was genau wolltest du aussagen?
> alles anderes wird mit Geschwindigkeitseinbußen erkauft.
selbst 50% Geschwindigkeits- und Codezunahme sind lächerlich im
Vergleich zu 500% Zunahme des Entwicklungsaufwands von was-auch-immer
(assembler vs. Hochsprache).
Pack einen 2. Speicherchip rein, takte dein Kram doppelt so schnell,
schon ist deine Einbuße hinfällig. Das skaliert wunderbar linear und
"kost nix"
Du wirst aber unwahrscheinlicherweise keine weitere Spezifikateure,
Entwickler, Koordinatoren nutzen wollen, welche dir deine
Entwicklungsaufgabe dann in Assembler auf mehr Köpfe verteilt lösen
sollen....
Why not schrieb:> Deswegen sind als erstes Interpreter und später Compilersprachen> entstanden, weil der Programmieraufwand für die ganzen Gadgets zu hoch> wurde und die Programmierung für die Einfach-Programmierer nicht> nachvollziehbar war.
Darf ich fragen, wie alt du bist und wie lange du schon programmierst?
Die ersten verbreiteten Compiler (und damit Hochsprachen) waren
ALOGOL
Fortran
Cobol
PL/1
und die Entwicklungszeit dieser Compiler war irgendwann in den
50-er/60-er Jahren des letzten Jahrhunderts. Entwickelt hat sich das
ganze aus der Erkentnis, dass die Makro-Fähigkeiten der Assembler
a) sowieso immer gleich benutzt werden
b) viele typischen Fehler nicht abfangen
Gefragt war also ein 'Sprachtypus' bei dem man weg kam, von den
typischen Assemblerspezifischen Problemen und Problemkreisen, die
hauptsächlich technischer Natur waren und mit dem eigentlich
algorithmisch zu lösendem Problem nichts zu tun haben. Mit Assembler war
in dieser Richtung Ende der Fahnenstange und man sah auch nicht, wie man
das erhalten könnte. Selbst die ausgefuchstesten Makro-Fähigkeiten
halfen nicht mehr weiter. Also lehnte man sich zurück, identifizierte
typische Programmstrukturen (die vielerorts schon lange mittels Makros
vereinheitlicht worden waren) und suchte nach Wegen, wie man die in
einer Sprache formalisieren könne. Und zwar ohne den ganzen Kleinkram
wie CPU-Flags, Stack, Registerklauberei oder Push/Pop Zählerei. Da diese
Themenkreise sowieso immer nach fixen Mustern abgehandelt wurden, konnte
man das genausogut auch der Maschine überantworten. Die machte dabei
wenigstens keine Fehler mehr, sobald das Basismuster erst mal stimmte.
Sobald man angefangen hat, Computer für mehr als nur Spielerein in einer
Uni zu benutzen, waren Compiler unumgänglich.
Und es gab zuerst Compiler und erst dann, viiiel später Interpreter.
"Einfach-Programmierer" gab es zum damaligen Zeitpunkt schon gleich gar
nicht. Da waren Spezialisten am Werk, die die ersten kommerziell
eingesetzten Programme schufen. - ausschliesslich Spezialisten. Die
Spezies der "Einfach-Programmierer" kam erst mit der Verbreitung der PC,
rund 30 bis 40 Jahre später, auf.
> Assembler ist die traditionelle Sprache und Dein Denkfehler ist,> daß jedes Gui, usw. unbedingt mit Assembler programmiert werden muß> - nein, das war nie Sinn und Zweck von Assembler und damals war die> Programmbedienbarkeit ohne Gui eben komplizierter für den Anwender> bzw. aufgrund der Rechenleistung auch nie angedacht.
Sorry. Wenn das jetzt brutal klingt.
Aber irgendwie hab ich den Eindruck, du weißt nicht wirklich wovon du
redest. Speziell auf dieser Ebene war Assembler noch nie ein Thema.
Ich war dabei! Ich bin in dieser Zeit groß geworden als die ersten Guis
auf den Markt kamen! Ich hab das alles aus erster Hand erlebt. Ich hab
die ersten Guis programmiert! Ich hab Betriebssystem-Code studiert und
analysiert! Direkt im Source Code. Von CP/M konnte man sich (über
Umwege) den Originalcode organisieren. Geschrieben in PL/M. GEM ..
geschrieben in C. Die ersten Apple GUI's (stark beeinflusst von der
allerersten GUI, die bei Xerox entstanden ist), geschrieben in C.
Assembler war in diesem Bereich nie auch nur das geringste Thema. Ausser
auf der Ebene der Device-Treiber. Sofern man diese Ebene überhaupt als
'Treiber' ansehen kann. Mit dem was heutige Treiber machen, hatte das
nicht viel gemeinsam.
Karl Heinz Buchegger schrieb:> Und es gab zuerst Compiler und erst dann, viiiel später Interpreter.
Interessanterweise war das gar nicht viel später. Fortran (1957) war die
erste implementierte höhere Programmiersprache und wurde kompiliert.
Schon eineinhalb Jahre später (1958) kam die erste Lisp-Implementation
von Steve Russel, diesmal als Interpreter.
Weitere bekannte interpretierte Sprachen folgten in der ersten Hälfte
der 60er Jahre mit APL und Basic.
Wenn schon über Geschichte und Compiler diskutiert wird eine Frage die
ich mir immer wieder stelle: In welcher Sprache wurde der erste Compiler
geschrieben? In Assembler? Und der erste Assembler? In ???
troll schrieb:> Wenn schon über Geschichte und Compiler diskutiert wird eine Frage die> ich mir immer wieder stelle: In welcher Sprache wurde der erste Compiler> geschrieben? In Assembler? Und der erste Assembler? In ???
Bootstrap-Ansatz. Der Compiler wird in der Sprache geschrieben, in der
er anschliessend Nutzprogramme übersetzten soll. C-Compiler werden also
in C geschrieben.
http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29
> Darf ich fragen, wie alt du bist und wie lange du schon programmierst?
seit dem Aufkommen der ersten Heimcomputer - insofern hast Du recht, in
puncto Basic ist mir ein Fehler unterlaufen, kam erst um einiges später.
Wobei programmieren bei mir Hobby ist, ich bild mir auch nichts darauf
ein.
> Die ersten verbreiteten Compiler (und damit Hochsprachen) waren> ALOGOL> Fortran> Cobol> PL/1>> und die Entwicklungszeit dieser Compiler war irgendwann in den> 50-er/60-er Jahren des letzten Jahrhunderts.
ja wenn schon Aufklärung, dann bitte auch mal Quellen angeben:
http://de.wikipedia.org/wiki/Zeittafel_der_Programmiersprachen> Und zwar ohne den ganzen Kleinkram> wie CPU-Flags, Stack, Registerklauberei oder Push/Pop Zählerei. Da diese> Themenkreise sowieso immer nach fixen Mustern abgehandelt wurden, konnte> man das genausogut auch der Maschine überantworten.
ist ja alles richtig, aber nur so lernt man, wie die Materie
funktioniert - nicht durch reinschieben von Speicherriegeln und schnell
vergessen wie die Ursprünge aussahen.
> Da diese Themenkreise sowieso immer nach fixen Mustern abgehandelt> wurden, konnte man das genausogut auch der Maschine überantworten. Die> machte dabei wenigstens keine Fehler mehr, sobald das Basismuster erst> mal stimmte.
zumal damals Lehrbücher und Dokus in der Regel auch nur den Spezialisten
zur Verfügung standen bzw. die fixen Muster nur die Spezialisten
kannten, die damit täglich umgehen durften und mußten - es gab noch
keinen Massenmarkt.
> Da waren Spezialisten am Werk, die die ersten kommerziell> eingesetzten Programme schufen. - ausschliesslich Spezialisten.
kein Massenmarkt eben, aus denen man Spezialisten hätte generieren
können - d.h. wenige Uni-Professore, Angestellte in gehobenen
Positionen, etc. denen das Equipment zur Verfügung stand und die
natürlich auch das Talent und die Zeit hatten da was draus zu
programmieren, zweifelsohne.
> Die Spezies der "Einfach-Programmierer" kam erst mit der Verbreitung der > PC,
rund 30 bis 40 Jahre später, auf.
zum Glück, sonst hätten wir heute noch Steinzeit und elitäre Zustände.
> Was genau wolltest du aussagen?
ich muß doch an der Basis ansetzen, im Prinzip sogar noch eine Ebene
tiefer auf Maschinencodeebene, um ein schnelle Programmiersprache zu
entwickeln (falls Geschwindigkeit und Speicherresourcen Aspekte sind -
viele werden das verneinen ?!).
Bei einem lahmen Rechner wirst Du die Unterschiede sehr deutlich sehen
können.
Doppelcompilation,etc. geht zwar dank der heutigen Rechnerkapazitäten,
aber ist das unbedingt sinnvoll?
Dann kann ich auch gleich bei C bleiben und mir das letzte Drittel der
kryptischen Fenster- und Gui-Programmierung unter C antun - als Amateur
sowieso.
why not schrieb:> nur noch Intel oder AMD und die gestalten Ihre CPUs ja auch> abwärtskompatibel.
Vom Befehlssatz her ja, aber mittlerweile gibt es andere Grenzen.
Versuch mal, ein zwar altes aber immer noch häufig eingesetztes
Betriebssystem wie den Windows Server 2003 auf einem aktuellen
Intel-Server zu installieren. Es geht nicht.
Why not schrieb:>> In welcher Sprache wurde der erste Compiler geschrieben?> keine Ahnung
FORTRAN ist nicht der allererste Compiler, aber der erste der populär
wurde. Die Entwicklung des Compilers dauerte 18 Personenjahre.
Der erste Pascal-Compiler wurde übrigens in Pascal geschrieben.
<blockquote>
In welcher Sprache wurde der erste Compiler
geschrieben? In Assembler? Und der erste Assembler? In ???
</blockquote>
Du darfst dir das nicht so vorstellen, dass sich jemand hingesetzt hat
und sich gesagt hat: So jetzt schreib ich mal einen Compiler/Assembler
Das ganze hat sich historisch entwickelt.
Natürlich wurde in der Anfangszeit direkt in Binärcode programmiert. Da
wurden Löcher in Filstreifen gestanzt, Lochkarten händisch gelocht, etc.
All dem lag zugrunde, dass man erst mal sein Programm niedergeschrieben
hatte. Da stand dann eben auf dem papier
CD 01 08
AC
BD
wobei jede Zahl für einen Befehl stand und ob das tatsächlich Hex-Zahlen
waren, kann ich dir auch nicht sagen. Wahrscheinlich aber eher nicht.
Diejenigen die sich mit der Materie beschäftigt haben haben dann ganz
schnell erkannt (das dauer nur ein paar Stunden :-), dass diese
Schreibweise höchst fehleranfälig ist. Also haben sie sich Mnemnoics
ausgedacht
ADD A, B
JP 0801
RET
und haben so ihre Programme auf dem Papier geschrieben und nachdem es
dort zum Test fertig war händisch in die Codes übertragen. Und da ist
jetzt der Schritt nicht mehr weit, ein Programm zu schreiben, welches
diese Eingabe in Textform von Lochkarten abliest (speziell wenn man eine
Lochkartenstanze mit Schreibmaschinentastatur hat) [eine Lochkarte ist
gleich 1 Zeile] und anhand einfacher Regeln aus dem ADD und den
zusätzlichen Argumenten die entsprechenden Codes erzeugt und auf neuen
Lochkarten ausstanzt. Das mag zwar primitiv sein, erfüllt aber erst mal
seinen Zweck - der erste primitive Assembler ist geboren.
Dieses allererste Progamm muss man mangels Assembler natürlich noch in
der hergebrachten Art und Weise (also direkt mit den Codes) schreiben.
Aber: es muss ja auch nicht viel können. Genau genommen muss es nur die
Befehle können, die in ihm selber vorkommen. Denn dann kann man den
soweit vorhandenen Assembler in seiner eigenen Sprache nochmal neu
schreiben und so den Bootstrap-Prozess einleiten. Mit dem vorhandenen
einfachen Assembler schreibt man eine kompliziertere Variante, die schon
mehr kann. Und mit der kommt dann die nächste Stufe, die wieder mehr
kann, usw. usw.
Und genauso funktioniert das auch noch bei heutigen Compilern. Nur das
man die nicht mehr in Assembler anfängt sondern man schreibt einen
hypotetischen XYZ Compiler zb erst mal in C. Wieder: Der braucht noch
nicht allzuviel können. Gerade das, was in ihm selber vorkommt. Danach
wird dieser Einfachcompiler in seiner eigenen Sprache nochmal neu
geschrieben und dann beginnt sich das Bootstrap Karusell zu drehen - der
vorhandene XYZ Compiler wird dazu benutzt um bessere Versionen eines XYZ
Compilers herzustellen, die schon wieder mehr können.
Eine Erstversion eines Compiler muss zb keine Funktionen kennen, oder
lokale Variablen oder Floating Point Arithmetik. Er muss auch nicht
optimieren oder besonders guten Code erzeugen. Es reicht völlig aus,
wenn er erst mal nur seine Quellsprache soweit übersetzen kann, dass es
reicht um einen in dieser Sprache geschriebenen Einfachst-Compiler
übersetzen zu können, wobei das Ergebnis lediglich funktionsfähig sein
muss.
Why not schrieb:> ich muß doch an der Basis ansetzen, im Prinzip sogar noch eine Ebene> tiefer auf Maschinencodeebene, um ein schnelle Programmiersprache zu> entwickeln (falls Geschwindigkeit und Speicherresourcen Aspekte sind -> viele werden das verneinen ?!).
Eben. Geschwindigkeit ist ein wichtiger Punkt bei der
Compiler-Entwicklung, aber nur begrenzt bei der Sprach-Entwicklung.
Und da algorithmische Optimierungen immer noch mit Abstand die größten
Geschwindigkeitssteigerungen liefern, ist eine schnelle Sprache eine,
die abstrakt genug ist, Algorithmen komfortabel zu formulieren.
Klassisches Beispiel sind die Fibonacci-Zahlen. Sprachen mit multiplen
Rückgabewerten für Funktionen können einen schnelleren Algorithmus
verwenden als eine Sprache, in der nur ein einziger Wert zurückgegeben
werden kann. In letzterer muss man dann zur Verwendung des optimaleren
Algorithmus zusätzlich manuell das mit den Rückgabewerten emuliert
werden, und die naive Implementierung ist halt doppelt so lahm.
Was das Übersetzen in Maschinencode angeht, ist es sehr schwer, den
optimalsten Code zu erzeugen. Selbst bei einfachen CPUs ist das ein
NP-vollständiges Problem, also für alle praktischen Belange nicht
hundertprozentig optimal lösbar, weder für Menschen noch für Compiler.
Dazu kommt, dass auch hier die vielversprechenderen Optimierungen noch
auf einer abstrakten, maschinenunabhängigen Zwischenstufe des Programms
durchgeführt werden.
Die Assemblerebene ist also in weiten Bereichen irrelevant. Bei der
Parallelisierung von Aufgaben z.B. sind Compiler noch nicht so gut,
darum ist für SIMD (MMX, SSE und Co) Assemblersprache populär, aber eben
nur dort, wo der Aufwand in vernünftiger Relation zum Ergebnis steht.
Dank besserer Compiler wird das immer weniger.
Selbst bei GPU-Berechnungen ist man doch schon vom Assembler weg. Ich
habe das noch gemacht, weil GLSL noch nicht wirklich praxistauglich war
zu der Zeit. Das war Low-Level-Optimierung vom feinsten, Feilschen um
jedes Bit und jede Instruktion. Und es war nötig, es lief gerade so
eben, total am Limit der damaligen Standardhardware. Heute sehe ich
meine eigenen Programme, und sie sind de facto unwartbar, weil der Code
die zugrundeliegenden Algorithmen nicht wiedergibt. Der Aufwand, mich in
meine eigenen Programme von 30-40 Instruktionen(!) neu einzuarbeiten,
ist die Mühe nicht wert. Ich benutze das lieber mit leichten Fehlern.
Die selben Algorithmen neu geschrieben in GLSL (was ja sehr an C
orientiert ist) wären unter Garantie nicht so optimal, ich tippe auf
Faktor 2. Aber wen kümmert's? GPUs sind inzwischen 10 mal so schnell, da
werf ich auch gleich noch eine algorithmische Optimierung über den
Haufen, die ich damals einbaute, aber die praktische Nachteile hat. Noch
ein Faktor 4 langsamer. Immer noch egal, dafür könnte ich dann neue
Funktionen einbauen, Fehler beheben, und so weiter.
> Bei einem lahmen Rechner wirst Du die Unterschiede sehr deutlich sehen> können.
Es gibt immer Randbedingungen, unter denen deine Aussagen und
Prioritäten korrekt sind. Aber es sind heutzutage Ausnahmefälle. Die
Rechensekunde kostet nicht mehr 1DM, neue/schnellere/mehr Hardware ist
billig, aber die Programmiererstunde ist teuer.
Mich regt z.b. die heutige Desktopsoftware auch auf. Und es gibt auch
ganz böse Sünder, die ungerechtfertigt verschwenderisch mit Ressourcen
umgehen. Aber ich rege mich ganz schnell wieder ab, wenn ich dann einen
alten Win95-Rechner anmache. 4MB RAM, 100MHz, sagenhaft. Sowas fand man
mal komfortabel. Und was der alles nicht kann! Das übersieht man
nämlich schnell, den Anwenderkomfort den man heute gewohnt ist.
Dann doch lieber heutige Desktopsoftware. Die würde es ohne die
Verschwendung schlicht und ergreifend nicht geben. Ich will gar nicht,
dass die Programmierer alle genau wissen, was auf der Assemblerebene
abgeht. Die haben genug andere Probleme, und als Hintergrundwissen für
guten Programmierstil gibt es ebenfalls viel nützlichere Dinge.
Und all das kann man 1:1 auf Mikrocontroller übertragen. Auch da gibt es
Grenzfälle, z.B. wenn man schon das größte Modell einer Familie
einsetzt. Aber bevor man da ans Optimieren geht, sollte man sich fragen,
wie viel Zyklen/Bytes man gewinnt, und wie lange das reicht, bis die
nächste Funktion nicht mehr reinpasst. Großzügig überdimensionieren
kostet ein paar Euro, ein Bruchteil eines Stundenlohns. Von den
geschonten Nerven und der schnelleren Fertigstellung des Geräts mal ganz
abgesehen.
> Doppelcompilation,etc. geht zwar dank der heutigen Rechnerkapazitäten,> aber ist das unbedingt sinnvoll?> Dann kann ich auch gleich bei C bleiben und mir das letzte Drittel der> kryptischen Fenster- und Gui-Programmierung unter C antun - als Amateur> sowieso.
Und machst all die Fehler, die man in C gerne macht. Ich weiss seit
gestern, warum mein Rechner nach 2 Wochen 4GB Swap voll hat -- ein
Memory Leak in einer kleinen banalen Hilfsanwendung, die ich irgendwann
mal fix gestrickt hab. Typischer Fehler für ein C-Programm. Von einem
erfahrenen Programmierer. In gerade mal 1000 Zeilen Code. Fehler, die
die Sprache zulässt, passieren auch. Immer. Und zu all den typischen
Gefahren bei der Programmierung in C kommen bei Assembler noch zig neue
Gefahren hinzu.
GUI-Anwendungen schreibe ich z.B. grundsätzlich in einer interpretierten
Skriptsprache, weil der Performanceverlust dabei sch*egal ist, aber weil
ich dann auch nicht mehr auf's Memory Management achten muss und ich
noch abstraktere Sprachfunktionen nutzen kann. Ich bin schneller fertig
und die Software hat weniger Fehler. Dass sie statt 5ms nun 10ms
Antwortzeit hat, kümmert keinen. Dass sie doppelt so viel Speicher
verbrät, ist sicherlich nicht ideal und summiert sich dann doch auf,
aber ich brauche nur ein einziges Memory Leak fixen und hab genug
Speicher gewonnen für 10 verschwenderische Programme ;) Und dann hat das
Progremm auch noch jeden Komfort, den man sich denken kann. In C würden
etliche sekundäre Funktionen wegfallen, weil es eben so viel Aufwand
ist.
Und ist es dann doch mal zu langsam/zu verschwenderisch mit Speicher,
dann, und nur dann, misst man mal aus, wo genau das Problem ist und
überlegt sich einen besseren Algorithmus. Gibt es keinen, dann (und nur
dann) geht man eine Sprachebene tiefer, also z.B. Skriptsprache->C und
von C->Assembler. Oder man nimmt größere Hardware, was von beidem halt
einfacher/billiger ist.
troll schrieb:> Trotzdem, ich mag Assembler (und C).
Ich mag auch CW (Morse-Telegrafie im Funkverkehr).
Trotzdem würde ich mich lächerlich machen, wenn ich mich hinstelle
und GSM & Co. als überflüssigen Mist zu bezeichne, weil man ja auch
mit CW prima Daten übertragen kann und dafür deutlich weniger (und
weniger fehleranfällige) Technik braucht.
CW ist mittlerweile aus dem professionellen Funkverkehr komplett
verschwunden. Die letzten, die sich (nach knapp 100 Jahren) davon
verabschiedet haben, waren die Seenotfunkdienste. Genauso wird
sich der Assembler nahezu vollständig aus professioneller (*)
Programmierung verabschieden.
(*) Zur Erinnerung: professionell ist kein Hinweis auf besonders
gute oder besonders schlechte Qualität, sondern es heißt lediglich,
dass derjenige, der es tut, sich damit seine Brötchen verdienen muss.
Das bedingt u. a., dass er mit seiner Produktivität konkurrenzfähig
sein muss.
Jörg Wunsch schrieb:> troll schrieb:>> Trotzdem, ich mag Assembler (und C).> Ich mag auch CW (Morse-Telegrafie im Funkverkehr).> [...]
Ich habe ja nirgendswo C verteufelt... Ich meine nur auch Assembler hat
noch seine Berechtigung, und sei es nur wenn man (als Hobby) hochgradig
zeitkritische Sachen auf unterdimensionierten AVRs machen will... Soll
doch jeder so programmieren wie er will und alle sind zufrieden. :-)
(Und wenn ich mal die Afu-Prüfung mache will ich auch CW lernen.)
Nebenbei noch Danke an Karl Heinz Buchegger für den sehr interessanten
Beitrag zum Compiler-Henne-Ei-Problem!
troll schrieb:> Jörg Wunsch schrieb:>> troll schrieb:>>> Trotzdem, ich mag Assembler (und C).>> Ich mag auch CW (Morse-Telegrafie im Funkverkehr).>> [...]> Ich habe ja nirgendswo C verteufelt... Ich meine nur auch Assembler hat> noch seine Berechtigung, und sei es nur wenn man (als Hobby) hochgradig> zeitkritische Sachen auf unterdimensionierten AVRs machen will...
Hat es.
Ausgansgpunkt der Sache war aber C-Bashing mit der Alternative der
einzig selig machenden, 'richtigen' Sprache Assembler. Und das kann man
so weder stehen lassen noch akzeptieren.
Wer heute aus Liebhaberei einen Ford Model-T am Leben erhält, ist ein
Enthusiast. Einem Autobauer dieses Modell aber als das einzig wahre Auto
verkaufen zu wollen, grenzt an Masochismus.
(Und zudem ist guennie nicht das erste mal mit diesem Blödsinn
aufgefallen)
Thread beobachten
Seitenaufteilung abschalten