|
JLI Spieleprogrammierung
|
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
RebornX JLI'ler
Anmeldedatum: 16.03.2007 Beiträge: 169
Medaillen: Keine
|
Verfasst am: 18.10.2007, 19:28 Titel: Prozessor... Segmente ... ?? |
|
|
Kurz vorweg:
ka ob man hier überhaupt fragen über Assembler stellen darf... da das board ja eher etwas mit C++ zu tun hat. Aber auf Grund meiner Erfahrungen hier im Board, habe ich festgestellt, das hier einige sehr SEHR schlaue Köpfe dabei sind und deswegen wollte ich es einfach mal ausprobieren, ansonsten löscht den thread.
Hi,
ich bins wieder... der der vor einigen Monaten noch an C++/Win-Api rumhing.
Jetzt, da ich eine etwas bessere Vorstellung von C++ habe, will ich ein Level höher bzw runter gehen (Man soll ja aufhören wenns am schönsten ist xD).
Ich will mir jetzt Assembler beibringen, weil ich mir eine bessere Vorstellung davon machen will, wie ein Computer überhaupt funktioniert.
Natürlich will ich jetzt nicht anfangen mit Assembler große Programme zu schreiben, dafür sind ja eher die high-Level Sprachen geeignet (zB. C++).
Ich habe schon jetzt ein paar Fragen was den Prozessor angeht:
http://de.wikibooks.org/wiki/Assembler_%2880x86_Prozessor%29-Programmierung:_Der_Prozessor
^^ Unter dem Abschnitt: "Adressierung des Arbeitsspeichers im Real Mode" steht einiges über Segmente, jedoch glaube ich das ich irgendwie eine falsche Vorstellung davon habe.
Also ich stelle mir das irgendwie so vor:
Die 8086/88-CPU hat einen Adressbus von 20 Bit.
Da die CPU aber nur 16 Bit breite Adressen annehmen kann, bleiben im Adressbus immer 4 bits übrig. Die wollte man aber auch nutzten und deswegen kamen die Segmente dazu.
Segmente sind sozusagen packete aus Dateiregistern. Diese Segmente können dann quasi in jeweils 20 Bits geteilt werden und dann an den Adressbus den prozessor geschickt werden... moment ... irgendwie passt da was nicht... die CPU kann ja nur 16 bit breite Adressen annehmen ... ach verdammt.
Kann mir das bitte nochmal einer in anderen worten erklären?
Also was diese Segmente überhaupt sind ? _________________ Besucht meine Seite:
www.cpparchiv.dl.am
Zuletzt bearbeitet von RebornX am 18.10.2007, 19:48, insgesamt einmal bearbeitet |
|
Nach oben |
|
|
manu Super JLI'ler
Alter: 35 Anmeldedatum: 09.03.2006 Beiträge: 327 Wohnort: allgäu (DE) Medaillen: Keine
|
Verfasst am: 18.10.2007, 19:42 Titel: |
|
|
Sorry, wenn ich von der eigentlichen Frage abschweife, aber ich denke du hast dir da mit "dem PC" für den anfang zu viel vorgenommen..
Ein Tipp von mir, weil wir des gerade in der schule machen und auch die eher unbegabteren da einigermaßen durchsteigen.
Fang mit was kleinerem an, z.B. mit nem Microcontroller der 8051-Familie.
Ne Befehlsliste gibts z.B. hier:
http://www.mcls-modular.de/deutsch/helpsys/t_as2.htm
Das geschriebene Programm assembeln, dannach linken(wenn nötig) und am schluss ne Intel-Hex datei draus machen, die kannst du dann z.B. mit der demo von 8051win simulieren. Damit kann man einiges machen und lernen, ist echt cool.
http://www.simsoft.de/8051win.htm
wo du am besten den assembler herbekommst der auch dazu passt hab ich leider keine ahnung. Wir haben in der schule was vom feger, da is ne asm51.exe, link51.exe und ne obj2hex.exe bei.
vllt. haste ja schon was.
Und segmente.... nicht, dass ich mich sonderlich mit dem begriff auskenne. Aber ein segment ist halt einfach ein Teil des speichers. Und ich kenn mich mit dem PC jetzt net aus, aber ich könnte mir vorstellen, dass man verschiedene segmente auf verschiedene arten anspricht, z.B. direkt oder indirekt.. Was auch problematisch sein dürfte is da aber, dass der Speicher net genau unterteilt werden kann und sich segmente auch teils überschneiden können.. |
|
Nach oben |
|
|
RebornX JLI'ler
Anmeldedatum: 16.03.2007 Beiträge: 169
Medaillen: Keine
|
Verfasst am: 18.10.2007, 20:13 Titel: |
|
|
Hmm, aber da wird ja schon richtig programmiert^^
Ist es nicht besser erstmal zu wissen wie ein prozessor im Groben überhaupt geht?
Den Assembler ist ja eine sehr prozessornahe Sprache... und alle Befehle da sind ja im prozessor gespeichert.
Und auch in allen Assembler-Tutorials (die ich bis jetzt angefangen habe zu lesen) fangen die immer am Anfang erstmal mit Binärcode-/hexcodeberechung an, dann steigen sie in die tiefen des Prozessors ein und erst danach fangen sie an die einzelnen Befehe zu erklären. _________________ Besucht meine Seite:
www.cpparchiv.dl.am |
|
Nach oben |
|
|
PeaceKiller JLI Master
Alter: 35 Anmeldedatum: 28.11.2002 Beiträge: 970
Medaillen: Keine
|
Verfasst am: 18.10.2007, 21:32 Titel: |
|
|
RebornX hat Folgendes geschrieben: | Hmm, aber da wird ja schon richtig programmiert^^
Ist es nicht besser erstmal zu wissen wie ein prozessor im Groben überhaupt geht?
Den Assembler ist ja eine sehr prozessornahe Sprache... und alle Befehle da sind ja im prozessor gespeichert |
Jein, heutige Prozessoren haben praktisch nochmal eigene Compiler, die den Mikro-Code optimieren, etc.
Wenn du wissen willst wie dein Prozessor funktioniert schau dir mal:
http://www.mathematik.uni-marburg.de/~gumm/MicroSim/cebit.html
an und entscheide dich, ob du das wirklich wissen willst.
Etwas einfacher ist:
http://www.martinjakobs.de/Mikrorechner/Mikrorechner.php
Das machen wir gerade in Informatik. _________________ »If the automobile had followed the same development cycle as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and explode once a year, killing everyone inside.«
– Robert X. Cringely, InfoWorld magazine |
|
Nach oben |
|
|
GreveN JLI Master
Alter: 38 Anmeldedatum: 08.01.2004 Beiträge: 901 Wohnort: Sachsen - Dresden Medaillen: Keine
|
Verfasst am: 19.10.2007, 10:31 Titel: |
|
|
Sprachen wie C++ oder Java werden extra auf einem so hohen Abstraktionslevel entworfen um dir als Programmierer eine relativ einfache Schnittstelle zu bieten, die nicht unnötig "technisch" ist. Haskell oder Prolog z.B. sind noch abstrakter und näher an der Mathematik bzw. Logik. Das ist auch gut so, da sich System- und insbesondere Prozessorarchitekturen mit der Zeit doch weiterentwickeln und dich als Programmier das dann nur bedingt interessieren braucht.
Natürlich ist es nicht verkehrt und vorallem nicht uninteressant zu wissen was auf Systemebene passiert. Assembler lernen ist prinzipiell auch nicht schlecht und nicht allzu zeitaufwendig, allerdings sollte dir bewusst sein, dass so wie jede Architektur ein bisschen anders funktioniert, Assemblercode überall anders ausschaut und deshalb nicht portabel ist - von schlechter Wartbarkeit etc. ganz zu schweigen. Fazit: Echte Programme in Assembler schreiben lohnt sich heute eigentlich nicht mehr, aber es ist sicher auch nicht schlecht eine grobe Vorstellung davon zu haben, wie dein in modernen Hochsprachen geschriebener Code nach dem Kompilieren aussehen wird und wie dieser dann im Rechner verwertet wird. |
|
Nach oben |
|
|
manu Super JLI'ler
Alter: 35 Anmeldedatum: 09.03.2006 Beiträge: 327 Wohnort: allgäu (DE) Medaillen: Keine
|
Verfasst am: 19.10.2007, 10:44 Titel: |
|
|
RebornX hat Folgendes geschrieben: |
Den Assembler ist ja eine sehr prozessornahe Sprache... und alle Befehle da sind ja im prozessor gespeichert.
|
Joa, mehr oder weniger.. Die Nullen und Einsen werden halt dann aus dem codesegment wo das Programm liegt nacheinander eingelesen und vom Befehlsdekoder in unterschiedlich vielen Dekodierstufen dekodiert und dann ausgeführt..
Die sache auf die ich hinaus wollte ist eher die, dass du das ganze Prozessordingens eher verstehen wirst, wenn du dich mit nem kleiner dimensionierten microcontroller befasst. Du musst ja nicht gleich mit dem Programmieren anfangen. Hab dir nur schonmal ein paar Links beigelegt so als Info. Und mit dem 8051win kann man echt gut lernen, indem man z.B. ne Ampel an einen Port anschließt und dann ein Programm schreibt um die Ampel zu steuern.. Auch hatts ne gute Hilfe. |
|
Nach oben |
|
|
RebornX JLI'ler
Anmeldedatum: 16.03.2007 Beiträge: 169
Medaillen: Keine
|
Verfasst am: 19.10.2007, 13:53 Titel: |
|
|
GreveN hat Folgendes geschrieben: | allerdings sollte dir bewusst sein, dass so wie jede Architektur ein bisschen anders funktioniert, Assemblercode überall anders ausschaut und deshalb nicht portabel ist - von schlechter Wartbarkeit etc. ganz zu schweigen. |
ehm... was genau meinst du damit?
Ich dachte immer das man grade Assembler überall nutzen kann.
Also ich denk man kann jedes programm durch Assembler optimieren/verändern ect. (durch disassemblieren und so) Und man kann auch soweit ich weiß das auch gut in C/C++ zur programmcode optimierung einsetzten.
Das ist bei den Hochsprachen ja eher nicht der Fall ... da man ja inzwischen keinen compilierten C++/vb/delphi usw... code wieder decompilieren kann.
Oder irre ich mich da etwa? _________________ Besucht meine Seite:
www.cpparchiv.dl.am |
|
Nach oben |
|
|
GreveN JLI Master
Alter: 38 Anmeldedatum: 08.01.2004 Beiträge: 901 Wohnort: Sachsen - Dresden Medaillen: Keine
|
Verfasst am: 19.10.2007, 14:42 Titel: |
|
|
RebornX hat Folgendes geschrieben: | ehm... was genau meinst du damit?
Ich dachte immer das man grade Assembler überall nutzen kann. |
Kannst du auch, nur verwenden eben unterschiedliche Prozessorfamilien unterschiedliche Befehlssätze etc. und damit wird dein Assemblercode dann zwangsläufig wieder anders ausschauen.
RebornX hat Folgendes geschrieben: | Also ich denk man kann jedes programm durch Assembler optimieren/verändern ect. (durch disassemblieren und so) Und man kann auch soweit ich weiß das auch gut in C/C++ zur programmcode optimierung einsetzten. |
Man kann Inline-Assembler in C++ verwenden, das wurde/wird auch gemacht um performancekritische Stellen zu optimieren, nur sind damit eben auch wieder o.g. Nachteile verbunden. Zudem lohnt es sich heute eigentlich nicht mehr, da moderne Compiler das schon fast besser können als du. Zudem sind die wenigsten PC-Anwendungen (Spiele mal ausgenommen) wirklich performancekritisch, heute machen gute Software eher andere Dinge aus, wie eben die Wart- und Erweiterbarkeit, sowie die Portabilität. |
|
Nach oben |
|
|
User_User JLI'ler
Anmeldedatum: 05.08.2004 Beiträge: 137
Medaillen: Keine
|
Verfasst am: 19.10.2007, 15:41 Titel: |
|
|
RebornX weißt du inzwischen, was Segmente sind ? Wenn nein, dann erkläre ich sie kurz.
Annmerkung: Ich habe einst auch in Assembler programmiert (viele Jahre her) und habe damit Schluss gemacht, da man sehr wenig damit erreicht. |
|
Nach oben |
|
|
RebornX JLI'ler
Anmeldedatum: 16.03.2007 Beiträge: 169
Medaillen: Keine
|
Verfasst am: 19.10.2007, 15:58 Titel: |
|
|
User_User hat Folgendes geschrieben: | RebornX weißt du inzwischen, was Segmente sind ? Wenn nein, dann erkläre ich sie kurz.
Annmerkung: Ich habe einst auch in Assembler programmiert (viele Jahre her) und habe damit Schluss gemacht, da man sehr wenig damit erreicht. |
ne ich weiß imma noch nicht so richtig was Segmente sind^^
Wär super wenn du das erklären könntest _________________ Besucht meine Seite:
www.cpparchiv.dl.am |
|
Nach oben |
|
|
User_User JLI'ler
Anmeldedatum: 05.08.2004 Beiträge: 137
Medaillen: Keine
|
Verfasst am: 19.10.2007, 16:47 Titel: |
|
|
Im RealMode kann man 1 MB = 1024 KB = 1024 x 1024 Byte ansprechen.
Dies entspricht einer 20stelligen Dualzahl 2^20 (2 Hoch 20).
Nun hat der Prozessor Register (das sind quasi einige Variablen auf seiner CPU, auf der man Dinge speichert (Adressen), Rechnungen ausführen kann usw.)
Da die 16Bit (2Byte) für eine 20Bit-Adresse nicht ausreichen, könnte man die Register (8x3) = 24Bit (3 Byte) groß machen. Dabei würden von den 24 Bits nur 20 Bits benötigt. 4 Bits blieben ungenutzt.
Deshalb geht man einen anderen Weg.
Man verwendet die 16Bit (2Byte) der Register. Kann aber nur 65536 Byte (2^16) ansprechen (64 KB). Dies heißt Offset.
Um die vollen 1024 Kilobyte anzusprechen benötigt man einen weiteren Wert.
Man verwendet wieder 16 Bit (2Byte). Um damit 20Bit ansprechen zu können, springt man von Wert zu Wert um 16 Adressstellen (damit ist der Wertebereich auch 16 mal so groß (64 KB x 16 = 1024).Folgende 20 Bit-Adresse:
20-Bit-Adresse:
1001 1111 1010 1011 0111
Wird in folgende 16-Bit Adresse umgewandelt:
1001 1111 1010 1011
Der Computer interpretiert diese Adresse später als:
1001 1111 1010 1011 0000
Die letzten 4 Bit lässt man Weg. Damit haben die einzelnen Positionen zu diesen Adressen jeweils einen Abstand von 16 Adressstellen. Diese Adresse heißt Basisadresse.
Die Endadresse ergibt sich aus: Basisadresse x 16 + Offset |
|
Nach oben |
|
|
User_User JLI'ler
Anmeldedatum: 05.08.2004 Beiträge: 137
Medaillen: Keine
|
Verfasst am: 19.10.2007, 17:00 Titel: |
|
|
Nachtrag:
Zu den Adress-Register gehören auch die Segment-Register (CS, DS, SS, ES).
Die Basisadresse wird in einem Segmentregister gespeichert. |
|
Nach oben |
|
|
User_User JLI'ler
Anmeldedatum: 05.08.2004 Beiträge: 137
Medaillen: Keine
|
Verfasst am: 19.10.2007, 19:14 Titel: |
|
|
Ich habe mir kurz die Beiträge der anderen Teilnehmer durchgelesen.
Der 8086-Assembler wurde unter anderem unter MS-DOS (keine grafische Benutzeroberfläche vor Windows 3.1) im Real-Mode (1 MB adressierbar) verwendet. Er war somit sehr grundlegend (und einfach!) und alles weitere baut auf ihm auf.
Vielleicht finden sich in der Bücherei noch einige gute alte Bücher.
Internet-Artikel sind oft wie Nachschlagewerke aufgebaut und eignen sich vielleicht weniger für eine zusammenhängige Einführung.
Dein angegebener Link beschreibt den grundlegendsten und einfachsten Real-Mode.
Wenn ein neuer Prozessor neue Dinge kann, dann muss man die neuen Befehle auch nutzen, um davon zu profitieren. Dies ist für Spezialisten (z.B. Entwickler von DirectX oder Windows) interessant.
Für technische Geräte wie Waschmaschinen, Heizungsanlagen, Elektronikartikel (z.B. von Conrad) usw. könnte man evtl. Assembler noch gebrauchen (z.B. für Leute, die Mechatronik studieren). |
|
Nach oben |
|
|
RebornX JLI'ler
Anmeldedatum: 16.03.2007 Beiträge: 169
Medaillen: Keine
|
Verfasst am: 19.10.2007, 20:03 Titel: |
|
|
User_User hat Folgendes geschrieben: |
Man verwendet die 16Bit (2Byte) der Register. Kann aber nur 65536 Byte (2^16) ansprechen (64 KB). Dies heißt Offset. |
Ehm verstehe ich nicht ganz sry^^ Also sind jetzt diese 16 Bit ein Offset?
Aber ich denke das sind register?
Und was sind da jetzt drin? Adressen oder Daten?
User_User hat Folgendes geschrieben: |
Um die vollen 1024 Kilobyte anzusprechen benötigt man einen weiteren Wert.
Man verwendet wieder 16 Bit (2Byte). Um damit 20Bit ansprechen zu können, springt man von Wert zu Wert um 16 Adressstellen (damit ist der Wertebereich auch 16 mal so groß (64 KB x 16 = 1024). |
Ehm was meinst du mit Wert ?
Mit "noch einen weiteren Wert" meinst du sicher noch so ein 16 Bit register (Register sind immer 16 Bit groß oder? und register ist nur ein Oberbegriff für Speicher oder?)
Aber von Wert zu Wert springen? Geht der jetzt von einem 16 bit register zum anderen? Und wenn ja, warum?
Ach und diese 20 Adressleitungen sind ja insgesamt 1mb groß, dh. eine Leitung ist 51,2kb groß.... ach man ... braucht jetzt eine Adresse etwa 51,2kb ???
Oh man ich glaube ich bin echt zu blöd dafür.... _________________ Besucht meine Seite:
www.cpparchiv.dl.am |
|
Nach oben |
|
|
User_User JLI'ler
Anmeldedatum: 05.08.2004 Beiträge: 137
Medaillen: Keine
|
Verfasst am: 19.10.2007, 23:31 Titel: |
|
|
Zitat: | Ach und diese 20 Adressleitungen sind ja insgesamt 1mb groß, dh. eine Leitung ist 51,2kb groß.... ach man ... braucht jetzt eine Adresse etwa 51,2kb ??? |
Der Computer kennt nur zwei Zustände Strom an oder nicht.
Dies kann man als 0 oder 1 symbolisieren.
Diese zwei Werte entsprechen ein Bit.
Will man mehrere Zustände speichern braucht man mehrere solcher Bits.
Wenn man zwei Bits hat, dann kann man 4 Zustände speichern.
Wert Bit Nr. 2 dann Wert Bit Nr. 1 dann Dezimalwert
00 Wert = 0
01 Wert = 1
10 Wert = 2
11 Wert = 3
Setzt man ein Weiteres Bit davor, dann kann man die 4 Werte einmal mit einer führenden 0 und einmal mit einer führenden 1 schreiben.
000 = 0; 100 = 4
001 = 1; 101 = 5
010 = 2; 110 = 6
011 = 3; 111 = 7
Insgesamt kann man mit jedem weiteren Bit einen doppelt so großen Wertebereich darstellen.
Hat man 8 Bit, dann kann man damit 2*2*2*2*2*2*2*2 = 0 bis 255 Werte
darstellen. Dies nennt man ein Byte.
Damit kann man z.B. ein Zeichen darstellen. Jeder Wert entspricht einem anderen Zeichen.
Der Arbeitsspeicher besteht aus sehr vielen dieser Bytes. Um das Byte Nr. 17300 ansprechen zu können, muss man diese Zahl als Dualzahl angeben. Dabei bestimmt die Anzahl der Stellen wie groß diese Dualzahl (welche immer eine Ganzzahl ist) maximal sein kann.
Hat man 16 Bits zur Verfügung kann man
2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2 = 2^16 = 65536
verschiedene Werte damit darstellen. Eine größere Anzahl an unterschiedlichen Zuständen kann man mit 16 Bits nicht darstellen.
Um 1024 Kilobytes = 1024 * 1024 Byte = 1048576 Werte darzustellen braucht man 20 Bits.
Da man die 1048576 Bytes des Speichers "ansprechen" will, bräuchte man eigentlich 20 solcher Bits. Man hat aber nur 16 zur Verfügung.
Ein Kilobyte sind übrigends nicht 1000 Bytes, sonder 1024. Der Computer arbeitet mit Dualzahlen. Und 2^10 = 1024 kommt dem Kilobegriff recht nahe. |
|
Nach oben |
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
Powered by phpBB © 2001, 2005 phpBB Group Deutsche Übersetzung von phpBB.de
|