Compiler!

GPC

compiler! schrieb:

Macht der Compiler eigentlich das von mir beschriebene?

http://tutorial.schornboeck.net/compiler.htm

nman

compilerer schrieb:

Ich meine, dass es unter linux " gas " ist. Wie heißt die Prozessorsprache unter Windows?

Gas ist der GNU Assembler, der übersetzt aber genauso Assembly wie z.B. der NASM unter Windows, auch wenn er früher nur AT&T Assembler Syntax beherrschte und noch keine Intel-Syntax.

rüdiger

gas == GNU Assembler

Die meisten Compiler benutzen Assembler als zwischenstufe. Wie die Assemblersprache genau aussieht hängt hauptsächlich vom Prozessor ab. Aber die unterschiedlichen Assembler führen in der Regel diverse Macros, Anweisungen und Syntax Eigenheiten ein.

gas benutzt zB die AT&T Syntax, während nasm die nasm Syntax benutzt, was der unter x86er eher üblichen Intel-Syntax nachempfunden wurden.

Was bei den Assemblern rauskommt ist Maschinensprache, die auf dem gleichen Prozessor für alle Betriebssysteme gleich ist.

C++ Forumbot

Dieser Thread wurde von Moderator/in kingruedi aus dem Forum Rund um die Programmierung in das Forum Assembler verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Die meisten Compiler benutzen Assembler als zwischenstufe

Das möchte ich aber nicht. Die ausgngssprache ist ja schon Assembler. Wenn ich ein Assembler-compiler schreiben möchte: In welche sprache muss der ass-code "übbersetzt" werden?

Talla

Irgendwann ist Schluss mit den Sprachen, Assembler wird fast 1:1 in die entsprechenden Bytesequenzen übersetzt und außer 0 und 1 ist da nichts mehr.

Ominion

Stell dir mal vor du willst ein Programm, welches in C++ geschrieben wurde, kompilieren. Dann wandelt der Compiler also immer erst in Assembler und dann in die nächste Sprache um, welche noch näher am Prozessor ist als Assembler? Also wenn du so willst kommt nach Assembler noch die Bytesequenzen, welche nur aus 1 und 0 bestehen. Diese ist aber in allen Betriebssystemen gleich.

Mfg Ominion

PS: Früher hat man mit Lochkarten gearbeitet. Das heißt damals gab es noch keine Programmiersprachen. Jedem Loch wurde eine bestimmte Bytsequenz zugeordnet, die dann an den Prozessor geschickt wurde.

Stell dir mal vor du willst ein Programm, welches in C++ geschrieben wurde, kompilieren. Dann wandelt der Compiler also immer erst in Assembler und dann in die nächste Sprache um, welche noch näher am Prozessor ist als Assembler? Also wenn du so willst kommt nach Assembler noch die Bytesequenzen, welche nur aus 1 und 0 bestehen. Diese ist aber in allen Betriebssystemen gleich.

Also wandelt ein Assembler-Compiler den assemblercode i assembler um? Von assembler zu assembler? Ihrgendwie nicht zu glauben
Bitte um erklärung

Ominion

Ich habe geschrieben, dass der C++-Compiler in Assembler umwandelt, und nicht der Assemblercompiler.

Mfg Ominion

Ich habe geschrieben, dass de C++-Compiler in Assembler umwandelr, und nicht der Assemblercompiler.

Ja, und meine Frage weiß man ja schon.

PS: Danke für deine antwort im a là TGGC - Stile , .....

Ominion

Nein tut er nicht. Ich dachte du hast das mit C++ vielleicht überlesen, und habe dich deshalb nochmal darauf hingewiesen.

Mfg Ominion

rüdiger

compiler! schrieb:

Die meisten Compiler benutzen Assembler als zwischenstufe
Das möchte ich aber nicht. Die ausgngssprache ist ja schon Assembler. Wenn ich ein Assembler-compiler schreiben möchte: In welche sprache muss der ass-code "übbersetzt" werden?

Danach gibt es keine Programmiersprache, sondern nur Opcode. Das wurde ja bereits erklärt. Wenn du wissen willst wie du direkt mit Opcodes programmieren kannst, dann besorg dir von deinem Hardware Hersteller die entsprechenden CPU Beschreibungen (kann man idr. kostenlos auf der Hersteller Homepage als PDF und oft auch als Buch erhalten). Die Opcodes werden vom Prozessor direkt gelesen und verarbeitet.

C++ kompilieren läuft also in vielen Fällen so ab: C++ -> Assembler -> Opcode

wobei je nachdem noch Linkervorstufen erzeugt werden, aber das ist ja erstmal uninteressant.

Danach gibt es keine Programmiersprache, sondern nur Opcode. Das wurde ja bereits erklärt. Wenn du wissen willst wie du direkt mit Opcodes programmieren kannst, dann besorg dir von deinem Hardware Hersteller die entsprechenden CPU Beschreibungen (kann man idr. kostenlos auf der Hersteller Homepage als PDF und oft auch als Buch erhalten). Die Opcodes werden vom Prozessor direkt gelesen und verarbeitet.

Die Opcode sind dan aber von Prozessor zu Prozessor unterschiedlich, oder?

rüdiger

compiler! schrieb:

Die Opcode sind dan aber von Prozessor zu Prozessor unterschiedlich, oder?

Kommt drauf an. Die meisten Prozessoren sind kompatibel mit ihren Vorgängern. PC Prozessoren sind ja abwärts kompatibel bis hin zu den erster 8086ern. (Was fast über 30 Jahre her ist und zu vielen macken in der PC Architektur geführt hat).

Ominion

Ein Problem ist nur, dass du teilweise zum Beispiel nicht einmal den selben Code den du für ein Pentium verwendet hast, für einen Celeron verwenden kannst. Das heißt es kann dir auch passieren, dass wenn du zwei Prozessoren vom gleichen Hersteller hast, aber die unterschiedliche Typen haben, dass du dort andere Bytesequenzen verwenden musst.

Mfg Ominion

Ein Problem ist nur, dass du teilweise zum Beispiel nicht einmal den selben Code den du für ein Pentium verwendet hast, für einen Celeron verwenden kannst. Das heißt es kann dir auch passieren, dass wenn du zwei Prozessoren vom gleichen Hersteller hast, aber die unterschiedliche Typen haben, dass du dort andere Bytesequenzen verwenden musst.

Hö, hab ich was verpasst? Microsoft wird für jeden Prozessor natürlich ein eigenes Windows schreiben
Du hast insofern Recht,dass sich die Opcodes bei der x86-Architektur von Generation zu Generation unterscheiden können. Aber auch nur, weil diverse Erweiterungen(z.B. MMX, SSE etc.) oder weitere Befehle integriert wurden. Natürlich kannst du dann die Opcodes der MMX unterstützenden Prozessoren nicht bei älteren x86-CPUs verwenden, da der Prozessor die Opcodes halt nicht "kennt". Aber zwischen Celeron und einem "normalen" Pentium besteht normalerweise kein Unterschied, sofern Pentium und Celeron der gleichen Prozessor-Generation angehören. Und Intel würde sich selbst nicht gut tun, bei Prozessoren einer Architektur auch noch total verschiedene Opcodes zu verwenden.

Anders sieht es dann bei Prozessoren wie dem Itanium aus, der afaik eine ganz andere Architektur verwendet, als die "herkömmliche" x86 Architektur. Dort sehen die Opcodes dann auch anders aus.