Autor Thema: booten / laden von diskette  (Gelesen 14318 mal)

Simon

  • Beiträge: 6
    • Profil anzeigen
Gespeichert
« am: 30. March 2011, 19:00 »
Hallo zusammen,
ich bin 14 und programmiere seit ca. 1 1/2 Jahren Assembler für ein Jufo Projekt und versuche ein System hinzukriegen.
als Compiler verwende ich asmarc (glaube ich), da ich eigentlich Compiler hasse (sry) weil bei mir nie die Parameter funktionieren.
Dieses 'asmarc' ist, wie ich später merkte, 16 bit. Ich habe aber nen 32 und 64 computer. Den Kernel habe ich immer mit NTVDM simuliert.
Jetzt stehe ich (unter anderem) vor folgendem Problem:
1. Welchen Assembler soll ich nehme? er sollte möglichst leicht zu bedienen sein
2. Mein Programm ist größer als 512 byte, also brauche ich einen Bootloader. um den Aufwand möglichst klein zu halten, wür ich gerne auf eine Diskette in den Bootsektor den Bootloader schreiben, auf die andere in den Bootsektor den Kernel. Was muss ich hierbei beachten? (Abschlussbytes usw...) Welche Programme kann man mir empfehlen?
Clund

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 30. March 2011, 19:31 »
Hallo Simon, willkommen im Forum!

Die meisten hier benutzen entweder as (den GNU-Assembler) oder nasm. Die können beide sowohl 32 als auch 64 Bit. Als Bootloader empfehlen wir grundsätzlich GRUB zu nehmen. Wenn du dich ein bisschen in unserem Wiki umschaust, findest du auch ein paar verschiedene Artikel zum Einstieg, die alles etwas ausführlicher beschreiben als ich das jetzt hier in einem Beitrag tun kann.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Simon

  • Beiträge: 6
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 30. March 2011, 19:48 »
Hallo,
danke erstmal für die Info
wenn ich von 16 auf 32 bzw 64 bit umsteige, muss ich da bezüglich registern und Variablen was im Programm ändern?
eine Frage noch, die mir grad einfällt:
funktioniert Variablenzugriff direkt oder im Verhältnis der Adresse des Befehl, der auf die Variable zugreift?
Clund

rizor

  • Beiträge: 521
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 30. March 2011, 20:37 »
Hallo Simon, auch ein herzliches Willkommen von mir.

Du musst darauf achten, dass ein int maximal 32 bit grosz ist.
Wenn du ein 16-bit System hast, ist ein int 16 bit grosz, bei einem 32-bit System 32 bit und bei einem 64-bit System 32 bit.
Bei longs sieht die geschichte etwas anders aus. bei einem 32-bit Systemen und 16-bit System (bin mir nicht mal sicher, ob es da longs gibt) 32 bit und bei einem 64-bit System sind es 64 bit.

Deine andere Frage verstehe ich nicht so ganz.
Ich vermute mal, dass sie sich auf absolute und relative Adressierung bezieht. Das kannst du halten wie du moechtest. Ich wuerde dir aber bei der x86-Architektur absolute Adressierung empfehlen, da relative Adressierung in dem Fall etwas schwerer ist (habe ich zumindest mal gelesen), da du nicht direkt mit dem Program Counter arbeiten kannst.
Programmiertechnik:
Vermeide in Assembler zu programmieren wann immer es geht.

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 30. March 2011, 22:27 »
Hallo und Willkommen,

wenn du bisher komplett mit für 16-Bit programmiert hast, kannst du das auch weiterhin tun, bleibst aber auf die entsprechenden Grenzen beschränkt (max. 1 MB RAM im Real Mode, 16 MB RAM im 16-Bit Protected Mode). Die 32-Bit-Programmierung unterscheidet sich davon aber, es ist im Endeffekt eine neue Assemblersprache mit sehr viel Ähnlichkeit, bei 64 Bit sind die Unterschiede dann noch etwas größer.

