Binär?

Daedalus333

Ensign
Dabei seit
Okt. 2007
Beiträge
147
Hi leute,

ich hätt da mal ne kleine frage. ich versuche gerade anhand von video2brain, c++ zu lernen/verstehen. recherchiere nebenher auch einzelne stichworte im internet, entdeckte dann auch Richard Stallman, der ja die "gnu" gegründet hat. jetzt hab ich, in dem wiki text von ihm gelesen:

"Viele Firmen begannen, Software nicht mehr in der bis dahin weitgehend üblichen Form von Quelltexten auszuliefern, sondern in Form eines rein maschinenlesbaren Formates, dem sogenannten binären Format."

stallman hat das genervt, weil man dadurch die programme nicht mehr selber umändern konnte, oder? aber ich denke das binärformat ist doch maschinenlesbar, also kann/konnte man es umändern? oder hab ich da einfach nur was falsch verstanden? wenn es in "rein maschinenlesbaren format" ausgeliefert wird, dann heist es, es ist schon kompiliert oder? denn das vor dem kompilieren, ist ja der quelltext. das heist man kann es nicht mehr zurückkompilieren? ich hoffe ich habe mich verständlich ausgedrückt, mfg daedalus333
 
Im Grunde werden Anwendungen beim Kompilieren nur Abgewandelt. Du kannst aus diesen Anwendungen tatsächlich noch etwas auslesen, allerdings nur aus dem Maschinencode, also dem Assembler. Google mal danach.

mfg,
Markus
 
Ein Compiler überstetzt das ganze in Assemblercode, der für Menschen noch halbwegs lesbar ist.
Das ist aber eigentlich auch nicht der Maschinencode. Der entsteht nach dem Assemblieren und macht dann aus sowas wie "MOVE #$4F3B,D2" sowas wie "01101010001010101011010101010" was dann der Maschinen- oder Bytecode ist.
Du kannst dir vorstellen, dass jede 0 und jede 1 der CPU sagt, welche Steuersignale sie aktivieren / nicht aktivieren soll usw., um das mal sehr oberflächlich zu formulieren. Im Prinzip sieht aber JEDER Befehl und jede Aktion im Rechner aus.
Und das können glaub ich nur ganz wenige Menschen lesen ;)
 
danke erstmal für eure antworten - das heist, dadurch das die firmen die software nur noch im maschinenlesbaren format rausgebracht haben, war die software nicht mehr zu lesen, und damit auch nicht mehr veränderbar? dieses "010101010010" nennt man also dann den binärcode? das, was der compiler dann aus deinem quelltext macht oder wie? @skeemo: ach deshalb nennt man assembler, wie ich grad gelesen habe, "programmierwerkzeug" - weil es der vorgang vor dem "kompletten" kompilieren ist? was zum schluss der maschinencode ist, ist dann wohl die exe oder? ich bin da noch ziemlich neu drin, und hab das gefühl das man da nie ganz überblicken kann/wird? wie sieht das aus? wahrscheinlich liege ich da falsch, man muss wohl erst ziemlich viel aufgreifen und lernen, und es kommt stück für stück oder?

edit: also der compilervorgang besteht daraus, das der quelltext erstmal assembliert wird oder? und danach wird er in maschinensprache kompiliert? nur ums nochmal genau zu sagen?^^
 
Also nochmal ganz langsam :)

1. Man schreibt ein Programm in einer sog. Hochsprache, z.b. C++. Eine Hochsprache kennzeichnet sich dadurch, dass die Programme sehr gut lesbar sind und sich der Aufbau von Programmen einfach nachvollziehen lässt. Das sieht ungefähr so aus :

"fprintf(stdout, "Hallo Welt\n");"

Was so viel heisst wie :
"Gib die Zeichenkette in den "" auf dem Bildschirm/Standardausgabe aus".
Aber : die CPU "kennt" den Bildschirm nicht als solchen, sie weiss nur dass an den und den Pins eine Peripherie namens Grafikkarte ist, die er addressieren kann. Daher...


2. ...Man kompiliert diesen Quellcode, der Compiler baut dort im Erstansatz Assemblercode draus.
Der ist schon sehr maschinennah, denn hier gibt es nur Befehle wie

"Schiebe den Inhalt von Speicherzelle A nach Speicherzelle B"

oder einfache Vergleiche wie

"Wenn Inhalt von Register D1 gleich Null ist dann mache an Stelle XY weiter", also bedingte Sprünge.




3. Man assembliert den Assemblercode (das macht der Hochsprachencompiler aber auch für den Programmierer !) und heraus kommt der Byte- / Maschinen- oder Binärcode. Und nur dessen Bitmuster versteht der Rechner dann wirklich.




Früher (ganz früher) gab es noch keine Hochsprachen, ganz ganz früher gab es sogar nicht mal Assembler.
Da haben die Programmierer (die zugleich die Anwender waren) die Rechner tatsächlich mit Binärprogrammen gefüttert.
Vielleicht hast du schon mal was von "Lochkarten" gehört, wobei die Information "Loch" oder "kein Loch" ja sehr anschaulich eine binäre Information ist.

