Ist es theoretisch möglich jedes Programm in Assembler zu schreiben?
-
sj schrieb:
Kann der Compiler zaubern?
Um die Frage ein für allemal zu klären: Ja.
Was dachtest du sonst, wie der allererste Computer programmiert wurde?
-
sj schrieb:
Aber wer hat dem das denn beigebracht? Kann der Compiler zaubern? Und wo sind die Libs dafür? In welchen Dateien steht der original Assemblercode? Den will ich haben. Kann doch nicht so schwer zu verstehen sein.
Der Compiler ist in der Lage, C++ Code zu verstehen - und im Compiler ist auch hinterlegt, was er aus den C++ Anweisungen machen soll. Sowas kann man nicht zwischen Tür und Angel erklären, dafür empfehle ich mal ein Buch zum Thema Compilerbau.
(oder du schaust dir den Compiler auch mal in Assember an :D)
-
SeppJ schrieb:
Ja.
@TE
Der erste Assembler (Compiler für Assembler) wurde in Bytecode geschrieben. Der erste Compiler einer Sprache entweder in Assembler oder in einer Sprache, für die bereits ein Compiler existierte. So baut man von unten nach oben Funktionalität aus. Verstanden?
-
sj schrieb:
Aber wer hat dem das denn beigebracht?
Die Programmierer des Compilers.
Und wo sind die Libs dafür? In welchen Dateien steht der original Assemblercode?
Der Compiler ist die "Lib".
-
Mal andersrum, wenn ich also alle Funktionen von C++ in Assembler haben möchte, muss ich alle Funktionen compilieren und diese dann von Hand speichern, so daß ich alle Funktionen als Assembler-Source-Code habe?
Ansonsten geb ich's auf, danke.
-
Einmal noch, habt ihr schon mal ein Disassemblat gesehen ohne Debuginfos? Na toll, schein ja ein Militärgeheimnis zu sein
-
Darf man fragen, was du überhaupt vorhast?
(praktisch gesehen: Der Compiler arbeitet nicht mit "Funktionen", sondern mit Sprach-Bestandteilen - für jedes Konstrukt, das in der Sprache vorgesehen ist, gibt es Möglichkeiten, es in Maschinencode darzustellen. Und genau das macht der Compiler, wenn du ihm einen Quellcode vorsetzt (natürlich muß er zunächst die verwendeten Sprachmittel identifizieren))
-
Alle Standardfunktionen (das heißt "richtige" Funktionen, also alles, was zum Beispiel hier erwähnt wird) sind in der C(++) Laufzeitbibliothek. Die kannst du dir einfach angucken oder disassemblieren, davon ist (in der Regel) sogar der (in C(++) geschriebene) Quelltext verfügbar. Da stehen aber nicht so Sachen drin, wie zum Beispiel zwei Zahlen addiert werden, so ein triviales Zeugs ist im Compiler selber eingebaut.
-
Man programmiert doch nur noch z.B.
int main () {ifstream infile;
infile.open ("test.txt", ifstream::in);
...
und keiner weiß, was eigentlich passiert, und keinen interessierts, funktioniert doch prima. Ich will aber gerade wissen was der Rechner, z.b. bei infile.open(... eigentlich macht, und wenn ich will, programmiere/optimiere(haha) ich einfach den Assembler-Code. Der Thread war mir einfach nicht ausreichend beantwortet.
Ich werde ins Assembler-Forum wechseln...
Aber Danke für die Hilfe.
-
Wie ich schon gesagt habe, wenn dich die Innereien des Compilers interessieren, solltest du dir mal etwas Literatur zum Thema Compilerbau suchen. Sowas haben kluge Leute sehr ausführlich durchdacht, damit wir als 08/15-Programmierer uns nicht mehr um die Details kümmern müssen.
PS: bei ifstream::open() kannst du sogar das Glück haben, daß du die Funktion in Reinform in den System-Headern vorfindest - einfach mal umschauen
-
sj schrieb:
Ich will aber gerade wissen was der Rechner, z.b. bei infile.open(... eigentlich macht
Ich würde fast vermuten, dass der C Code aufruft.
Wenn dich solche Funktionen interessieren, dann lerne halt Assembler. Wenn du schon etwas kannst, könnte das ganz interessant sein.
-
Wo ist bitte dein Problem?
Am Anfang gab es nur Maschinencode und man musste mühselig aus Zuständen (Aus, An; 0, 1) Programme schreiben. Eine bestimmte Folge dieser Zustände war dann ein Befehl, den der Prozessor verstanden hat. Daraufhin hat er z.B. in ein Register geschrieben, etc.
Das war zu mühselig also hat man angefangen aus diesen Codes ein Assembler zu bauen, der anstatt der Zahlen lesbare Befehle verstand...
Das ging einige Zeit ganz gut, aber irgendwann war auch das zu langwierig und zu fehleranfällig.
Es kamen die Hochsprachen, wie z.B. die Programmiersprache C.
Diese Sprachen machen nichts anderes als wieder den Maschinencode zu generieren, den es schon seit Anfang an gibt.
Deine Sachen mit Dateien öffnen, etc. sind allerdings Betriebssystemspezifisch. Hier wird einfach ein Befehl abgesetzt, der dem Betriebssystem sagt, das man das möchte
-
cooky451 : Vielen Dank, das ist ein Link der mir wirklich sehr gefällt, da werd ich erst mal Stunden lang lesen. Ich komme halt noch von Old-School-Dos, muss ne Menge nachholen.
Ihr könnt ja mal hier reinschauen oder lasst es...
http://www.file-upload.net/download-3592694/spacy.rar.html
sind Sachen von mir. Vielleicht Schrott, vielleicht gut(e Ideen), was solls interessiert eh keinen...
-
sj schrieb:
Mal andersrum, wenn ich also alle Funktionen von C++ in Assembler haben möchte, muss ich alle Funktionen compilieren und diese dann von Hand speichern, so daß ich alle Funktionen als Assembler-Source-Code habe?
Ansonsten geb ich's auf, danke.Nein, das kann man so nicht sagen.
C++ Code kann vom Compiler auf verschiedene Arten in Assembler bzw. (wenn's direkt läuft) Maschinencode umgewandelt werden.
Der C++ Compiler ist in der Lage zu optimieren und bestimmte Codeteile so zu arrangieren, daß z.b. für eine Funktion einmal die SSE Einheit verwendet wird und ein andermal die FPU.Dementsprechend kann man C++ Funktionen nicht 1:1 auf ganz bestimmte Assemblerbefehle bzw. Maschinenopcodes abbilden.
D.h. es ist eher ein 1:n.Bei Assembler und Maschinenopcodes ist das anders, da ist es wirklich 1:1.
Aber bei C++ sind aufgrund seiner abstrakten Eigenheit halt viele Wege möglich.Und genau deswegen ergibt ein cout auf dem einen C++ Compiler ein völlig anderer Maschinencode, als auf einem anderen C++ Compiler.
Wenn du also mit z.b. dem Compiler von Visual Studio compilate von diversen C++ Funktionen erstellst, dann sind die noch lange nicht identisch mit denen, des GCC oder Intel Compilers.
Die Compilate sind nichtmal die selben, wenn du für verschiedene CPUs optimierst.
Für nen Penitum wird der Compiler immer anderen Code erzeugen als z.B. für einen Core2Duo.Als Beispiel diese For Schleife:
for (int i=0; i < 2; i++) { a = a + 1; }
Könnte der Compiler z.b. entweder in Maschinencode eine Schleife schreiben, die bis auf 2 hochzählt, oder er könnte den gleichen Befehl a = a + 1 einfach 2 mal im Maschinencode einbauen. Das Ergebis wäre das selbe.
Und ganz schlaue Compiler optimnieren die Schleife ganz weg und machen ein
a = a + 2 draus.
Auch hier wäre das Ergebnis das selbe.Deswegen bringt es nichts, alle C++ Funktionen in Assembler umzuwandeln und dann mit diesen Assemblerbruchstücken manuell ein Programm zusammenzufrickeln.
Dein Code dürfte dann nämlich deutlich langsamer sein, als wenn du einfach C++
Code schreibst und vom Compiler optimieren läßt.Und schaut man sich die Weiterentwicklung von Hochsprachen an, z.b. Java und C#, dann geht es da noch einen Schritt weiter, denn da optimieren die Virtual Machines sogar zur Laufzeit.
Mit C++ Code der als fertigen Maschinencode compiliert wird, geht das nicht, denn der wird nicht mehr zur Laufzeit compiliert, sondern vorher.
-
Man kann es auch umgekehrt machen:
z.B.:
http://drdobbs.com/blogs/architecture-and-design/228701319so theoretisch ist also die Frage gar nicht.