Für ein richtiges Betriebssystem würde ich dir eine Hochsprache ans Herz legen, da du den Code übersichtlicher strukturieren kannst. Außerdem wird es einfacher, da eine höhere Programmiersprache dir einiges an Aufwand abnehmen kann (und schneller, da ein Compiler optimieren kann - ein Assembler nicht).

Für den Kernel empfehle ich dir einen vorhandenen Bootloader zu benutzen (z.B. GRUB) und deinen Kernel einfach entsprechend  Multiboot-Standard herzurichten (siehe Wiki).

Zu beiden Themen gibt es hier im Forum lange Diskussionen, die du dir durchlesen kannst oder auch nicht. Die Empfehlungen sind jedenfalls nicht aus Luft entstanden. ;-)

rizer: "Relative Adressierung" heißt nicht zwingend relativ zu IP oder PC. Du kannst auch relativ zu Segmenten oder relativ zu BX programmieren. Es ist aber in jedem Fall möglich.

Schöne Grüße,
Svenska

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 30. March 2011, 23:29 »
Ahoi und Willkommen an Bord!

wenn ich von 16 auf 32 bzw 64 bit umsteige, muss ich da bezüglich registern und Variablen was im Programm ändern?

Nicht ändern. Du wirst vermutlich alles komplett neuschreiben müssen. So ist das (im Allgemeinen) immer, wenn man in Assembler programmiert und dann den Assembler und/oder die Architektur wechselt. Du solltest also nicht davon ausgehen, dass es mit einem einfachen Wechsel der Programme getan ist.
« Letzte Änderung: 30. March 2011, 23:34 von PorkChicken »
Dieser Text wird unter jedem Beitrag angezeigt.

freecrac

  • Beiträge: 86
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 31. March 2011, 01:15 »
(max. 1 MB RAM im Real Mode, 16 MB RAM im 16-Bit Protected Mode).
Mit einem 80286 kann man im Protectmode(PM) zwar nur max. 16 MiB physikalischen Speicher adressieren, aber ab einen 80386 (mit 21 Adressleitungen) gibt es diese Beschränkung doch gar nicht mehr und man kann vergleichsweise wie im 16 Bit-Unrealmode auch im 16 Bit-PM den gesamten 4 GiB-Adressraum vollständig adressieren, vergleichsweise wie im 32 Bit-PM.

Zitat
Die 32-Bit-Programmierung unterscheidet sich davon aber, es ist im Endeffekt eine neue Assemblersprache mit sehr viel Ähnlichkeit, ...

Der einzige Unterschied auf einem 80386+ zwischen dem 16 Bit-Mode und dem 32 Bit-Mode ist die Verwendung der Register-Size-, Operand-Size- und Adress-Size-Prefixe und wie die CPU folgende Operation mit und ohne diese Prefixe interpretiert und ausführt.

Für den 16 Bit-Mode muss man diese Prefixe verwenden, wenn man 32 Bit-Register, 32 Bit Operanden und/ oder 32 Bit Adressen verwenden möchte.
Bei der Verwendung von 16 Bit-Register, 16 Bit-Operanden und/oder 16 Bit-Adressen muss man im 16 Bit-Mode diese Prefixe weglassen.
Und umgekehrt im 32 Bit-Mode muss man diese Prefixe verwenden, wenn man 16 Bit-Register, 16 Bit-Operanden, oder 16 Bit-Adressen verwenden möchte
und man muss diese Prefixe weglassen, wenn man 32 Bit-Register, 32 Bit Operanden und/ oder 32 Bit Adressen verwenden möchte.

Es kehrt sich also nur die Bedeutung mit oder ohne dieser Size-Prefixe um. (Mit der adressierbaren Größe des Speichers haben beide Modi(16 Bit, 32 Bit) rein gar nichts zu tun, wenn man eine 32 Bit-CPU verwendet.)

...

Der Unterschied zwischen dem PM und dem RM, ob nun im 16 Bit-Mode, oder im 32Bit-Mode ist da schon weitaus umfassender und daher nicht mehr in nur wenigen Sätzen so schnell abgehandelt.

Dirk

freecrac

  • Beiträge: 86
    • Profil anzeigen