Als die Rechner immer kleiner wurden (Mikroprozesser) kamen dann die Assembler, und weil das eigentlich immer noch sehr kompliziert ist, wurden irgendwann Hochsprachen erfunden.

Also um es zusammenzufassen :

Hochsprachen-Quellcode --> Compiler --> Assembler-Quellcode --> Assembler --> Bytecode.


Naja die EXE ist irgendwie schon der Maschinencode, die EXEn heissen auch "Binaries", kannst ja mal eine mitm Notepad aufmachen ;) (aber nicht abspeichern !)
 
ja, lochkarten sagen mir was, in der zeit der 70er ungefähr?^^das mit dem binärcode versteh ich, die cpu versteht nur einsen und nullen, das ist es was im endeffekt der compiler mit meinem in der programmiersprache geschriebenen quelltext macht. der macht zuerst nen assemblercode draus, dieser wird dann nochmal assembliert, und daraus wird dann der maschinencode, also das "01010101010"? und so ähnlich wie die lochkarten funktionieren doch auch disketten oder? ich meine, video2brain erklärt das zwar, aber bleiben viele begriffe irgendwie im dunkeln, ich glaube da muss ich dann halt einfach selber nachgucken, so krieg ichs dann auch besser hin. du scheinst es ja ganz gut draufzuhaben, hast dus auch so gelernt?
 
seit wann heissen executables binaries.. und wenn ich ne exe aufmache mit notepad kommt da garantiert kein binärcode bei raus.
 
Zitat von skeemo:
Ein Compiler überstetzt das ganze in Assemblercode, der für Menschen noch halbwegs lesbar ist.

Nein. Ein Compiler ist zunächst nichts anderes als ein Übersetzer der ein in einer Quellsprache geschriebenes Programm in ein semantisch äquivalentes Programm einer Zielsprache umwandelt.

Das kann Maschinencode sein, das kann aber auch Bytcode sein oder etwas anderes. In Assemblercode wird dabei aber sicherlich nicht übersetzt.

Zitat von skeemo:
Das ist aber eigentlich auch nicht der Maschinencode. Der entsteht nach dem Assemblieren und macht dann aus sowas wie "MOVE #$4F3B,D2" sowas wie "01101010001010101011010101010" was dann der Maschinen- oder Bytecode ist.

Nein. Der Compiler erzeugt auch direkt Maschinencode. Ein Compiler, der Assemblersprache in Maschinencode übersetzt heißt Assembler. Ein Assembler ist also ein spezieller Compiler, nichts anderes.

Dabei entsteht auch nicht Bytecode. Bytecode bezeichnet Code, der von einer VM ausgeführt wird!

Es gibt heute verschiedene Assembler, die teilweise Hochsprachenkonstrukte gestatten, wie beispielsweise der NASM.

Der klassische Assembler ist aber nichts anderes als ein sehr einfacher Interpreter. Der Assemblerprogrammierer nutzt dabei die sogenannten Mnemonics. Eine Assemblersprache ist eine spezielle Programmiersprache, welche die Maschinensprache einer spezifischen Prozessorarchitektur in einer für den Menschen lesbaren Form repräsentiert.

Die klassische Assemblersprache ist also bereits Maschinencode, nur in einer für den Menschen lesbaren Notation. Die Mnemonics werden direkt in den Maschinencode der CPU abgebildet. Grundlage für die Abbildung ist die Befehlsatztabelle mit den Hexopcodes.

Der Befehl

Code:
MOV  AH, 0

ist daher ein Befehl der bereits in Maschinencode vorliegt. Es handelt sich nur um eine für den Menschen lesbare Form. Ein IA-32 Assembler muss im Gegensatz zu einem Hochsprachencompiler nicht den Befehl mittels lexikalischer, semantischer und syntaktischer Analyse zerlegen, er muss nur den Befehl mit der Tabelle in seine Hexnotation abbilden. Eine wirkliche Umformung von Befehlen in einzelne Befehlssequenzen (wie bei der Compilierung aus Hochsprachen) findet dabei nicht statt.

Es spielt daher keine Rolle, ob ich bei einem 8088 Satz

Code:
MOV AX,0005

oder

Code:
B80500

oder

Code:
101110000000010100000000

schreibe. Das ist derselbe Mist, in einer anderen Form. Nur das ich dank Mnemonics den Kram deutlich besser lesen und verstehen kann.

Das ist übrigens der Grund, warum ich jedes native Programm disassemblieren kann. Ich bringe es nur in eine lesbare Form. Die Daten liegen bereits in einer 1:1 Abbildung vor.
 
Zuletzt bearbeitet:
@ green_mamba
thx für die aufklärung - stand echt auf dem schlauch :lol:
 

Ähnliche Themen

Zurück
Top