Diskussion:Höhere Programmiersprache

Neutralität

Wo findet denn die Diskussion dazu statt? Besagte Passage ist meiner Meinung nach kompletter Unsinn und könnte (gern auch ersatzlos) gestrichen werden. Hier nur mal der gröbste Unfug:

• Compiler ignorieren Optimierungsmöglichkeiten (hinzufügung: !)
• 1:1 Übersetzung von Hochsprache in Assemblerbefehle
• Beispiel: Teile der kernel32.dll 10x schneller in Assembler, "Unkenntnis der Programmierer bezüglich des zu programmierenden Prozessors"
• das ist die Begrüdnung warum Hochsprachen Assembler noch nicht verdrängt haben

134.109.185.33 15:48, 5. Dez. 2006 (CET)

wirkt insgesamt ärgerlich - vergessen wir die Arbeit es auf einen begriff zu bringen nicht - wäre unfair dem autor gegenüber -- 02:57, 1. Apr. 2009 (CEST) 02:52 GMT (ohne Benutzername signierter Beitrag von 85.177.218.194 (Diskussion | Beiträge) )

Du hast recht, das ist komplett Unsinn. --Hubi 07:19, 18. Dez. 2006 (CET)

Kontrollstrukturen, Syntax, Optimierung

Daß ein Assembler keine Kontrollstrukturen hat, kann man wohl so nicht sagen. Jede „Kontrollstruktur“ in einer höheren Programmiersprache läuft auf eine bedingte (oder auch unbedingte) Verzweigung hinaus. Und genau das wird hinterher im Maschinencode (will sagen Assembler) programmiert. Also muß auch der Assembler Kontrollstrukturen haben - bedingte und unbedingte Verzweigungen. Und das hat ein normaler Assembler auch.

Und daß ein Assembler keine Syntax-Überprüfung bietet ist so auch nicht ganz richtig. Wenn man falsche Befehle eingibt meckert auch ein Assembler (wobei hier das Programm gemeint ist, das den Maschinencode für das Zielsystem generiert). Und mehr kann ein Hochsprache-Compiler leider auch nicht bieten. Auf eine Semantik-Überprüfung werden wir ja noch lange warten...

Zum Schluß: Eine hochoptimierender C-Compiler für Mikrocontroller haut einen ungeübten Assembler-Programmierer gewaltig aus dem Feld (ist mir selbst schon so ergangen und ich war nicht unbedingt „ungeübt“). Und geübte Assembler-Programmierer gibts eben wegen C immer weniger. --Harald Wehner 16:15, 2. Okt 2005 (CEST)

Kontrollstruktur ist eine Struktur (IF, WHILE), kein GOTO. Syntaxüberprüfung meint Syntax, keine lexikalische Analyse, die ein normaler Assembler allenfals durchführt. Hubi 17:05, 2. Okt 2005 (CEST)

IF, WHILE und ähnliches sind „Kontrollstrukturen“, welche im Maschinencode, der daraus generiert wird, auf bedingte oder unbedingte Sprünge hinauslaufen. Also hat ein Assembler genau die gleichen „Kontrollstrukturen“. Was ist ein JNE, JZ oder wie sie alle heißen mögen denn sonst?

Bei der „lexikalischen Analyse“ frage ich mich dann, was denn den sog. „Syntaxcheck“ eines Compilers de facto davon unterscheidet. Zu einem „syntaktisch korrekten“ Statement in Hochsprache ist doch im Prinzip keine weitere Aussage zu treffen als die, daß es dem Sprachumfang zugeordnet werden kann. Die Mittel des Assemblers (Programm), welcher den „lexikalischen Inhalt“ eines zu assemblierenden Programmes überprüft, erscheinen mir da zumindest sehr nahe an einer „syntaktischen Analyse“ zu sein. Die Fehler, die der Assembler (Programm) nicht anzeigt, zeigt auch kein Compiler an, als da wären nicht initialisierte Variablen, Pointer, die irgendwo ins Nirwana zeigen und solche Dinge mehr. Oder täusche ich mich da so? --Harald Wehner 17:13, 3. Okt 2005 (CEST)