Gespeichert
« Antwort #7 am: 31. March 2011, 16:19 »
rizer: "Relative Adressierung" heißt nicht zwingend relativ zu IP oder PC. Du kannst auch relativ zu Segmenten oder relativ zu BX programmieren. Es ist aber in jedem Fall möglich.

Adressierungsarten:
Bei der indirekten Adressierung verwendet man anstelle einer fixen Adressangabe ein Offset-Register, wo die Adresse enthalten ist. Hiebei kann man verschiede Offset-Register kombinieren deren Werte zusammengerechnet die Adresse bilden auf die zugegriffen werden soll. Die Kombinationsmöglichkeiten für 80386+ bei der Verwendung von 32Bit-Offsetregister sind wie folgt deklariert und werden im sogenannten "ModR/M"-Byte, oder auch Postbyte des verwendeten Opcodes eingetragen:

http://www.timmermann.org/ralph/index.htm?http://www.ralph.timmermann.org/controller/pentium.htm


Bei der Verwendung von 16-Bit-Offset-Register können nur BX oder BP als Basis- und nur SI oder DI als Indexregister verwendet werden, der Skalenfaktor ist nicht verfügbar und das „Displacement“ auf 16 Bit beschränkt.

Siehe auch: http://tams-www.informatik.uni-hamburg.de/lehre/2001ss/proseminar/mikroprozessoren/vortraege/03-x86-befehlssatz/ausarbeitung.pdf

Format of Postbyte(Mod R/M aus Intel-Doku)
------------------------------------------
MM RRR MMM

MM  - Memeory addressing mode
RRR - Register operand address
MMM - Memoy 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

