Assembler wo sind eigentlich diese ganzen Genies??

[Dennis H. (c-logic)]

Wolfgang R. schrieb:
> Also ich benutze einen Hammer für Nägel und einen Schraubenzieher für
> Schrauben. Letzteren passend zum Schraubenkopf.
>
> Ich bekomme natürlich die Schraube auch mit dem Hammer in die Wand.

Er hat Schraubenzieher gesagt !!!
Teert und federt ihn.

[Johann L. (gjlayde)]

Andreas M. schrieb:
> https://github.com/amesser/ecpp/blob/master/src/ecpp/HAL/AVR8/IOPort.hpp

Der Code ist Zucker um SFR-Adressen wie

constexpr volatile uint8_t* pin = &PINB;

usw, was aber kein gültiges C++ ist. Gemeinerweise akzeptiert GCC v5 
solchen Code, aber v6+ quittiert ihn mit einer Fehlermeldung.

> Manchmal ist C++ aber auch zum Haare raufen

+1

[Martin V. (oldmax)]

Hi
Nun ist es wieder da, diese ewige Diskussion über Programmiersprachen. 
Hier mal meine Meinung dazu:
Gute Programmierer wissen um die Vor- und Nachteile einer jeden Sprache 
und kennen auch den Unterschied zwischen Maschinencode und Assembler. 
Die Halbgaren dürfwen das gern weiter durcheinander werfen, ist ja doch 
egal, aber nur mal so zum Nachdenken
ein Z80 Maschinencode: C3C302  (Hexadezimale Darstellung, real aber
                                11010011
                                11010011
                                00000010 )
Assembler:             jp Main
Main = Adresse  02C3h
Also, 80% der Beiträge sind basierend auf
Ich hab ein bisserl "C" gelernt und erwarte, das alle "C" nachmachen und 
die andere Seite auch mit "Assembler ist ein Zeichen für Experten" einen 
völlig falschen Standpunkt vertreten.
Alles Quatsch! Experten, oder besser Profis wissen um die Vielfalt der 
Sprachen und wenden das an, welches dem zielführend ist.
Außerdem beteiligen sich so wie ich das sehe, nur wenige Profis an 
solchen Diskussionen, weil sie dafür vermutlich keine Zeit haben und 
werden, wenn sie solche teilweise haarsträubenden Beiträge lesen, 
höchstens ein müdes Lächeln übrig haben. Allein schon der Gedanke, 
Profis wären mal eben so in der Lage ein disassembliertes Programm zu 
entschlüsseln, zeigt, wieviel Ahnung da vorhanden ist. Erstens, ein 
disassemblierter Code kann nur aus der Maschinensprache entstammen und 
zweitens ist noch lange nicht gesagt, in welcher Sprache der Code 
ursprünglich entstanden ist. Das, was auf einer Maschine läuft, auch im 
PC und sonstwo auf elektronischen Geräten ist, "Trara", Maschinencode. 
Und da sind absolut keine Kommentarzeilen vorhanden.
Man kann, und das ist sehr zeitraubend, Maschinencode disassemblieren 
und mit viel Akrebie versuchen, den Verlauf des Programmes 
nachzuvollziehen. Spätestens aber, wenn ein Programmierer oder Compiler 
aus einer unbekannten Tabelle einen Wert in ein Register kopiert, mit 
Push auf den Stack legt und mit einem Return auf diese Adresse springt, 
ist es mit einem einfachen Lesen von Assemblercode vorbei.
So, und nun tobt euch weiter aus mit dieser völlig nutzlosen Diskussion, 
ob Assemblercode schneller oder "C" übersichtlicher ist.
Gruß oldmax

[Peter D. (peda)]

Wenn ich mal so an meine Assemblerzeiten zurückdenke, da habe ich auch 
viele Schweinereien gemacht.
Ich hab z.B. gerne konstante Argumente einfach mit DB-Anweisungen hinter 
den Call geschrieben, anstatt umständlich Register laden zu müssen oder 
sie in den Stack zu pushen. Die Unterfunktion mußte dann nur die 
Returnadresse in ein Pointerregister laden und konnte damit bequem die 
Argumente lesen. Und zum Schluß genau hinter das letzte Argument zurück 
springen.
Viel Vergnügen, wenn man sowas wieder disassemblieren will. 
Insbesondere, wenn die Argumentenliste variabel ist.

[Martin V. (oldmax)]

Hi
Nun ja, von einem Experten in Sachen Controllerprogrammierung bin ich 
weit entfernt, hab aber auch in den 80er Jahren mit einem ZX81 und dem 
Z80 Prozessor erste Schritte in Richtung Programmierung gehabt. Damals 
erhielt ich mit meinen 30 Lenzen auch einen Job an einer Industrieanlage 
mit "Frei programmierbarer Steuerung". Die Anführungsstriche sind 
deshalb, weil frei Programmierbar damals noch nicht ganz so einfach war. 
Da lief noch viel über EProms, die nur bei Anlagenstillstand eingesetzt 
werden konnten und man daher schon sehr genau vorarbeiten mußte, um 
keinen Fehler zu machen. Die waren richtig teuer, an so einer Anlage und 
konnten gern auch mal 5 stellige Kosten bewirken. Die Programmierung war 
eine Art Anweisungsliste, kurz "AWL". Das ich diesen Job u. a. über 35 
Jahre hatte, zeigt, das meine Fehlerquote klein war, auch zur Zeit der 
wirklich frei programmierbaren Steuerungen. In Sachen Programmiersprache 
hab ich dann auch nach Basic Paacal und Datenbanken gemacht. Aber eben 
auch hauptsächlich nur so zum Hobby und Weiterbildung. µC's mache ich 
nur hobbymäßig und wenn man mich ärgert. So hatte ich die letzten zwei 
Arbeitsjahre eine "Rentneruhr" auf meinem Schreibtisch, die im 1/10 
Sekundentakt rückwärts lief, und auf der Anzeige (7 Segment) zur 
richtigen Zeit "PAUSE" oder "FEIErAbENd" anzeigte. Sollte meinen 
Vorgesetzten zeigen, wie schnell die Zeit vergeht und das man mit der 
Einarbeitung eines Nachfolgers nicht allzulange warten sollte. Aber das 
ist Schnee von gestern. Jetzt genieße ich meinen Dauerurlaub.
Tja, die gute alte Zeit.....
gruß oldmax

[(prx) A. K. (prx)]

Peter D. schrieb:
> Viel Vergnügen, wenn man sowas wieder disassemblieren will.
> Insbesondere, wenn die Argumentenliste variabel ist.

Der erwähnte PL/65 Compiler bestand quasi daraus. So in der Art
   if (expect("goto"))
     emit("jmp ...")
wobei beide Aufrufe ihren String direkt hinter dem Aufruf hatten.

[Yalu X. (yalu) (Moderator)]

Peter D. schrieb:
> Wenn ich mal so an meine Assemblerzeiten zurückdenke, da habe ich auch
> viele Schweinereien gemacht.

Auch selbstmodifizierender Code gehörte dazu (prominentestes Beispiel:
Apple-Systemsoftware vom Woz). Leider geht das auf Harvard-Prozessoren
wie dem AVR nicht mehr, da hier nicht direkt in den Programmspeicher
geschrieben werden kann ;-)

[Einer K. (Gast)]

Yalu X. schrieb:
> da hier nicht direkt in den Programmspeicher
> geschrieben werden kann ;-)

U.A. AmForth tut das, über einen Kurzausflug über den Bootloaderbereich.
Kann man also schon unter "selbst modifizierender Code auf Harvard/AVR" 
einordnen, wenn man es möchte.