Frage zu Assembler und der Syntax

nachtfeuer

void** schrieb:

Hallo,

Wieso kann man z.b. die meiste Hardware nur mit Assembler ansprechen ?

Das stimmt so nicht, die "Hochsprachen" sind ja dafür da, die Hardware auf andere Weise anzusprechen als mit Assembler oder mit Hexcodeeingaben. Wie würde Windows funktionieren, wenn es mit seinem Hochsprachencode keinen Einfluss auf "die Hardware" hätte?

void** schrieb:

Warum hat Assembler z.b. eine Syntax wie:

mov eax,1
push eax

Hat Assembler solch eine Syntax bekommen weil es früher dadurch einfach leichter zu kennzeichnen war welchem Bauteil man welche Stromimpulse gesendet hat ?

Die beiden Befehle bewirken unterschiedliche Arbeitsweisen, darum heißen sie anders. Inwieweit Push und Pop jetzt so heißen und nicht Stacki und Stacko oder Blitz etc. weiß ich auch nicht so genau, man kann es sich aber denken, wenn man die Arbeitsweise des Stacks kennt.

mov eax,1 könnte man direkt mit Schaltern realisieren, die Schalterstellungen werden binär codiert:

1011100000000001000000000000000000000000

nun gibt es aber beim Pentium über 1000 unterschiedliche Befehle. Viel Spaß beim Bearbeiten komplexer Programme...
Eine kleine Hilfe ist das Hexadezimalzahlensystem,
mov eax,1 hexcodiert:

B801000000

schon besser, denn ein Hexwert kann 4 Bits zusammenfassen. Zum Editieren von Spielständen sehr praktisch. Aber viel Spaß beim Bearbeiten oder Erstellen oder gar Braindebuggen komplexer Progamme...

der Befehl

mov eax,1

zeigt auf den ersten Blick, worum es geht.
Push eax zeigt Insidern sofort worum es geht.
Assemblerroutinen versteht man dagegen nicht gleich auf den ersten Blick, man braucht Dokumentation. Da diese oft vergessen wird: viel Spaß beim Bearbeiten komplexer Programme, die nicht gut strukturiert und dokumentiert sind, vor allem, wenn die Maschinen selbst ganz unterschiedlich sein können oder das Betriebssystem direkte Hardwarezugriffe z.B. auf Ports und Prozessormodes weitgehend aussperrt.

Programmierung und Programmierschnittstellen an sich, hängen meistens direkt mit der Hardware oder dem Betriebssystem der Doku und dem Mainstream usw. zusammen.
Ein bißchen seltsam ist die Hello World praxis in einer von Audio und Video und Mathematik bestimmten Multimediarechenwelt.

Kennt hier jemand eigentlich den Song Jasmine and Rose?
http://www.youtube.com/watch?v=HdIGw8k19n4

Mir ist in diesem Zusammenhang aufgefallen, das die Bekanntschaft mit Jasmin http://www.lrr.in.tum.de/~jasmin/ und Jazelle http://en.wikipedia.org/wiki/Jazelle gar keine so schlechte ist.

(Und ein Geheimnis ist (pssst!) Asm Grundlagen lassen sich leichter lernen als Hochsprachengrundlagen. Manche Hochsprachengrundlagen lassen sich leichter verstehen, wenn man Asm-Grundlagen schon kann.(/pssssssst)

Nobuo T

void** schrieb:

Das hier http://www.visual6502.org/JSSim/index.html sieht ja sehr Interessant aus leider sagt mir das ganze gar nix. ^^

Und wofür ist dieser Hex Editor da auf der Rechten Seite ?

Ich hab da einfach mal irgendwelche Werte eingeben und dann auf den Start Button geklick aber ich konnte keine veränderungen festellen. ( Warscheinlich weil ich 0 Ahnung davon habe ^^ )

Jo, das Ding ist toll.

Auf der rechten Seite siehst du den Inhalt eines an die CPU angeschlossenen RAM in Form von Hex-Zahlen. Die CPU faengt dann an, ganz oben Links bei Adresse 0 den RAM auszulesen und das Gelesene auszufuehren.
In der Grafik links kannst du dann eine Darstellung des DIE der CPU sehen. Leitungen, auf denen eine "1" liegt, werden darin scheinbar rot dargestellt...
Den Code im RAM kannst du dann Schritt fuer Schritt ausfuehren lassen und dir zusaetzlich ueber der Darstellung des RAM ansehen, was in den Registern steht.

linux_c89

Ich meinte mit Assembler natürlich Maschinencode sorry.
Der Unterschied von der Komplexität ist der:
Es ist recht einfach einen Chip zu bauen der eine Zahl in ein register schiebt. Es ist sehr kompliziert einen Chip zu bauen der a) Text versteht b) variablennamen auf register und Speicher abbildet und c) dann noch kompliziertere ausdrücke wie a=b=0; verarbeitet
Deshalb kann der Prozessor

mov eax,1

(bzw. den maschinenbefehl dazu, also eine Zahl) d.h. lege an das Register eax so Strom an dass nachher eine 1 drinsteht aber nicht

a=1;

(was zur Hölle ist a und überhaupt was sollen diese 4 Zahlen 0x61 0x3D 0x31 0x3B bedeuten)

void** schrieb:
Hallo,

Wieso kann man z.b. die meiste Hardware nur mit Assembler ansprechen ?

Das stimmt so nicht, die "Hochsprachen" sind ja dafür da, die Hardware auf andere Weise anzusprechen als mit Assembler oder mit Hexcodeeingaben. Wie würde Winddows funktionieren, wenn es mit seinem Hochsprachencode keinen Einfluss auf "die Hardware" hätte?

Mit Hochsprachen kann man Hardware ansprechen weil der Compiler den text in Maschinensprache übersetzt (auch wenn man natürlich in manchen Einsatzbereichen Assembler nutzen _muss_ weil es (noch) keine Funktionen zum Ansprechen gibt.
Die Teile die auf die Hardware zugreifen sind übrigends in assembler geschrieben
Es gibt dann halt eine Schnittstelle zwischen dem Hochsprachencode und dem Assemblercode

abc.w

Man, habt ihr Probleme
Ich würde vielleicht gerne wissen, warum man die Syntax so gemacht hat, dass man zum Teil von rechts nach links lesen muss...
Warum "mov eax, 1" und nicht "mov 1, eax" wobei man natürlich irgendwie noch zwischen Displacements unterscheiden muss, was bei AT&T Syntax mit $-Zeichen gemacht wird: "mov $1, %eax" (Konstante) und "mov 1, %eax" (Displacement).
Und dann habe ich noch ein Problem, warum vergessen viele nach dem Komma ein Leerzeichen zu setzen
Warum "mov eax,1" und nicht "mov eax, 1" Ich finde ein Komma ohne Leerzeichen danach irgendwie störend... ja, es stört den Lesefluss...

linux_c89

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)

abc.w

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...

linux_c89

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

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?

linux_c89

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

Bitsy

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...

CCodex

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

SideWinder

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

Nobuo T

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.

CCodex

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?

Nobuo T

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...

Bitsy

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.

linux_c89

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(++)

abc.w

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...

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.

Bitsy

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.