---

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:
<sib address>=<Base>+<Index>*(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 MM<>00 (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

ASM86FAQ.TXT(asm86faq.zip) auf: http://www.sac.sk/files.php?d=12&p=5
bzw. hier: ftp://ftp.sac.sk/pub/sac/text/asm86faq.zip

Dirk

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #8 am: 31. March 2011, 16:23 »
Vielen Dank für das erfolgreiche Umbringen des Threads. :roll:

Simon

  • Beiträge: 6
    • Profil anzeigen
Gespeichert
« Antwort #9 am: 31. March 2011, 17:12 »
Hallo,
also das ist mehr als genug..
ich werde mich erstmal im i-net über Adressierungsarten usw... informieren
vielen dank für eure Hilfe
Simon

sfan

  • Beiträge: 94
    • Profil anzeigen
Gespeichert
« Antwort #10 am: 31. March 2011, 18:34 »
Auch Hallo und Willkommen im Forum!
Als Artikel im Wiki würde ich dir http://www.lowlevel.eu/wiki/OS-Dev_f%C3%BCr_Einsteiger empfehlen.
Wie sehr viele benutzte ich auch GRUB, das würde ich dir auch empfehlen


Sfan

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #11 am: 31. March 2011, 20:27 »
Hallo,


aber ab einen 80386 (mit 21 Adressleitungen) gibt es diese Beschränkung doch gar nicht mehr und man kann vergleichsweise wie im 16 Bit-Unrealmode auch im 16 Bit-PM den gesamten 4 GiB-Adressraum vollständig adressieren, vergleichsweise wie im 32 Bit-PM.
Das ist irgendwie blöd formuliert, also das mit dem 16Bit-PM. Wenn man auf einem 386 oder höher in den PM schaltet gibt es da erstmal keinen direkten Unterschied zwischen 16Bit-PM und 32Bit-PM, erst durch die Attribute der benutzten Segmente ergibt sich dann ob die CPU nun 16Bit-Code oder 32Bit-Code ausführt. Man kann den Segmenten eines 16Bit-PM-Programm nicht einfach so ein größeres Limit geben (um dann >64kB ansprechen zu können), dann wären es ja 32Bit-Segmente. Man kann also im PM problemlos 16Bit-Programme und 32Bit-Programme mischen, es müssen nur die jeweils passenden Segment-Descriptoren benutzt werden und der OS-Kernel muss natürlich mit beidem umgehen können (es ist also auf jeden Fall ein 32Bit-OS nötig wenn man auch 32Bit-Programme ausführen möchte).

Das mit dem UnReal-Mode ist etwas anders, da lädt man mit einem Trick größere Limits in die Segment-Shadow-Register um eben mehr als 64kB ansprechen zu können.


Aber ob all diese kniffligen Dinge für einen Anfänger schon das richtige sind möchte ich dann doch bezweifeln. Ich denke für den Einstieg ist eine Hochsprache (die vor einem all diese Dinge gut versteckt) doch wesentlich besser geeignet. x86 ist eine extrem komplexe und unübersichtliche Plattform, wenn man sich da nicht gleich völlig verzetteln will sollte man sich erst einmal auf das Wesentliche konzentrieren.


Grüße
Erik
Reality is that which, when you stop believing in it, doesn't go away.

freecrac

  • Beiträge: 86
    • Profil anzeigen
Gespeichert
« Antwort #12 am: 31. March 2011, 22:26 »
Vielen Dank für das erfolgreiche Umbringen des Threads. :roll:
Wie meinst du denn das?

Ich habe doch den Thread mit konkreten Fakten am Leben gehalten an den man sich orientieren kann.

Dirk

rizor

  • Beiträge: 521
    • Profil anzeigen
Gespeichert
« Antwort #13 am: 31. March 2011, 22:38 »
Vielen Dank für das erfolgreiche Umbringen des Threads. :roll:
Wie meinst du denn das?

Ich habe doch den Thread mit konkreten Fakten am Leben gehalten an den man sich orientieren kann.

Dirk

Du hast das sicher nur gut gemeint, allerdings muss man sagen, dass es fuer einen Anfaenger zu viel sein koennte (Habe ich jetzt auch so aus seiner Reaktion gedeutet). Das geht ja schon sehr weit in die Theorie, was fuer einen ersten Ueberblick zu viel sein kann.

Ist zumindest meine Meinung ;)
Programmiertechnik:
Vermeide in Assembler zu programmieren wann immer es geht.

freecrac

  • Beiträge: 86
    • Profil anzeigen
Gespeichert
« Antwort #14 am: 31. March 2011, 23:26 »
Hallo,


aber ab einen 80386 (mit 21 Adressleitungen) gibt es diese Beschränkung doch gar nicht mehr und man kann vergleichsweise wie im 16 Bit-Unrealmode auch im 16 Bit-PM den gesamten 4 GiB-Adressraum vollständig adressieren, vergleichsweise wie im 32 Bit-PM.
Das ist irgendwie blöd formuliert, also das mit dem 16Bit-PM.
Wenn man auf einem 386 oder höher in den PM schaltet gibt es da erstmal keinen direkten Unterschied zwischen 16Bit-PM und 32Bit-PM, erst durch die Attribute der benutzten Segmente ergibt sich dann ob die CPU nun 16Bit-Code oder 32Bit-Code ausführt.
Ja genau dieser Hinweis fehlte noch und ggf. auch kleine Programmschnipsel die zeigen welcher Opcode hierbei verwendet wird.
Doch ich dachte mir es am Anfang so einfach wie möglich zu halten.

Zitat
Man kann den Segmenten eines 16Bit-PM-Programm nicht einfach so ein größeres Limit geben (um dann >64kB ansprechen zu können), dann wären es ja 32Bit-Segmente.
Aber gewiss doch, beginnend vom 16 Bit-RM können wir in den 16 Bit-PM schalten und in der GDT die Segmente-Größe z.B. des Datensegments auf 4 Gib erweitern (auf einem 80386+).
Beispiel für ein Datensegment-Eintrag in der GDT, um darüber bis zu 4 Gib zu adressieren:
       DW 0FFFFh
       DW 0
       DB 0
       DB 92h
       DB 0FFh
       DB 0FFh

Zitat
Man kann also im PM problemlos 16Bit-Programme und 32Bit-Programme mischen, es müssen nur die jeweils passenden Segment-Descriptoren benutzt werden und der OS-Kernel muss natürlich mit beidem umgehen können (es ist also auf jeden Fall ein 32Bit-OS nötig wenn man auch 32Bit-Programme ausführen möchte).
Man braucht nicht unbedingr dafür ein 32Bit-OS um Programme(oder Teile davon) im 32 Bit-Mode auszuführen. Vom purem 16 Bit-DOS aus gestartet (ohne Memorymangaer wie emm386.exe) kann jede Anwendung selber in den 32 Bit-PM schalten und einen Opcode der für den 32 Bit-Mode entwickelt wurde dann auch ausführen.

Logisch das man 32 Bit-Anwendungen die z.B. für Linux/Windows/OS2... entwickelt wurden nicht ohne diese OS ausführen lassen kann.
Aber ein eigens entwickelter 32 Bit-Opcode kann man auch ohne ein 32 Bit-OS ausführen lassen.
Hier muss man also unterscheiden, ob die Anwendung für ein bestimmtes OS entwickelt wurde, oder eben nicht.

Zitat
Das mit dem UnReal-Mode ist etwas anders, da lädt man mit einem Trick größere Limits in die Segment-Shadow-Register um eben mehr als 64kB ansprechen zu können.

Der Unrealmode ist weder ein Trick noch ein Bug, sondern ein zu Anfang verleugneter Betriebsmode der mit der Einführung der 80386 hinzukam.

Zitat
Aber ob all diese kniffligen Dinge für einen Anfänger schon das richtige sind möchte ich dann doch bezweifeln. Ich denke für den Einstieg ist eine Hochsprache (die vor einem all diese Dinge gut versteckt) doch wesentlich besser geeignet. x86 ist eine extrem komplexe und unübersichtliche Plattform, wenn man sich da nicht gleich völlig verzetteln will sollte man sich erst einmal auf das Wesentliche konzentrieren.


Grüße
Erik
Diese Entscheidung überlasse ich jedem selber.

Mir persöhnlich macht das Programmieren mit Hochsprachen überhaupt kein Spaß und das erste was ich auf einem PC(es war ein 80286er) gelernt habe war es Debug.exe zu bedienen, noch bevor ich irgendwelche Befehle des von mir damals verwendeten MSDOS 5 überhaupt kennen gelernt habe. Damit habe ich dann die Funktionsweise der CPU erkundet und mich somit auf das Wesentliche konzentriert, denn wenn man hardwarenah programmieren möchte, dann ist es sehr zweckmäßig die genaue Funktionsweise der CPU kennen zu lernen.

Dirk

freecrac

  • Beiträge: 86
    • Profil anzeigen
Gespeichert
« Antwort #15 am: 31. March 2011, 23:37 »
Vielen Dank für das erfolgreiche Umbringen des Threads. :roll:
Wie meinst du denn das?

Ich habe doch den Thread mit konkreten Fakten am Leben gehalten an den man sich orientieren kann.

Dirk

Du hast das sicher nur gut gemeint, allerdings muss man sagen, dass es fuer einen Anfaenger zu viel sein koennte (Habe ich jetzt auch so aus seiner Reaktion gedeutet). Das geht ja schon sehr weit in die Theorie, was fuer einen ersten Ueberblick zu viel sein kann.

Ist zumindest meine Meinung ;)
Einen Bootloader und einen eigenen Kernel zu benutzen ist nun mal mit vielen Details verbunden.
Ich würde ja auch eher zu Anfang erstmal nur kleine Anwendungen programmieren wollen, bevor ich mit einem Kernel herumspiele. Aber du hast schon recht, es ist schwer abzuschätzen womit man beginnen sollte, wenn man schon beim Threadstart mit dem Wunsch konfrontiert wird ein System mit Assembler hinzubekommen, aber die verschiedenen Adressierungarten noch nicht bekannt sind.

