Mega verständlich erklärt mit einer sehr angenehm anzuhörenden Stimme. Bin bei Minute 6 und die sechs Minuten kamen mir vor wie eine. Und wäre es nicht 3 Uhr morgens und müsste ich morgen/gleich nicht früh raus, würde ich das Video zu Ende schauen und den Rest des Kanals durchforsten haha Habe aber direkt abonniert^^
Hallo Herr Wilkens, vielen Dank für die Videos! Als kleiner Tipp: es wäre hilfreich, wenn Sie die URLs wie z.B. bei 13:33 zusätzlich in der Videobeschreibung verlinken. Viele Grüße
Das Video soll eine erste Idee vermitteln, was mit Quellcode "in etwa" passiert, und wie daraus Maschinensprache wird, die dann auf der CPU ausgeführt werden kann. Es ist konzipiert für Studierende ohne großes Vorwissen in diesem Bereich. In dem Beispiel aus dem Video hat jeder Befehl eine Länge von 16 Bit = 2 Byte. Es ist klar, dass heute aktuelle CPUs andere Befehlssätze haben, und auch sonst extrem optimiert sind. Das lässt sich in einem Video von wenigen Minuten Länge aber nicht in aller Ausführlichkeit zeigen. Insbesondere wird hier ja auch keine konkrete CPU erläutert. Das Video vereinfacht also bewusst die Situation, damit eine erste Vorstellung entstehen kann.
@@maxmuster7003 Der Kommentar kommt vielleicht ein bisschen spät, aber ich habe das Video erst jetzt entdeckt. Ja, es stimmt, dadurch dass ein virtueller Prozessor zur Erklärung verwendet wird ist später in der Praxis ein zusätzlicher Abstraktionsschritt notwendig wenn es um die Arbeit mit einer konkreten CPU (sagen wir x386) geht. Um aber zu verstehen wie Maschinencode GRUNDSÄTZLICH funktioniert ist dieses Beispiel ziemlich gut, weil die Befehlskodierung sehr logisch und einfach strukturiert ist und es auch nicht hunderte unterschiedliche (wenn auch ähnliche) Befehle gibt, was das Verstehen sher vereinfacht. Wer schon ein wenig Vorwissen besitzt und aufmerksam das Video schaut wird auch bemerken, dass die Befehlsstruktur wie hier dargestellt eigentlich gar keinen Sinn macht, denn: 1. Wozu sollte eine 16 Bit CPU Befehle benutzen die nur 128 Byte addressieren kann? 2. Wozu 5 Bit "Reserve" bei der CPU unbenutzt lassen, was eine unglaubliche Verschwendung von Resourcen ist, wenn selbst 8bit CPUs aus den 70er Jahren 16bit Befehle verstehen und verarbeiten können? Im Grunde ist alles an dieser CPU verkehrt herum, eine 16 bit CPU die 16bit Befehle benutzt, sprich sie könnte THEORETISCH 65536 Befehle benutzen, aber nur einem addressierbaren Speicherplatz von 128 Byte? Ausserdem scheint es so zu sein und das ist der mutmaßliche Punkt 3, dass diese CPU nur ein Register benutzt, denn sonst würde man ja die Werte aus dem Akkumulator nicht in den (ohnehin) knappen Speicherplatz laden, sondern in ein weiteres Register, was zudem auch viel schneller wäre als den Umweg über das RAM zu benutzen. Alles an diesem Video weist also darauf hin, dass es auf ein grundsätzliches Verstehen der Arbeitsweise einer (generischen) CPU und deren Machinensprache geht, nicht um das erlernen eines konkreten Maschinencodes für eine Bestimmte Sorte von Computern.
@@kellerkind6169 Ich stimme zu, gut geschrieben. Ich selber habe bevor ich einen eigenen Computer hatte viele Bücher über Computer gelesen alle auf englisch. Ich kannte am Anfang noch kein einziges Fachwort was dort benutzt wurde. Nach und nach habe ich erst verstanden welche Begriffe was bedeuten und Internet gab es noch nicht. Ich habe mir alles selber bei gebracht. Zu meiner Schulzeit gab es nur Taschenrechner und Großrechner und noch keine Computer für zu Hause. Heute ist es wirklich einfach an Informationen zu kommen. Z.B. Intel developer manual und auch Dokus von AMD.
Hallo Andreas, Du hast das super erklärt! Was ich nicht verstehe, das alles ist ja virtuell (auf dem Bildschirm sichtbar), wie kommt es den von der Virtualität zur Realität? Ich meine, da müssen Minitransistoren mit Strom angesprochen/ gesteuert werden, an oder aus. Wie funktioniert das? Grüsse Timo
Hallo Timo, das ist natürlich kompliziert und nicht mit ein paar Zeilen erklärt. Aber einen guten Einstieg liefert dir diese Seite vfhcab.eduloop.de/loop/Computerarchitektur_und_Betriebssysteme
Gibt es bei modernen Prozessoren noch weitere "Num" Varianten, also ist dort die Definition von "int", "char", "float", "bool" etc. verortet? Vermutlich gibt es auch mehr Befehle und daher eine größere Befehlsbreite oder zumindest weniger Reserve?
Hallo, ja, die Befehlsbreite ist bei modernen CPUs tatsächlich größer. Da jeder CPU-Hersteller hier eigene Entwicklungen hat, empfehle ich bei Bedarf den Blick in die jeweilige CPU-Spezifikation, sofern diese veröffentlicht wurde.
Befehle werden nicht *auf* einem Accumulator ausgeführt, sondern mit einem. Das bedeutet, dass der Accumulator oft Ziel und Quelle einer Operation ist und solche Befehle nur über und mit dem Accumulator ausgeführt werden können. Ich finde die andere Beschreibung etwas unglücklich gewählt.
Gutes Video für einen ahnungslosen. Mir ist aufgefallen dass in Maschinensprache wie Assembler der Speicherort angegeben wird, im Quelltext aber nicht, bedeutet das dass man nicht weiß in welcher Speicherzelle die Daten abgelegt werden?
Ja, das ist richtig. Die Verwaltung des Hauptspeichers ist eine der Aufgaben des Betriebssystems. Anwendungsprogramme haben keinen Einfluss darauf, wo genau im Hauptspeicher sie abgelegt werden. Durch den Einsatz der virtuellen Hauptspeicherverwaltung kann es sogar dazu kommen, dass bestimmte Teile des Hauptspeichers ausgelagert werden (auf die Festplatte), um kurze Zeit später wieder an anderer Stelle im RAM eingelagert zu werden. Dann hat sich die Speicherzelle, in welcher der Wert einer Variablen gespeichert ist, sogar während der Laufzeit der Anwendung verändert. Die Angabe einer Adresse in Maschinensprache oder in Assembler ist übrigens typischerweise eine "virtuelle Adresse", welche davon ausgeht, dass die Anwendung ab Adresse Null im Hauptspeicher abgelegt ist. Tatsächlich ist das durch den Einsatz der virtuellen Speicherverwaltung aber nicht gegeben. Die MMU (Memory Management Unit) rechnet ständig virtuelle Adressen in physische Adressen um, was bei Einsatz der virtuellen Speicherverwaltung so erforderlich ist.
Vielen Dank für die Antwort. Es ist unglaublich wieviel Dinge im Leben benutzt werden von denen keiner weiß wie sie funktionieren. Ohne Programmierer würde die Welt im Stand von 1960 sein. Ich glaube als Programmierer ist man König
Tip Nummer FhundertFundFzig: Um dezimale und hexadezimale Werte leichter beim Sprechen/Hören unterscheiden zu können, macht es Sinn die hexadezimalen Werte anders zu sagen. Beispiel für hex 13 eins drei und nicht dreizehn. Sonst müsste man andernfalls doch bei hex A2 zweiundazig, oder hex A0A ahunderta sagen, was sich schon etwas sonderbar anhören würde, da hundert bei hexadezimalen Werten = 64 hex keine höhere Stelle ergibt, sondern erst bei 256 bzw. FF+1. Daher lieber a zwei, oder a Null a. Das macht es leichter.
warum wird konstante erst in den acc geladen, von dort in den speicher, dann wieder in den acc, kann er nicht im accu bleiben, dann 2 konstante in den accu, dann addieren
Der Mensch programmiert den Quellcode, der Compiler übersetzt diesen in Maschinencode, die CPU führt den Maschinencode aus. Hätte der Mensch den Quellcode anders geschrieben, dann hätte der Compiler anderen Maschinencode erzeugt und die CPU hätte diesen anderen Maschinencode erzeugt. Denkbar wäre auch, dass der Mensch einen besseren Compiler schreibt, der Optimierungen bei der Übersetzung vom Quellcode in den Maschinencode vornimmt. Das ist in diesem Beispiel aber nicht von Belang, es geht um die Verdeutlichung der generellen Arbeitsweise.
Wäre nett wenn der Link am Ende des Videos als echter Link in der Beschreibung ist. Danke Hier: courses.cs.vt.edu/csonline/MachineArchitecture/Lessons/CPU/sumprogram.html
Moderne Computer arbeiten mit bytes (8bit) wie passt das mit dem Video zusammen ? Ist es dann abhängig von dem Befehl wie viele bytes geladen werden ? Oder beschreibt das im Video erklärte Prinzip befehle einer RISC CPU und mein genanntes Problem das CISC Prinzip ? Schon mal danke für Antworten ;)
Wie schon erwähnt wurde, diese CPU gibt es gar nicht. Somit ist das Video eher praxisfern gestaltet, was den Einstieg m.M.n. eher erschwert, da die gezeigten Dinge nicht an einer real existierenden CPU ausprobiert werden können, um einen darauf aufbaunden Lerneffekt zu erzielen, der durch die Programmierpraxis sich erst verfestigen läßt und ergibt.
@@maxmuster7003 Programmierpraxis? Du Programmierst doch auf einen viel höheren Abstraktionsgrad. Maximal für Assembler sinnvoll. Das Video ist super, um Theoretisch das Thema grundlegend anzuschneiden
@@hansimgluck505 Ich programmiere überwiegend in Assembler. Einen Compiler habe ich noch nie verwendet. Zum entwickeln und testen von neuen Formeln verwende ich einen BASIC interpreter und wenn es funktioniert schreibe ich damit eine Assembler-Routine.
16 Bit CPU, daher wird einfach alles zu 16bit Blöcken aufgespalten. Das mag ja für ARM-CPUs gelten, aber bei x86-CPUs ist NICHT jeder Befehl gleich lang.
Ein 16 bit *x86 code* in 16 bit aufzuspalten ist aber nicht wirklich sinnvoll, da die Befehle unterschiedlich viele Bytes je 8 Bit haben können und nicht alle Befehle nur 16 Bit haben. Das ist dann etwas anders als im Video gezeigt. Der erste Befehl könnte dann nur ein einziges Byte haben und ein anderer Befehl danach 3 Bytes. Dann wären in den ersten 16 Bit der erste Befehl mit 8 Bit und zusätzlich die ersten 8 Bit vom zweiten Befehl, der sich über die nächsten 16 Bit weiter fort setzt und auf verschiedene 16 Bit Blöcke aufgespalten ist. Intel 80386+ A closer look to the possible sorts of bytes of one instruction: Instruction Prefix 0 or 1 Byte Address-Size Prefix 0 or 1 Byte Operand-Size Prefix 0 or 1 Byte Segment Prefix 0 or 1 Byte Opcode 1 or 2 Byte Mod R/M 0 or 1 Byte SIB, Scale Index Base (386+) 0 or 1 Byte Displacement 0, 1, 2 or 4 Byte (4 only 386+) Immediate 0, 1, 2 or 4 Byte (4 only 386+) Format of Postbyte(Mod R/M from Intel-manual) ------------------------------------------ MM RRR MMM MM - Memory addressing mode RRR - Register operand address MMM - Memory operand address RRR Register Names Filds 8bit 16bit 32bit 000 AL AX EAX 001 CL CX ECX 010 DL DX EDX 011 Bl BX EBX 100 AH SP ESP 101 CH BP EBP 110 DH SI ESI 111 BH DI EDI --- (Note: We observe the next two tables from the 16 bit address mode. The D flag in the code-segment descriptor is not set. The default size of memory access and the operand size (without size prefixes) is 16 bit.) 16bit memory (No 32 bit memory address prefix) MMM Default MM Field Field Sreg 00 01 10 11=MMM is reg 000 DS [BX+SI] [BX+SI+o8] [BX+SI+o16] 001 DS [BX+DI] [BX+DI+o8] [BX+DI+o16] 010 SS [BP+SI] [BP+SI+o8] [BP+SI+o16] 011 SS [BP+DI] [BP+DI+o8] [BP+DI+o16] 100 DS [SI] [SI+o8] [SI+o16] 101 DS [DI] [DI+o8] [SI+o16] 110 SS [o16] [BP+o8] [BP+o16] 111 DS [BX] [BX+o8] [BX+o16] Note: MMM=110,MM=0 Default Sreg is DS !!!! 32bit memory (Has 67h 32 bit memory address prefix) MMM Default MM Field Field Sreg 00 01 10 11=MMM is reg 000 DS [EAX] [EAX+o8] [EAX+o32] 001 DS [ECX] [ECX+o8] [ECX+o32] 010 DS [EDX] [EDX+o8] [EDX+o32] 011 DS [EBX] [EBX+o8] [EBX+o32] 100 SIB [SIB] [SIB+o8] [SIB+o32] 101 SS [o32] [EBP+o8] [EBP+o32] 110 DS [ESI] [ESI+o8] [ESI+o32] 111 DS [EDI] [EDI+o8] [EDI+o32] Note: MMM=110,MM=0 Default Sreg is DS !!!! --- SIB is (Scale/Base/Index) SS BBB III Note: SIB address calculated as: =+*(2^(Scale)) Fild Default Base BBB Sreg Register Note 000 DS EAX 001 DS ECX 010 DS EDX 011 DS EBX 100 SS ESP 101 DS o32 if MM=00 (Postbyte) SS EBP if MM00 (Postbyte) 110 SS ESI 111 DS EDI Fild Index III register Note 000 EAX 001 ECX 010 EDX 011 EBX 100 never Index SS can be 00 101 EBP 110 ESI 111 EDI Fild Scale coefficient SS =2^(SS) 00 1 01 2 10 4 11 8 Was hier fehlt und nicht mit hinein passt in diesen Kommentar sind die Opcodes der verschiedenen x86er-Befehle und die Bytes der Befehls-Prefixe. Alles andere ergibt sich aus den Tabellen oben.
Max Muster: Jetzt bleib mal locker. Es wurde nicht ein einziger Kommentar von dir gelöscht. Jedenfalls nicht von mir. Und die einzigen beiden, die sonst noch etwas löschen könnten sind Google/TH-cam oder du selbst. Vielleicht stellst du mal die Sortierreihenfolge der Kommentare auf "Neueste zuerst".
@@AndreasWilkens Ok, danke das du dich dazu geäussert hast. Ich habe gestern 6 Kommentare geschrieben und in 3 davon etwas kritisiert und 4 wurden gelöscht. In einem davon habe ich Tabellen vom Intel Manual gepostet. Heute morgen waren nur noch 2 Kommentare übrig geblieben. Ich habe mir Mühe gegeben die Kommentare zu verfassen. Ich hoffe dass du meinen Frust über die Löschung verstehst. Ich glaube dir dass du daran unschuldig bist. Ich finde es eine bodenlose Frechheit daß so etwas passiert. Entschuldige bitte, wenn ich dich damit geärgert habe. Mehr kann ich nun auch nicht daran ändern. Ich nehme nun mein Daumen nach unten wieder zurück. Ich wünsche dir noch einen schönen Tag. Und lasse uns die Angelegenheit nun vergessen und begraben. Nochmal Danke, es tut gut deine Worte zu lesen. Mir bedeutet so etwas viel, besonders in dieser momentanen angespannten Lage und Situation in der wir uns befinden. Alles gute für dich.
@@maxmuster7003 Also ich sehe genau 3 Kommentrare von dir unter diesem Video, diesen nicht eingerechnet. Deine Inteltabelle sehe ich auch, leider ohne Erklärung nicht zu verstehen wenn man sich nicht mit prozessoren auskennt.
Mega verständlich erklärt mit einer sehr angenehm anzuhörenden Stimme. Bin bei Minute 6 und die sechs Minuten kamen mir vor wie eine. Und wäre es nicht 3 Uhr morgens und müsste ich morgen/gleich nicht früh raus, würde ich das Video zu Ende schauen und den Rest des Kanals durchforsten haha
Habe aber direkt abonniert^^
Daaaaaaaaaaannnkkkeeeeeeeee!!! Phantastisch erklärt. Ich habe das, was erklärt wurde verstanden. Richtig toll !! Danke.
Hallo Herr Wilkens,
vielen Dank für die Videos!
Als kleiner Tipp:
es wäre hilfreich, wenn Sie die URLs wie z.B. bei 13:33 zusätzlich in der Videobeschreibung verlinken.
Viele Grüße
Das Video soll eine erste Idee vermitteln, was mit Quellcode "in etwa" passiert, und wie daraus Maschinensprache wird, die dann auf der CPU ausgeführt werden kann. Es ist konzipiert für Studierende ohne großes Vorwissen in diesem Bereich.
In dem Beispiel aus dem Video hat jeder Befehl eine Länge von 16 Bit = 2 Byte.
Es ist klar, dass heute aktuelle CPUs andere Befehlssätze haben, und auch sonst extrem optimiert sind. Das lässt sich in einem Video von wenigen Minuten Länge aber nicht in aller Ausführlichkeit zeigen. Insbesondere wird hier ja auch keine konkrete CPU erläutert.
Das Video vereinfacht also bewusst die Situation, damit eine erste Vorstellung entstehen kann.
Ich denke eine bestimmte CPU in groben Zügen zu erklären wäre praxisnaher.
@@maxmuster7003 Der Kommentar kommt vielleicht ein bisschen spät, aber ich habe das Video erst jetzt entdeckt.
Ja, es stimmt, dadurch dass ein virtueller Prozessor zur Erklärung verwendet wird ist später in der Praxis ein zusätzlicher Abstraktionsschritt notwendig wenn es um die Arbeit mit einer konkreten CPU (sagen wir x386) geht.
Um aber zu verstehen wie Maschinencode GRUNDSÄTZLICH funktioniert ist dieses Beispiel ziemlich gut, weil die Befehlskodierung sehr logisch und einfach strukturiert ist und es auch nicht hunderte unterschiedliche (wenn auch ähnliche) Befehle gibt, was das Verstehen sher vereinfacht.
Wer schon ein wenig Vorwissen besitzt und aufmerksam das Video schaut wird auch bemerken, dass die Befehlsstruktur wie hier dargestellt eigentlich gar keinen Sinn macht, denn:
1. Wozu sollte eine 16 Bit CPU Befehle benutzen die nur 128 Byte addressieren kann?
2. Wozu 5 Bit "Reserve" bei der CPU unbenutzt lassen, was eine unglaubliche Verschwendung von Resourcen ist, wenn selbst 8bit CPUs aus den 70er Jahren 16bit Befehle verstehen und verarbeiten können?
Im Grunde ist alles an dieser CPU verkehrt herum, eine 16 bit CPU die 16bit Befehle benutzt, sprich sie könnte THEORETISCH 65536 Befehle benutzen, aber nur einem addressierbaren Speicherplatz von 128 Byte? Ausserdem scheint es so zu sein und das ist der mutmaßliche Punkt 3, dass diese CPU nur ein Register benutzt, denn sonst würde man ja die Werte aus dem Akkumulator nicht in den (ohnehin) knappen Speicherplatz laden, sondern in ein weiteres Register, was zudem auch viel schneller wäre als den Umweg über das RAM zu benutzen.
Alles an diesem Video weist also darauf hin, dass es auf ein grundsätzliches Verstehen der Arbeitsweise einer (generischen) CPU und deren Machinensprache geht, nicht um das erlernen eines konkreten Maschinencodes für eine Bestimmte Sorte von Computern.
@@kellerkind6169 Ich stimme zu, gut geschrieben.
Ich selber habe bevor ich einen eigenen Computer hatte viele Bücher über Computer gelesen alle auf englisch. Ich kannte am Anfang noch kein einziges Fachwort was dort benutzt wurde. Nach und nach habe ich erst verstanden welche Begriffe was bedeuten und Internet gab es noch nicht. Ich habe mir alles selber bei gebracht. Zu meiner Schulzeit gab es nur Taschenrechner und Großrechner und noch keine Computer für zu Hause. Heute ist es wirklich einfach an Informationen zu kommen. Z.B. Intel developer manual und auch Dokus von AMD.
@@kellerkind6169 Ich freue mich über jeden Komentar, auch wenn es erst Jahre später kommt.
Danke für das Video und danke dafür, dass du das #-Zeichen Doppelkreuz nennst und nicht wie viele falsch Raute.
Super Video 👍
Vl ist es möglich die Videos in einer Playlist chronologisch zusammenzufassen.
LG
Sven
Einfach mal 60 Seiten Script in einem 14min Video perfekt dargestellt.
Vielen Dank Andreas! Du hast vielen Menschen geholfen
Richtig gutes Video. 😊 Danke für die einfache und verständliche Erklärung.
Genau das was ich gesucht habe, danke dafür!!!!=)
super video!! jemand sollte einen guide schreiben, wo man auf youtube die richtigen videos findet.
Es ist alles da....aber find das mal....
ich habs zum Beispiel erst jetzt gefunden :D
danke sehr für Ihres Video!
Hallo Andreas, Du hast das super erklärt! Was ich nicht verstehe, das alles ist ja virtuell (auf dem Bildschirm sichtbar), wie kommt es den von der Virtualität zur Realität? Ich meine, da müssen Minitransistoren mit Strom angesprochen/ gesteuert werden, an oder aus. Wie funktioniert das? Grüsse Timo
Hallo Timo, das ist natürlich kompliziert und nicht mit ein paar Zeilen erklärt. Aber einen guten Einstieg liefert dir diese Seite vfhcab.eduloop.de/loop/Computerarchitektur_und_Betriebssysteme
Gibt es bei modernen Prozessoren noch weitere "Num" Varianten, also ist dort die Definition von "int", "char", "float", "bool" etc. verortet? Vermutlich gibt es auch mehr Befehle und daher eine größere Befehlsbreite oder zumindest weniger Reserve?
Hallo, ja, die Befehlsbreite ist bei modernen CPUs tatsächlich größer. Da jeder CPU-Hersteller hier eigene Entwicklungen hat, empfehle ich bei Bedarf den Blick in die jeweilige CPU-Spezifikation, sofern diese veröffentlicht wurde.
Vielen Dank
Sehr schön erklärt
Befehle werden nicht *auf* einem Accumulator ausgeführt, sondern mit einem. Das bedeutet, dass der Accumulator oft Ziel und Quelle einer Operation ist und solche Befehle nur über und mit dem Accumulator ausgeführt werden können. Ich finde die andere Beschreibung etwas unglücklich gewählt.
Danke für diese hervorragende Erklärung, weiter so!
Gutes Video für einen ahnungslosen. Mir ist aufgefallen dass in Maschinensprache wie Assembler der Speicherort angegeben wird, im Quelltext aber nicht, bedeutet das dass man nicht weiß in welcher Speicherzelle die Daten abgelegt werden?
Ja, das ist richtig. Die Verwaltung des Hauptspeichers ist eine der Aufgaben des Betriebssystems. Anwendungsprogramme haben keinen Einfluss darauf, wo genau im Hauptspeicher sie abgelegt werden. Durch den Einsatz der virtuellen Hauptspeicherverwaltung kann es sogar dazu kommen, dass bestimmte Teile des Hauptspeichers ausgelagert werden (auf die Festplatte), um kurze Zeit später wieder an anderer Stelle im RAM eingelagert zu werden. Dann hat sich die Speicherzelle, in welcher der Wert einer Variablen gespeichert ist, sogar während der Laufzeit der Anwendung verändert.
Die Angabe einer Adresse in Maschinensprache oder in Assembler ist übrigens typischerweise eine "virtuelle Adresse", welche davon ausgeht, dass die Anwendung ab Adresse Null im Hauptspeicher abgelegt ist. Tatsächlich ist das durch den Einsatz der virtuellen Speicherverwaltung aber nicht gegeben. Die MMU (Memory Management Unit) rechnet ständig virtuelle Adressen in physische Adressen um, was bei Einsatz der virtuellen Speicherverwaltung so erforderlich ist.
Vielen Dank für die Antwort. Es ist unglaublich wieviel Dinge im Leben benutzt werden von denen keiner weiß wie sie funktionieren. Ohne Programmierer würde die Welt im Stand von 1960 sein. Ich glaube als Programmierer ist man König
Danke für das ausführliche und trotzdem kompakte Video :)
Tip Nummer FhundertFundFzig: Um dezimale und hexadezimale Werte leichter beim Sprechen/Hören unterscheiden zu können, macht es Sinn die hexadezimalen Werte anders zu sagen. Beispiel für hex 13 eins drei und nicht dreizehn. Sonst müsste man andernfalls doch bei hex A2 zweiundazig, oder hex A0A ahunderta sagen, was sich schon etwas sonderbar anhören würde, da hundert bei hexadezimalen Werten = 64 hex keine höhere Stelle ergibt, sondern erst bei 256 bzw. FF+1. Daher lieber a zwei, oder a Null a. Das macht es leichter.
Vielen Dank! Genau das was ich brauche! Und schön kurz und knapp, aber alles Wesentliche drin! Super! :)
Das ist was für Laien wie mich......Relativ einfach erklärt.......Danke!!!!
Wir müssen das im Unterricht anschauen #ferdinantsteinbeiss
Ja, wir auch...
Grüße Leon Bruckmaier
Super Video! Sofort abonniert!
warum wird konstante erst in den acc geladen, von dort in den speicher, dann wieder in den acc, kann er nicht im accu bleiben, dann 2 konstante in den accu, dann addieren
Der Mensch programmiert den Quellcode, der Compiler übersetzt diesen in Maschinencode, die CPU führt den Maschinencode aus.
Hätte der Mensch den Quellcode anders geschrieben, dann hätte der Compiler anderen Maschinencode erzeugt und die CPU hätte diesen anderen Maschinencode erzeugt.
Denkbar wäre auch, dass der Mensch einen besseren Compiler schreibt, der Optimierungen bei der Übersetzung vom Quellcode in den Maschinencode vornimmt. Das ist in diesem Beispiel aber nicht von Belang, es geht um die Verdeutlichung der generellen Arbeitsweise.
Danke, sehr plausibel erklärt. Prima
nich komplett geguckt, da ich schon weiter bin im studium aber hut ab, das was ich gesehen hab war astrein erkklärt!
vielen vielen Danke für diese tolle Erklärung
Geschnallt hab ichs noch nicht so ganz , aber super aufbereitet !!!
vielen Dank
Wäre nett wenn der Link am Ende des Videos als echter Link in der Beschreibung ist.
Danke
Hier: courses.cs.vt.edu/csonline/MachineArchitecture/Lessons/CPU/sumprogram.html
Danke!
Moderne Computer arbeiten mit bytes (8bit) wie passt das mit dem Video zusammen ?
Ist es dann abhängig von dem Befehl wie viele bytes geladen werden ?
Oder beschreibt das im Video erklärte Prinzip befehle einer RISC CPU und mein genanntes Problem das CISC Prinzip ?
Schon mal danke für Antworten ;)
Während ein Bit fest definiert ist, kann ein Byte unterschiedlich groß sein. In der Regel ist er tatsächlich 8 Bit lang.
Wie schon erwähnt wurde, diese CPU gibt es gar nicht. Somit ist das Video eher praxisfern gestaltet, was den Einstieg m.M.n. eher erschwert, da die gezeigten Dinge nicht an einer real existierenden CPU ausprobiert werden können, um einen darauf aufbaunden Lerneffekt zu erzielen, der durch die Programmierpraxis sich erst verfestigen läßt und ergibt.
@@maxmuster7003 Programmierpraxis? Du Programmierst doch auf einen viel höheren Abstraktionsgrad. Maximal für Assembler sinnvoll. Das Video ist super, um Theoretisch das Thema grundlegend anzuschneiden
@@hansimgluck505 Ich programmiere überwiegend in Assembler. Einen Compiler habe ich noch nie verwendet. Zum entwickeln und testen von neuen Formeln verwende ich einen BASIC interpreter und wenn es funktioniert schreibe ich damit eine Assembler-Routine.
klasse verständlich erklärt, danke
Tolles Video. Gefällt mir sehr gut und gerne würde ich mehr davon sehen...:)
Vielen Dank für dieses informative Video! :)
Sehr gut erklärt, Danke Ihnen :)
starkes video!! danke dir
Ich dachte Maschinensprache ist sowas wie CD 21 od. BF 04 , hmmm :-) also in Hexdezimal
Sehe ich auch so.
MMMEEEEGGGGAAAA Super erklärt !!!! WOW
16 Bit CPU, daher wird einfach alles zu 16bit Blöcken aufgespalten.
Das mag ja für ARM-CPUs gelten, aber bei x86-CPUs ist NICHT jeder Befehl gleich lang.
Sehr gutes Video!
vielen dank!!!!
super video für einen ersten Eindruck
Ein 16 bit *x86 code* in 16 bit aufzuspalten ist aber nicht wirklich sinnvoll, da die Befehle unterschiedlich viele Bytes je 8 Bit haben können und nicht alle Befehle nur 16 Bit haben. Das ist dann etwas anders als im Video gezeigt.
Der erste Befehl könnte dann nur ein einziges Byte haben und ein anderer Befehl danach 3 Bytes. Dann wären in den ersten 16 Bit der erste Befehl mit 8 Bit und zusätzlich die ersten 8 Bit vom zweiten Befehl, der sich über die nächsten 16 Bit weiter fort setzt und auf verschiedene 16 Bit Blöcke aufgespalten ist.
Intel 80386+
A closer look to the possible sorts of bytes of one instruction:
Instruction Prefix 0 or 1 Byte
Address-Size Prefix 0 or 1 Byte
Operand-Size Prefix 0 or 1 Byte
Segment Prefix 0 or 1 Byte
Opcode 1 or 2 Byte
Mod R/M 0 or 1 Byte
SIB, Scale Index Base (386+) 0 or 1 Byte
Displacement 0, 1, 2 or 4 Byte (4 only 386+)
Immediate 0, 1, 2 or 4 Byte (4 only 386+)
Format of Postbyte(Mod R/M from Intel-manual)
------------------------------------------
MM RRR MMM
MM - Memory addressing mode
RRR - Register operand address
MMM - Memory operand address
RRR Register Names
Filds 8bit 16bit 32bit
000 AL AX EAX
001 CL CX ECX
010 DL DX EDX
011 Bl BX EBX
100 AH SP ESP
101 CH BP EBP
110 DH SI ESI
111 BH DI EDI
---
(Note: We observe the next two tables from the 16 bit address mode. The D flag in the code-segment descriptor is not set. The default size of memory access and the operand size (without size prefixes) is 16 bit.)
16bit memory (No 32 bit memory address prefix)
MMM Default MM Field
Field Sreg 00 01 10 11=MMM is reg
000 DS [BX+SI] [BX+SI+o8] [BX+SI+o16]
001 DS [BX+DI] [BX+DI+o8] [BX+DI+o16]
010 SS [BP+SI] [BP+SI+o8] [BP+SI+o16]
011 SS [BP+DI] [BP+DI+o8] [BP+DI+o16]
100 DS [SI] [SI+o8] [SI+o16]
101 DS [DI] [DI+o8] [SI+o16]
110 SS [o16] [BP+o8] [BP+o16]
111 DS [BX] [BX+o8] [BX+o16]
Note: MMM=110,MM=0 Default Sreg is DS !!!!
32bit memory (Has 67h 32 bit memory address prefix)
MMM Default MM Field
Field Sreg 00 01 10 11=MMM is reg
000 DS [EAX] [EAX+o8] [EAX+o32]
001 DS [ECX] [ECX+o8] [ECX+o32]
010 DS [EDX] [EDX+o8] [EDX+o32]
011 DS [EBX] [EBX+o8] [EBX+o32]
100 SIB [SIB] [SIB+o8] [SIB+o32]
101 SS [o32] [EBP+o8] [EBP+o32]
110 DS [ESI] [ESI+o8] [ESI+o32]
111 DS [EDI] [EDI+o8] [EDI+o32]
Note: MMM=110,MM=0 Default Sreg is DS !!!!
---
SIB is (Scale/Base/Index)
SS BBB III
Note: SIB address calculated as:
=+*(2^(Scale))
Fild Default Base
BBB Sreg Register Note
000 DS EAX
001 DS ECX
010 DS EDX
011 DS EBX
100 SS ESP
101 DS o32 if MM=00 (Postbyte)
SS EBP if MM00 (Postbyte)
110 SS ESI
111 DS EDI
Fild Index
III register Note
000 EAX
001 ECX
010 EDX
011 EBX
100 never Index SS can be 00
101 EBP
110 ESI
111 EDI
Fild Scale coefficient
SS =2^(SS)
00 1
01 2
10 4
11 8
Was hier fehlt und nicht mit hinein passt in diesen Kommentar sind die Opcodes der verschiedenen x86er-Befehle und die Bytes der Befehls-Prefixe. Alles andere ergibt sich aus den Tabellen oben.
10000000000000000000000000000000000 Danke Danke Danke......
Ach, wenn man hier Kritik übt, dann wird der Kommentar gelöscht. Wirklich peinlich. Ok. Dann lösche ich meine anderen Kommentare auch. Daumen runter.
Max Muster: Jetzt bleib mal locker. Es wurde nicht ein einziger Kommentar von dir gelöscht. Jedenfalls nicht von mir. Und die einzigen beiden, die sonst noch etwas löschen könnten sind Google/TH-cam oder du selbst. Vielleicht stellst du mal die Sortierreihenfolge der Kommentare auf "Neueste zuerst".
@@AndreasWilkens Ok, danke das du dich dazu geäussert hast. Ich habe gestern 6 Kommentare geschrieben und in 3 davon etwas kritisiert und 4 wurden gelöscht. In einem davon habe ich Tabellen vom Intel Manual gepostet. Heute morgen waren nur noch 2 Kommentare übrig geblieben. Ich habe mir Mühe gegeben die Kommentare zu verfassen. Ich hoffe dass du meinen Frust über die Löschung verstehst. Ich glaube dir dass du daran unschuldig bist. Ich finde es eine bodenlose Frechheit daß so etwas passiert.
Entschuldige bitte, wenn ich dich damit geärgert habe. Mehr kann ich nun auch nicht daran ändern. Ich nehme nun mein Daumen nach unten wieder zurück. Ich wünsche dir noch einen schönen Tag. Und lasse uns die Angelegenheit nun vergessen und begraben. Nochmal Danke, es tut gut deine Worte zu lesen. Mir bedeutet so etwas viel, besonders in dieser momentanen angespannten Lage und Situation in der wir uns befinden. Alles gute für dich.
@@maxmuster7003 Also ich sehe genau 3 Kommentrare von dir unter diesem Video, diesen nicht eingerechnet. Deine Inteltabelle sehe ich auch, leider ohne Erklärung nicht zu verstehen wenn man sich nicht mit prozessoren auskennt.