Sprünge sind nach Dijkstra unstrukturiert, weil im der Programmfluss und der Programmtext unter Umständen auseinanderlaufen (Spaghetticde). D.h. es ist nicht einfach festzustellen, was am Anfang, was am Ende, was mehrfach etc. ausgeführt wird. Verwendet man kein Goto sondern die Kontrollstrukturen der höheren Programmiersprachen, so ist sichergestellt, dass innerhalb einer Prozedur der Programmfluss und der Programmtext kongruent sind (s. Goto Statement considered harmful v. Edsger Dijkstra). Dass letztlich immer eine JMP oder ä. Konstruktion im Maschinencode verwendet wird, tut hier dem Argument keinen Abbruch. Dass einige moderne Makroassembler Kontrollstrukturen von höheren Programmiersprachen übernehmen, auch nicht.

Syntax im Sinne von Programmiersprachen bezeichnet in der Regel kontextfreie Grammatiken (C++, Pascal), während Assembler nur endliche Automaten sind, die natürlich auch eine Fehlermeldung generieren, wenn das falsche Symbol (Mnemonic) kommt. Hubi 19:03, 3. Okt 2005 (CEST)

von Continuations hält er dann wahrscheinlich auch nix ;) -- ∂ 19:05, 3. Okt 2005 (CEST)

Oh je - die „strukturierte Programmierung“!! Was hat „Strukturierung“ denn mit „Kontrollstrukturen“ zu tun? Kontrollstrukturen sollen doch den Programmablauf eindeutiger und lesbarer machen. DAS muß aber der Programmierer leisten. Es helfen dazu die besten Kontrollstrukturen nichts, wenn der Programmieraffe gearbeitet hat. Ich hatte mal ein Fortran-Programm zum debuggen (F77 hat schon ein gerüttelt Maß an Kontrollstrukturen) - aber das Teil hatte bei 8000 Lines of Code keine Einrückungen, keine Kommentare und eine einzige Function (die von den 8000 Zeilen etwa 5000 Zeilen ausgemacht hat). Kontrollstrukturen waren da massig drin. IFs, ELSEs, DOs (auch CONTINUEs, was ja lt. Dijkstra wohl keine Berechtigung haben dürfte) und was F77 so alles noch hat. (Es ist zum Glück schon lange her...)

Ich behaupte, daß ich mit Assembler strukturierter gearbeitet habe, als viele „Hochsprachen-Programmierer“ es je können. Die werden von den vielen kleinen Helferlein in ihren schönen IDEs einfach versaut. Da hilft auch nicht die noch so schönste, strukturierte oder was weiß ich auch immer Programmiersprache. Das haben halt viele Leute einfach nicht drauf. Ich behaupte nicht, daß ich die Strukturiertheit in Person bin, aber alleine die Aufteilung der Funktionen in entsprechende Files finden gar viel zu viele Leute einfach lästig. (Ich programmiere ausschließlich C).

Eine etwas andere Sache (nur so als kleines Schmankerl): In eben diesem F77 habe ich vor 20 Jahren an einem praktisch komplett objektorierten Projekt mitgearbeitet. F77 kennt an sich ja keine Objekte. Wir haben sie ihm eben beigebracht - und wir haben uns auch daran gehalten, wie es jeder gute Programmierer tun sollte. Man braucht also keine „objektorientierte Sprache“ um mit Objekten herumzualbern... --Harald Wehner 20:16, 4. Okt 2005 (CEST)

Und was hat das jetzt mit dem Thema zu tun? Was hat Strukturierung mit Kontrollstrukturen zu tun? (viel), Mit Assembler habe ich strukturierter gearbeitet. Da sage ich: schön für dich! Da wir offensichtlich aneinander vorbeireden, halte ich die Diskussion für erledigt. --Hubi 07:46, 5. Okt 2005 (CEST)