Dirk

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #16 am: 01. April 2011, 03:40 »
Ich halte es dennoch für überzogen, einen Anfänger, der ein paar Grundsatzfragen gestellt hat, gleich mit einer Seite Assemblercode und zusätzlichen Details zuzubomben.

Nachfragen geht immer, verschrecken ist einfacher.

freecrac

  • Beiträge: 86
    • Profil anzeigen
Gespeichert
« Antwort #17 am: 01. April 2011, 10:22 »
Ich halte es dennoch für überzogen, einen Anfänger, der ein paar Grundsatzfragen gestellt hat, gleich mit einer Seite Assemblercode und zusätzlichen Details zuzubomben.

Nachfragen geht immer, verschrecken ist einfacher.
Nach eigenen Angaben programmiert er schon 1,5 Jahre Assembler. Ich würde ihn damit nicht gerade als wirklichen Anfänger bezeichnen. Und ich denke nach 1,5 Jahren wird es möglicherweise Zeit die verschiedenen Adressierrungsarten einmal näher kennenzulernen. Und ob er nun durch eine schlichte Tabelle wo die verschiedenen Adressierungsarten ersichtlich werden nun verschreckt wurde, das kann ich so noch gar nicht erkennen, zumal er nun ein Interesse bekundete sich die Adressierungsarten einmal genauer anzuschauen. Auch meine ich das es nur wenig nütztlich ist nur um den heissen Brei herumzudebatieren, ohne mal konkrete Fakten auf den Tisch zu packen mit denen man sich auch etwas spezieller und eingehender befassen kann.

