4. Frage zu Assembler und der Syntax

Frage zu Assembler und der Syntax

  • L

    Das is ja nur ne Frage des Assemblers, du kannst dir jederzeit einen Assembler schreiben der das andersrum macht.
    AT & T Syntax ist zum Beispiel

    movb $0x61, %al

    Intel Syntax ist dagegen das bekannte

    mov al,61h

    Das ist deshalb so rum weil der Maschinencode dafür auch so rum ist.
    Die Befehle oben sind in x86-Maschinensprache

    0xB0 0x61

    (Big- und little Endian nicht beachtet)

    0
  • A

    linux_c89 schrieb:

    ... du kannst dir jederzeit einen Assembler schreiben der das andersrum macht.

    Ne, ich kann das nicht, einen Assembler (x86) schreiben ist zu kompliziert für mich 🙂 Habe es mal versucht und aufgegeben...

    0
  • L

    naja vielleicht isses besser erstmal einen für eine RISC-Architektur zu schreiben (und den Assembler simpel zu halten)
    Ich meinte vor allem das es viel leichter ist einen Assembler zu schreiben als einen Compiler

    0
  • ?

    wieso soll sich abc.w gleich einen assembler neu schreiben müssen, und vor allem wenn es den schon längst gibt?

    @abc.w
    was ist denn ein displätzchen? haben wir schon weihnachtszeit? 😃
    und sollen wir dich jetzt immer abc. w nennen, weil es sich einfach besser liest?
    😉

    0
  • L

    wieso soll sich abc.w gleich einen assembler neu schreiben müssen, und vor allem wenn es den schon längst gibt?

    Aus Übungsgründen er hat ja auch gesagt dass ers probiert hat
    Ich habe bisher nur Programme geschrieben dies schon gibt weil ich mir die nötigen Programmierkenntnisse antrainieren muss

    0
  • B

    mov al, 61h läßt sich mit regular expressions schneller in mov(al,0x61); umsetzen, wenn Du einen C-emu-code draus machen willst 😉
    Ich bastele gerade an so einem Emulator rum. Also - für einen 68000-Prozessor war das um einiges einfacher als für so 'nen dämlichen 386er. So ein 6502-Sim dürfte für das erste Verständnis ideal sein.

    @void**: Versuche patallel dazu Erhard's PrettyOS-Tutorial anzulesen. Für das grundlegende Verständnis eines Computers ist das Betriebssystem genauso wichtig.

    offtopic: Gibt's da bereits irgendwelche brauchbare Sourcen, die einen 386 in C emulieren? Mit so manchen Commands tue ich mich da durchaus etwas schwer...

    0
  • C

    Ich frag mich warum gerade Assembler schneller seien soll als c++ wenn doch beide in Machinensprache übersetzt werden?

    0
  • S

    gamebuntu schrieb:

    Ich frag mich warum gerade Assembler schneller seien soll als c++ wenn doch beide in Machinensprache übersetzt werden?

    Alle Möglichkeiten hast du mit beiden Sprachen. Allerdings kann es in seltenen speziellen Fällen dazu kommen, dass der Compiler der dir C++ in Maschinensprache übersetzt nicht genau sieht was du machen möchtest bzw. nicht weiß, dass diese Aufgabe mit anderen Maschinenbefehlen, anderer Speicherbelegung, etc. noch performanter möglich wäre. In so einem Fall würde man dann (wenn diese Performance wichtig ist) die Stelle mit Assembler ausprogrammieren und dem Compiler damit vorweggreifen.

    MfG SideWinder

    0
  • N

    Es sei dazu auch nochmal auf den Entscheidenden Unterschied in der Abstraktions"hoehe" zwischen Assembler und Sprachen wie c++ mit sehr abstrakten Konstrukten hingewiesen.
    Was du in Assembler schreibst, steht spaeter so ziemlich 1:1 als Maschinencode umgesetzt in deinem Programm. Mal abgesehen von bereits erwaehnten Spezialbefehlen in der CPU, die sich nicht sinnvoll in einer CPU-unabhaengigen Hochsprache abbilden lassen, ist die Gefahr hier deshalb eher gering, praktisch nutzlosen oder unnoetig aufgeblaehten Code in deinen Programmen zu haben, wenn du dich nicht gerade ungeschickt anstellst.
    Dagegen bergen gerade die zwar angenehmen, aber sehr abstrakten Konstrukte in zB. c++ bei achtloser Verwendung ein hohes Potential, ein heilloses Chaos an letztendlich praktisch nicht produktivem Maschinencode zu generieren, der allein dazu gut ist, die ganzen abstrakten Sprachkonstrukte praktisch zu organisieren und zu verwalten.
    C als Sprache mit weniger abstrakten Konstrukten ist da von der Abstraktion schon naeher an Assembler, bzw. man laeuft dort mit einem guten Compiler deutlich weniger Gefahr, in teure Fettnaepfchen zu treten.

    0
  • C

    Ah noch ne frage wie kann man den eine Hochsprache in Binäre umwandeln also was ich meine ist wie wandelt der compiler den C++ code in binären code um?
    Un wie ist das bei Assemblersprache da ja asm ja fast 1:1 ist?

    0
  • N

    Compilerbau ist eine ziemlich komplizierte Angelegenheit. Einen sehr groben Einblick gibt dir vielleicht Wikipedia.
    Ein Assembler ist dagegen relativ simpel gestrickt. Wenn man von Zusaetzen wie Meta- und Strukturbefehlen absieht, laeuft es im Prinzip darauf hinaus, dass sich der Assembler in einem ersten Durchgang Zeile fuer Zeile hernimmt, die Zeichenfolge bis zu den ersten Leerzeichen mit einer Liste zulaessiger Mnemonics abgleicht und wenn er was gefunden hat schaut, ob die dahinterstehenden Parameter zulaessig sind. Mit den Mnemonics sind dann die entsprechenden Maschinencodes und Vorschriften zu deren Modifizierung in Abhaengigkeit von der Parametern verknueft. So kann jeder Zeile die Bytefolge eines maschinenlesbaren Befehls zugeordnet werden. Stoesst der Assembler auf Befehle, die Speicher adressieren, werden statt der Adressen zunaechst ausreichend grosse Platzhalter eingefuegt und diese Stellen mit den adressierten Variablen oder Labels gespeichert.
    Stoesst der Assembler auf Labels oder "Variablen", werden ihre Adressen soweit schon feststellbar ebenfalls gespeichert.
    Am Ende dieses Vorgangs liegt also eine Rohfassung des kompletten Programms inklusive Daten, Labels/Variablen und deren Adressen im Speicher vor.
    In einem zweiten Schritt werden dann die Platzhalter fuer Adressen durch die gespeicherten Adressen der Labels ersetzt.
    Zur Optimierung kann dann in weiteren schritten die Adressweite von Befehlen angepasst werden. zB. kann man fuer nahegelegene relative Sprungziele auch 8-Bit statt der sicherheitshalber zuvor reservierten maximalen Adressweite verwenden...

    0
  • B

    Damit ist aber nun erst die Hälfte der Arbeit zu einem ausführbaren Programm geschaffen. Jetzt kommt nämlich das Betriebssystem ins Spiel. Nehmen wir ein ganz simpel gestricktes, dann bleibt immer noch das Problem, dass man nicht weiß, wo das Programm im Speicher landen wird. Jetzt gibt es im Programm aber nicht nur relative Sprünge, oder relative Datenadressen - sondern bei weiten Distanzen eben auch absolute Adressen - und die können noch nicht bekannt sein. Daher werden solche Stellen praktisch offen gelassen, und im Anhang des Programms eine Art Liste dieser Stellen drangeklebt. Das Ganze wird nun - sagen wir mal als .exe - abgespeichert. Wenn Du dem Kommandointerpreter nun die Anweisung test.exe eintippst, so hüpft Dein Programm nicht einfach in den Speicher und legt los, sondern dieser Kommandointerpreter bringt es an eine ihm passende Stelle, bereitet es vor, indem er nun jene Liste auswertet und die fehlenden Adressen ergänzt und dann ruft er es wie eine Art Unterprogramm auf. Soweit zum einfachsten Fall! Es gibt nun also durchaus unterschiedliche Dateiformate für ausführbare Programme, und zusammen mit anderen Notwendigkeiten, kann es Dir eben passieren, dass ein DOS-Programm nicht mehr unter Win laufen will, oder grob gesagt, obwohl das Programm mit dem gleichen Assembler auf dem gleichen Prozessor erstellt wurde, spielt eben das Betriebssystem noch eine entscheidende Rolle.
    Daher meine Anregung - zum Grundverständnis eben auch gleich noch in dieses Gebiet einlesen.

    0
  • L

    Ich frag mich warum gerade Assembler schneller seien soll als c++ wenn doch beide in Machinensprache übersetzt werden?

    Das sind meistens Kleinigkeiten (Dinge die man normalerweise braucht aber in diesem Spezialfall überflüssig sind)
    Heutzutage ist der Unterschied durch extrem intelligente Compiler wie den gcc sehr gering und da überwiegt meistens der Voteil der besseren Les- und Wartbarkeit von C(++)

    0
  • A

    fließkommafreak schrieb:

    und sollen wir dich jetzt immer abc. w nennen, weil es sich einfach besser liest?

    Nein, das ist was anderes. Das ist mein Benutzername in diesem Forum, kurz, anonym und neutral.
    Fehlende Leerzeichen stören den Lesefluss, weiss nicht, wie es die anderen sehen. Klar, dem Assembler ist es egal, ob da ein Leerzeichen fehlt oder ob da 20 Leerzeichen stehen. Das ist aber kein Grund, den Quelltext für den Assembler zu schreiben. Vielleicht hat der eine oder andere Mensch Lust, den Quelltext zu lesen.

    PS: Ich durfte mal Vorlesungen bei einem Informatik-Professor besuchen, er hatte in seinem Quelltext so wenig wie möglich Leerzeichen benutzt, z.B. so ähnlich:

    for(i=0;i<N;i=i+2){a[i]=b[i]-1;c[i?0:1]=a[i];}

    Vielleicht hat er dabei an den Compiler gedacht, dass er zu viele Zeichen parsen soll und dann hatte er vielleicht Mitleid mit dem Compiler deswegen 😕 Wie dem auch sei, seinen Quelltext hat er sicherlich für den Compiler geschrieben und nicht für seine Studenten...

    0
  • ?

    Bitsy schrieb:

    offtopic: Gibt's da bereits irgendwelche brauchbare Sourcen, die einen 386 in C emulieren? Mit so manchen Commands tue ich mich da durchaus etwas schwer...

    hast du dir schon
    http://www.dosbox.com/ angesehen?

    @abc.w
    asm code nervt doch am meisten, wenn er unkommentiert oder schwachkommentiert ist, oder grundlagen voraussetzt, die nirgendwo im buch oder internet stehen, dann folgt die spezialsynthax(oft überflüssig) eines assemblers, von zuvielen speziellen hochsprachenelementen darin und ganz zu schweigen und von verwirrenden weihnachtsdisplätzchen-bezeichnungen(tolle assoziation zu den nummern an den weihnachskalendertürchen, was?, huch bin ich genial).
    und wenn ich bei einem schon lange im gebrauch seienden system immer noch überflüssigerweise movl oder movb schreiben oder lesen muss oder soll, oder mainstreamfremde datentypenbezeichnungen, dann fühl ich mich vergessen. aber dies nur nebenbei. über asmsyntax kann man natürlich immer mal diskutieren, ist aber eher ein nebenschauplatz, wenn hier jemand im forum nach grundlagenerklärungen fragt und auf aufklärende antworten hofft. das ist in etwa so, als wenn ein kleines kind auf dich zukommt, und fragt:"spielst du mit mir pennis?" und du antwortest zeigefingerfuchtelnd:"hey, das sagt aber aber nicht, mein kind" "und in der nase bohren solltest du auch nicht". und c-code und c++code: habe ich nur selten lesbarer empfunden, als asm-code. zu den ausnahmen gehört vor allem der c/c++-code einiger wirklicher(!) code-künstler hier in forum oder der c-code für unbekannte microprozessoren.
    der benutzername abc.w wirkt auf mich nicht neutral: erster eindruck: codierschützling, weiblich.
    wie wäre es mit den alternativen aq, ay, as, a+b² oder gar +a ?

    @c/c++ vs asm: für windows-anwendungs programmierung weitgehend irrelevant, denn hier ist für den meisten sachen visual basic vorzuziehen oder für mathe ein matheprogramm, welches auch gleich plotten kann oder sinnvollere datentypen hat und genauer rechnen kann usw.

    0
  • B

    hast du dir schon
    http://www.dosbox.com/ angesehen?

    Jo, da hat mir gerade die heavydebug-Version sehr geholfen!
    Hat aber auch ein paar Mankos. Wenn's in die Interrupts im Real-mode geht, kann er keine 16-Bit disassemblieren - und der Debugger nimmt immer ein paar Schritte auf einmal und landet auch hinter Breakpoints. Ich habe die fertige Binary benutzt, das war nur Version 0.72. Möglicherweise ist das mittlerweile ausgemerzt.

    0
  • L

    for(i=0;i<N;i=i+2){a[i]=b[i]-1;c[i?0:1]=a[i];}

    Ich denk das problem sind hier nicht die (fehlenden) Leerzeichen sondern die fehlenden Zeilenumbrüche
    Aber wie heißt es schon im Linux kernel coding style

    Don't put multiple statements on a single line unless you have
    something to hide:

    0
  • A

    fließkommafreak schrieb:

    ...und wenn ich bei einem schon lange im gebrauch seienden system immer noch überflüssigerweise movl oder movb schreiben oder lesen muss oder soll, oder mainstreamfremde datentypenbezeichnungen, dann fühl ich mich vergessen.

    Wenn du damit die AT&T Syntax für die x86er meinst - die ist meiner Meinung nach die am besten durchdachte Syntax auf dieser Welt 🙂 Aber es ist wahr, dass die "movl" z.B. unnötig oft an den Stellen eingesetzt werden, wo sie überflüssig sind. Ich mache diesen Fehler auch und würde mich freuen, wenn ich hier im Forum eine Funktion in AT&T Syntax poste, jemand darauf reagieren und mich gleich korrigieren würde, genauso wie in deinem Beispiel mit dem Kind.

    linux_c89 schrieb:

    Aber wie heißt es schon im Linux kernel coding style

    Wenn du damit die Regeln in Documents/coding_style oder coding_rules (weiss jetzt nicht genau) meinst, da steht es glaube ich noch mehr drin, dass u.a. Kernighan und Ritchie Recht haben und dass Kernighan und Ritchie noch mal Recht haben 🙂 Und wenn du zufällig deren Buch "Programmieren in C" zur Hand hast - ich habe zufällig so eins ins Deutsche übersetzte aus dem Jahre 1983 - und in dem Buch mal blätterst, dann wirst du sehen: Alle Quelltexte sauber eingerückt und alle Leerzeichen da, wo sie auch hingehören. Vielleicht einer der Gründe für die Erfolgsgeschichte von C 😕

    0
  • L

    Jaja die unglaublich überzeugende Begründung

    but all right-thinking people know that (a) K&R are _right_ and (b) K&R are right

    Ich meinte eigentlich dass es hier wichtiger ist die Zeilenumbrüche zu machen als Leerzeichen. Mit Leerzeichen isses natürlich noch besser zu lesen
    Und ich glaube nicht dass C so erfolgreich ist weil es so leicht lesbar und sauber formatiert ist^^ (ich sag nur

    for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

    aus Humorseite)

    0
  • E

    die AT&T Syntax für die x86er ... - die ist meiner Meinung nach die am besten durchdachte Syntax auf dieser Welt

    Kannst Du das begründen?

    0
Anmelden zum Antworten