Ob wir so aneinander vorbeireden? Wir haben offensichtlich unterschiedliche Standpunkte. Ein „Syntax-Check“ prüft doch, ob erlaubte Konstrukte benutzt sind oder nicht. Die unerlaubten bemängelt er. Das „Problem“ bei Assembler ist, daß ziemlich viel erlaubt ist. Aber eine zum Mnemonik nicht passende Addressierungsart ist z.B. nicht erlaubt - und das wird ein Assembler auch bemängeln. Mir fällt sonst nichts ein, was ein Assembler bemängeln könnte - außer den von Dir schon erwähnten falschen Mnemonik. Vielleicht noch nicht dazu passende Register oder so was. Vielleicht gibts sogar Assembler, die es verbieten aus einem Modul heraus zu hüpfen - ich hab da keine große Erfahrung, da ich im Wesentlichen nur mit Z80 und 6502 auf Assemblerebene gearbeitet habe - und dort wars egal, wo ein JMP landete. Ah ja - da ist noch was: Nicht egal waren z.B. die Short Jumps. Deren Ziel mußte schon in Reichweite liegen (127 Byte) - sonst gabs auch eine „Fehlermeldung“. Und so wie ich es sehe, hat das durchaus mit „Syntax“ etwas zu tun. Es ist halt ein etwas erweiterter Syntax-Begriff. Nix für ungut - aber so ausschließlich den Begriff „Syntax“ auf die „höheren Programmiersprachen“ zu beschränken, halte ich für akademisch - was für mich heißt: nicht praxisbezogen (ich hab lang genug selbst studiert...). --Harald Wehner 00:08, 11. Okt 2005 (CEST)

Also, mir stoeszt die Formulierung "Syntaxanalyse unmoeglich" ebenfalls gehoerig auf - so trivial die Syntax eines Assembler-Parsers auch sein mag, es ist nichtsdestotrotz eine Syntax... und deren Analyse ist auch offensichtlich moeglich (sonst haette es ja auch nie Assembler gegeben, gelle? ;D). Interessanter waere da dann doch, darauf hinzuweisen, dass eben Assembler (sofern sie keine komplizierteren Makros bereitstellen) eine regulaere Syntax verwenden und somit nur tiviale Sprachkonstrukte moeglich sind, waehrend mit kontextfreien Grammatiken Klammerungen, Blockstrukturen und dergleichen erkannt werden koennen.

Ich hab den Artikel einfach mal geändert. Auch ein Assembler kann Syntaxanalyse. Viele Assembler können zum Beispiel geklammerte arithmetische Ausdrücke berechnen, und dazu braucht man schon einen kompletten Parser. --RolandIllig 04:33, 20. Apr 2006 (CEST)

Ob ein Register zu einem Befehl passt, hat allerdings vermutlich nix mit Syntax zu tun - das ist eher Kontext und um den mogelt man sich im allgemeinen herum (kontextsensitive Sprachen koennen bekanntlicherweise schlecht bis garnicht analysiert werden).

Ich ordne das nicht unter "Kontext" ein, sondern als semantische Analyse. Genau aus dem Grund steht mittlerweile auch im Artikel, dass selbst Assembler grundlegende semantische Analyse betreiben. --RolandIllig 04:33, 20. Apr 2006 (CEST)

Eine ganz andere Sache noch: Die Tatsache, dass Assembler noch nicht 100%ig verdraengt wurde halte ich nicht seiner ach so tollen Effizienz zu gute (zum Henker mit Koeffizienten ;D) sondern eher dem Fakt, dass man bestimmte Operationen wie malloc etc. auch in C nicht programmieren kann (die Funktion malloc aus der C-Bibliothek ist meines Wissens nach immer in Assembler geschrieben - ob nun inline oder normal, ist ja eigentlich egal). Und genau fuer solche Faelle sowie fuer Grundsteinlegung auf neuen Maschinen ist Assembler nunmal die geschickteste Loesung. --FAR 07:38, 17. Okt 2005 (CEST)

malloc kann man auch ganz ohne Assembler schreiben. Beispiel: ftp://g.oswego.edu/pub/misc/malloc.c --RolandIllig 04:33, 20. Apr 2006 (CEST)

Objektorientierung?

Im 5. Absatz von "Geschichte" steht:

Wohl aber wurden Ein- und Ausgangsparameter (INPUT/OUTPUT) vom Haupt- ans Unterprogramm übergeben und umgekehrt (objektorientiertes Programmieren).