Ich selber bin ja auch kein Mensch der besonders schnell lernt, doch etwas Inhalt sollte schon in einer Antwort enthalten sein, damit man eben einen konkreten Ansatzpunkt hat mit dem man sich weiterführend beschäftigen kann. In diesem Sinne weiss ich auch nicht so recht was man mit einer Antwort wie etwa "Um Betriebsmode XY zu programmieren braucht man quasi eine neue Assembler-Sprache mit vielen Änlichkeiten" überhaupt anfangen soll, dann das sagt ja eigentlich überhauptz nichts aus und der Lerneffekt wäre zumindest damit bei mir mit so einer Antwort gleich Null.

Bitte versteht das jetzt nicht als persöhnlichen Angriff, das soll jetzt keine Schelte sein und auch ich habe bestimmt noch Defizite dabei wie man ein Wissen am besten rüberbringt. Ich selber bin auch dankbar wenn an meinem Stil Kritik geübt wird, es ist ja auch nicht so einfach einen fremden Hilfesuchenden mit uns unbekannten Vorwissen richtig einzuschätzen um eine Antwort geben zu können die genau dort ansetzt wo es benötigt wird. Hier braucht man aber auch das Feedback des Fragestellers, falls man nicht gerade rein zufällig mal ins Schwarze mit seiner Antwort trifft.

Dirk

Simon

  • Beiträge: 6
    • Profil anzeigen
Gespeichert
« Antwort #18 am: 01. April 2011, 18:07 »
Zitat
Nach eigenen Angaben programmiert er schon 1,5 Jahre Assembler. Ich würde ihn damit nicht gerade als wirklichen Anfänger bezeichnen. Und ich denke nach 1,5 Jahren wird es möglicherweise Zeit die verschiedenen Adressierrungsarten einmal näher kennenzulernen. Und ob er nun durch eine schlichte Tabelle wo die verschiedenen Adressierungsarten ersichtlich werden nun verschreckt wurde, das kann ich so noch gar nicht erkennen, zumal er nun ein Interesse bekundete sich die Adressierungsarten einmal genauer anzuschauen. Auch meine ich das es nur wenig nütztlich ist nur um den heissen Brei herumzudebatieren, ohne mal konkrete Fakten auf den Tisch zu packen mit denen man sich auch etwas spezieller und eingehender befassen kann.

Da muss ich ganz bescheiden sagen:
Ich hab mich erstmal gefreut, das ich überhaupt etwas funktionierendes hingekriegt habe, und habe dann auf dem Niveau weiterprogrammiert.
Ich habe überhaupt keine Ahnung über Real Mode, usw...
Speicheradressierung hat mich auch noch nicht besonders beschäftigt, weil ich es nie gebraucht habe.
Ich bin sogesehen ein Anfänger
Simon

freecrac

  • Beiträge: 86
    • Profil anzeigen
Gespeichert
« Antwort #19 am: 02. April 2011, 09:57 »
Hallo Simon.

Zitat
Nach eigenen Angaben programmiert er schon 1,5 Jahre Assembler. Ich würde ihn damit nicht gerade als wirklichen Anfänger bezeichnen. Und ich denke nach 1,5 Jahren wird es möglicherweise Zeit die verschiedenen Adressierrungsarten einmal näher kennenzulernen. Und ob er nun durch eine schlichte Tabelle wo die verschiedenen Adressierungsarten ersichtlich werden nun verschreckt wurde, das kann ich so noch gar nicht erkennen, zumal er nun ein Interesse bekundete sich die Adressierungsarten einmal genauer anzuschauen. Auch meine ich das es nur wenig nütztlich ist nur um den heissen Brei herumzudebatieren, ohne mal konkrete Fakten auf den Tisch zu packen mit denen man sich auch etwas spezieller und eingehender befassen kann.

Da muss ich ganz bescheiden sagen:
Ich hab mich erstmal gefreut, das ich überhaupt etwas funktionierendes hingekriegt habe, und habe dann auf dem Niveau weiterprogrammiert.
Ich habe überhaupt keine Ahnung über Real Mode, usw...
Speicheradressierung hat mich auch noch nicht besonders beschäftigt, weil ich es nie gebraucht habe.
Ich bin sogesehen ein Anfänger
Simon
Schönen Dank das du dazu noch etwas zu sagen hast und ich freue mich das du beim Programmieren schon ein klein wenig Erfolg hattest.
Was genau hast du denn programmiert?
Du sagst das dein Programm schon größer als 512 Bytes ist. Ich denke mir das du dort wohl auch mal eine Speicheradresse beschrieben und ausgelesen hast.

Nun habe ich mal nach asmarc gesucht und diese Adresse gefunden:
http://assembler86.de/download/asmarc.exe

Im dort enthaltenen "Liesmich.txt" findet man auch nähere Details dazu z.B. unter Systemvoraussetzungen, das man ein PC mit DOS ab Version 3.x benötigt.
Dieser Assembler arbeitet also im 16 Bit-Realmode und man kann damit 16 Bit-Realmode-Programme erstellen.

Beim weiterern Stöbern fand ich dann auch ein "10.asm" im Verzeichniss "Lernprog".
Dort wird gezeigt wie man eine Zeichenkette über DOS-Funktion 0Ah eingibt und dazu wird eine Speicheradresse mit den folgenden Befehlen beschrieben:
OBJECT Line:
  MaxLen DB ?                 ; 1. Feld "MaxLen"  (ein Byte groß)
  Length DB ?   
    ....
    ....
    lea  di,  Line.MaxLen
    mov  Word [di], 254
    ....
    .....
Der LEA-Befehl läd in das DI-Register die Adresse(Offset) von "Line.MaxLen".
Und der folgende MOV-Word-Befehl schreibt über DI den Wert zu dieser Adresse und der darauf folgenden Adresse("Line.Length").

Bei dieser Adressierung wird das DS-Segmentregister verwendet und die vollständige Adresse bildet sich aus "DS:DI" bzw. "DS:Line.MaxLen"
Das Daten-Segment-Register "DS" braucht man hierbei nicht extra mit in den MOV-Befehl mit angeben, da es hierbei standardmäßig zugeordnet wird, wenn man das DI-Register als Adress-Register verwendet.

...

In der von mir geposteten Intel-Postbyte-Tabelle findet man auch noch andere Adressierungarten mit den man auf eine Speicherstelle zugreifen kann.
Hiermit kannst du etwas experimentieren.

Beispiel:
Puffer1  DB  0,1,2,3,4,5,6,7,8,9
         DB  "ABCDEFGHIJ"
         ....
         ....

         lea  di, Puffer1
         mov  bx, 10
         mov  al, [bx+di]
         .....
Ich vermute du kannst hierbei erkennen was hier in das AL-Register geladen wird.

Dirk

 

Einloggen