Wenn ich nicht total falsch liege, hat das alles mit Objektorientierung nichts zu tun. Ich bin dafür, den Link an dieser Stelle kommentarlos zu streichen. --Rubik-wuerfel 11:25, 7. Jun. 2007 (CEST)

Stimmt, ich habe ihn entfernt. --jpp ?! 13:15, 7. Jun. 2007 (CEST)

die Definition ist Quatsch

Da heißt es:

Eine höhere Programmiersprache (engl. high level language) ist eine Programmiersprache, die die Abfassung eines Computerprogramms in einer abstrakten Sprache ermöglicht (die so zwar für Menschen, aber nicht unmittelbar für Computer verständlich ist)

Danach ist auch Assembler eine höhere Programmiersprache, denn auch hier wird abstrahiert zu Mnemonics, lesbaren Zahlen und Prozeduraufrufen. Ohne Übersetzer für eine Maschine nicht verständlich. Und auch C gehört nicht zu den höheren Programmiersprachen. Die Sprache wurde geschaffen als minimale Abstraktion über Assembler, um systemnah zu programmieren, keinesfalls als Programmiersprache, die irgendein tolles Programmierparadigma umsetzt. Mr. Anderson 15:11, 2. Aug. 2007 (CEST)

Die Defintion ist nicht ganz korrekt, da geb ich dir Recht. Wobei C sehrwohl eine höhere Programmiersprache ist, was eigentlich auch außer Frage steht. Jedoch weiß ich jetzt nicht ob die obige Behauptung jetzt auf die Definition einer höheren Programmiersprache beruht oder dies allgemein deine Meinung ist, nichtsdestotrotz ist es Quatsch.

Das sehen Kernighan und Ritchie nicht ganz so streng... In ihrem berühmten Werk heißt es in der Ausgabe von 1978 "C is a general-purpose programming language which features economy of expression, modern control flow and data structures, and a rich set of operators. C is not a "very high level" language, nor a "big" one, and is not specialised to any particular application. But its absence of restrictions and its generality make it more convenient and effective for many tasks than supposedly more powerful languages".134.247.251.245 12:48, 15. Sep. 2014 (CEST)

Siehe auch: Gegenüberstellung von 3GL und 4GL

Der verwiesene Teil existiert nicht mehr in dem Artikel

Fehlerhafter Assemblercode?

 M1: CMP R2,#20
     BGT M2
     MUL R1,R2
     INI R2
     JMP M1

Ist schon eine Weile her aber, sollte die erste Zeile nicht auf 21 testen? IMHO nimmt lt. Code der linken Seite »I« die Werte 1..20 und nicht 1..19 an. Also:

  M1: CMP R2,#21

Und dann steht weiter unten ein

  INI R2

Ich weiss nicht welcher Assember das sein soll, aber es soll wohl ein Inkrement darstellen und damit sollte es doch besser

  INC R2

heissen, oder? (nicht signierter Beitrag von Maexotic (Diskussion | Beiträge) 15:24, 22. Aug. 2011 (CEST))

BGT steht ja wohl für Branch on Greater Than, da ist die 20 im Befehl davor schon ok, denn damit soll es ja nochmal durchlaufen. - Und ja, INC statt INI fände ich auch intuitiver, schließlich heißt das ja sowohl auf 8080 und 6502 so, und dieser Assembler soll ja anscheinend eine Mischung aus den beiden darstellen. --PeterFrankfurt 03:33, 23. Aug. 2011 (CEST)

Assembler

Vielleicht sollten noch ein Abschnitt und eine Klärung hinzugefügt werden. Zwar gilt gemeinhin Assembler nicht als höhere Programmiersprache, und für die ersten Assembler ist das auch sicherlich zutreffend.

Allerdings ist die Grenze heute ganz und gar nicht mehr trennscharf, denn die seit den Achtzigern stetigt weiterentwickelten Makro-Assembler beinhalten schon eine ganze Reihe von Abstraktionsebenen, auch sind Unterprozeduren und Co kein Problem mehr. Mit Variablen arbeiten Assembler ja schon von Beginn an.134.247.251.245 12:41, 15. Sep. 2014 (CEST)