Ein paar (Anfänger)fragen

Ich bin im Moment dabei mir ein wenig Assembly anzueignen, und zu diesem Zwecke habe ich auch schon einige Stunden damit verbracht diese Augenkrebs erregenden Dokumentationen zu NASM, GDB usw. durchzulesen / -arbeiten.
Im Laufe der Zeit stellten sich mir Fragen, die ich durch Google nur sehr mangelhaft zu beantworten vermochte (vielleicht wusste ich einfach nich wonach ich suchen sollte).
Schon im Voraus ein Danke an alle, die sich die Mühe machen, den Beitrag zu lesen. Ich etwarte natürlich keine Antwort auf alle Fragen von einer einzelnen Person.

1.:
Gibt es einen konkreten Unterschied zwischen

num:  db 100

und

num   db 100

?

2.:
Ich habe zu Übungszwecken ein Programm geschrieben, dessen Verwendungszweck im Moment nicht relevant ist (ich möchte v.a. Korrekturen meines Codes vermeiden, die ich, wenn nötig gerne selbst vornehmen würde, ohne dass mich Andere darauf hinweisen, will ja schließlich durch Erfahrung lernen).

Ich habe damit allerdings ein Problem, hier (auszugsweise) das Programm:

section .data
	sc:	dd 3
	rc:	dd 2

section .text
        global main

main:
	push ecx
	push edx
	push ebx		

	mov ecx,[esp-sc]
	dec sc	 		
        mov ebx,1
	mov eax,4		

	int 0x80

Das Problem liegt hierbei in der Zeile

mov ecx,[esp-sc]

NASM gibt hier folgenden Fehler:

Bash schrieb:

Programm.asm:28: error: beroset-p-637-invalid effective address

Sobald ich den Operator von "-" zu "+" ändere, geht es (nungut, es treten andere Fehler auf). Ich habe das ganze auch mit lea ausprobiert, aber das ändert nicht wirklich etwas. Ich weiß wirklich nicht, wie ich auf das Byte, das 4 Bytes unter dem Stackpointer liegt zugreifen kann. Aus dem Doku-Artikel über effektive Adressen werde ich nicht besonders schlau, denn laut diesem sollte mein Code doch eigentlich funktionieren.

Nur um sicher zu gehen, ob ich die Syntaktik verstanden habe (laut NASM Doku habe ich das):

mov eax,var1 ;<= legt die Adresse von var1 in eax ab
mov eax,[var1];<=legt den Wert von var1 in eax ab[/code]
Dementsprechend sollte das ganze auch für ADD, SUB, DEC etc gelten.
Wendet man dies jedoch auf die Situation oben an, so ergibt sich, dass man eigentlich [code]mov ecx,[esp-[sc]]

schreiben sollte, was allerdings mit einem Syntax-error seitens NASM quittiert wird.

3.:
Ich habe mich unter anderem sehr kurz mit Kernelprogrammierung in Assembly beschäftigt und einige Samplecodes (bspw. von www.OSdev.org oder lowlevel.brainsware.org) gelesen.
Ein konkretes Beispiel wäre hierzu:

global loader           ; making entry point visible to linker
extern kmain            ; kmain is defined elsewhere

; setting up the Multiboot header - see GRUB docs for details
MODULEALIGN equ  1<<0                   ; align loaded modules on page boundaries
MEMINFO     equ  1<<1                   ; provide memory map
FLAGS       equ  MODULEALIGN | MEMINFO  ; this is the Multiboot 'flag' field
MAGIC       equ    0x1BADB002           ; 'magic number' lets bootloader find the header
CHECKSUM    equ -(MAGIC + FLAGS)        ; checksum required

section .text
align 4
MultiBootHeader:
   dd MAGIC
   dd FLAGS
   dd CHECKSUM

; reserve initial kernel stack space
STACKSIZE equ 0x4000                  ; that's 16k.

loader:
   mov esp, stack+STACKSIZE           ; set up the stack
   push eax                           ; pass Multiboot magic number
   push ebx                           ; pass Multiboot info structure

   call  kmain                       ; call kernel proper
   hlt                                ; halt machine should kernel return

section .bss
align 32
stack:
   resb STACKSIZE                     ; reserve 16k stack on a quadword boundary

Zuerst ist mir unklar, warum die Konstanten außerhalb jeglicher Sektionem definiert werden. Wäre es möglich, davor einfach ein

section .data

zu setzen, bzw. wieso ist die .bss-Sektion vorhanden und .data nicht?

Der (oder die) nächste/n Punkt/e ist/sind folgende/r:
Es wird mit den drei double-word definitionen jeweils ein 32bit großer Speicherbereich mit dem entsprechenden Wert initialisiert (auch in der .textt-section, nich in der (nicht existierenden) .data-section), jedoch ohne Label.
Anschließend wird der Stackpointer neu gesetzt (wobei ich nicht weiß, warum hier keine eckigen Klammern für die effektive Adresse verwendet werden muss).
Anschließend wird der Inhalt der register eax und ebx auf den Stack gelegt. Doch woher kann ich sicher sein, dass sich dort die Magic number und die Flags befinden? Werden bei der Allokation des Speichers für diese Variablen zuerst die Prozessorregister bemüht?

4.:
Ein weiterer Samplecode (ich verzichte hier auf ein komplettes Code-Quote, der Lesbarkeit zuliebe hier der Link: http://www.osdever.net/bkerndev/Docs/basickernel.htm) eines ASM-Kernels (ich hoffe ich gehe euch damit nicht auf die Nerven ) ist mir in Teilen ebenso unverständlich:
Abgesehen davon, dass hier kein .text und .data, aber dafür wieder .bss vorhanden ist, stellt sich mir ein Problem in der .bss-Sektion:
Er reserviert hier zuerst 8KiloByte unedefinierten Speichers, und danach ein Label, und begründet dies damit, dass der Stack nach unten wächst.

SECTION .bss
    resb 8192               ; This reserves 8KBytes of memory here
_sys_stack:

Wie sieht dieser Vorgang intern aus, damit das so funktioniert?
Ein label bezeichnet normalerweise eine Sprungmarke, verwendet man also keinen jmp-befehl, so wird einfach diese Zeile ausgeführt? Verwendet man hier also das label _sys_stack, so hat man nur eine leere Zeile, also gar nichts.
Alternativ (und das glaube ich eher) wird hier damit gespielt, dass das label _sys_stack direkt nach den 8KB im Speicher angelegt wird.
Mich würde das nur einmal interessieren

5.:
Endlich Erlösung, die letzte Frage
Wobei das wieder eher eine Frage nach Bestätigung ist, da ich mir nicht wirklich sicher bin:
Auf http://lowlevel.brainsware.org/wiki/index.php/C-Kernel_mit_Grub steht dieser Code:

int main() {
  // Pointer zum Videospeicher
  char *video = (char*)0xB8000;
  // String zum Ausgeben
  char *hello = "Hello World";

  // Zuerst den Speicher leeren
  for(video+=4000; video !=(char*)0xB8000 ;video--)
     *video=0;

  // String ausgeben
  while (*hello) {
    *video = *hello;
    video++;
    *video = 0x07;
    video++;
    hello++;
  }

  // jetzt wo wir schon im Kernel drin sind, wollen wir auch nicht mehr raus ;)
  while (1);
  return 0;
}

Hierbei wird der Videospeicher mit einem char-Cast einer Adresse initialisiert. Wieso dieser cast? Ist er nötig um die 32bit Adresse in 8bit unterzubringen?
Und noch ein letztes: Wird dieser Speicherbereich vom BIOS automatisch auf den Bildschrim gebracht? Das wäre imo die einzig schlüssige Möglichkeit, da der (anscheinend um Welten langsamere) int 0x10 nie aufgerufen wird.

PS: Mir ist durchaus bewusst, dass die letzte Frage wohl besser in das ANSI C Forum gepasst hätte. Da es hier allerdings um ein sehr maschinennaher thema geht, dachte ich, dass sich die Leute im ASM-Bereich wohl besser damit auskennen als die Cler (obwohl wohl beides im Endeffekt ein bunt gemischter Haufen ist )

Ich hoffe ich habe meine Fragen klar und verständlich gestellt. Sollte ich aus müdigkeit oder anderen Gründen übersehen haben, dass im WWW ausreichend informationen vorhanden sind, meine Fragen vollkommen abzudecken, so genügt mir nat. auch ein Link zur entsprechenden Seite.
Danke an alle die meinem Geschreibsel bis hierher gefolgt sind.
Ich hoffe auf baldige antworten

MfG
Brandy

camper

Brandy (TS) schrieb:

1.:
Gibt es einen konkreten Unterschied zwischen
num:  db 100
und
num   db 100

Wie NASM das handhabt, habe ich schon wieder vergessen. Bei (einigen) anderen Assemblern besteht der Unterschied darin, dass num im ersten Fall ein bloßes Label ist (also ein Symbol, dass auf eine bestimmte Adresse verweist), während es im zweiten Fall ein Variable bezeichnet (mithin ist beim Zugriff über dieses Symbol dann automatisch der Typ der Variablen - hier Byte - bekannt).

Brandy (TS) schrieb:

Nur um sicher zu gehen, ob ich die Syntaktik verstanden habe (laut NASM Doku habe ich das):
mov eax,var1 ;<= legt die Adresse von var1 in eax ab
mov eax,[var1];<=legt den Wert von var1 in eax ab[/code]
Dementsprechend sollte das ganze auch für ADD, SUB, DEC etc gelten.
Wendet man dies jedoch auf die Situation oben an, so ergibt sich, dass man eigentlich [code]mov ecx,[esp-[sc]]
schreiben sollte, was allerdings mit einem Syntax-error seitens NASM quittiert wird.

Das (Teil-)Ergebnis einer Instruktion kann nicht gleichzeitig ihr Operand sein. [sc] erfordert ja bereits einen Speicherzugriff. Die komplexe Adressierung erlaubt es, die Summer zweier Register (eins davon mit einem konstanten Faktor 1,2,4 oder und einer Konstante direkt als Speicherreferenz zu benutzen. Also keine Subtraktion. Und ein Speicheroperand kann nicht Summand sein. Dies musst du also auf mehrere Instruktionen verteilen.

mov ecx,[sc] ; type-override ist evtl. nötig
neg ecx ; wir können bei der Adressberechnung nicht Subtrahieren
mov ecx,[esp+ecx]

Brandy (TS) schrieb:

Zuerst ist mir unklar, warum die Konstanten außerhalb jeglicher Sektionem definiert werden. Wäre es möglich, davor einfach ein
section .data
zu setzen, bzw. wieso ist die .bss-Sektion vorhanden und .data nicht?

Weil sie keinen Objektcode generieren. Es handelt sich dabei um symbolische Konstanten, die nur beim Assemblieren bekannt sind - stell sie dir wie Objektmakros in C vor. Das ist auch der Grund, warum die Stackinitialisierung per mov erfolgen kann: die Berechnung der Konstanten erfolgt bereits beim Assemblieren.

Brandy (TS) schrieb:

Anschließend wird der Inhalt der register eax und ebx auf den Stack gelegt. Doch woher kann ich sicher sein, dass sich dort die Magic number und die Flags befinden?

Das kannst du dann, wenn sie vorher so initialisiert wurden.

Brandy (TS) schrieb:

Alternativ (und das glaube ich eher) wird hier damit gespielt, dass das label _sys_stack direkt nach den 8KB im Speicher angelegt wird.

Speicher wird innerhalb einer Sektion immer mit aufeinanderfolgenden Adressen exakt so wie deklariert zugewiesen, es sei denn, es kommen irgendwelche align oder org etc.-Deklarationen.

Brandy (TS) schrieb:

5.:
Endlich Erlösung, die letzte Frage
Wobei das wieder eher eine Frage nach Bestätigung ist, da ich mir nicht wirklich sicher bin:
Auf http://lowlevel.brainsware.org/wiki/index.php/C-Kernel_mit_Grub steht dieser Code:
int main() {
  // Pointer zum Videospeicher
  char *video = (char*)0xB8000;
  // String zum Ausgeben
  char *hello = "Hello World";
 
  // Zuerst den Speicher leeren
  for(video+=4000; video !=(char*)0xB8000 ;video--)
     *video=0;
 
  // String ausgeben
  while (*hello) {
    *video = *hello;
    video++;
    *video = 0x07;
    video++;
    hello++;
  }
 
  // jetzt wo wir schon im Kernel drin sind, wollen wir auch nicht mehr raus ;)
  while (1);
  return 0;
}
Hierbei wird der Videospeicher mit einem char-Cast einer Adresse initialisiert. Wieso dieser cast? Ist er nötig um die 32bit Adresse in 8bit unterzubringen?

Weil Zeiger in C nun mal keine Zahlen sind - der Cast erzeugt einen Zeiger der auf die Adresse mit dem numerischen Wert 0xB8000 zeigt.

Brandy (TS) schrieb:

Und noch ein letztes: Wird dieser Speicherbereich vom BIOS automatisch auf den Bildschrim gebracht? Das wäre imo die einzig schlüssige Möglichkeit, da der (anscheinend um Welten langsamere) int 0x10 nie aufgerufen wird.

Das macht die Video-Hardware direkt. Sie liest einfach (im Textmodus) permanent den Speicherbereich ab 0xB8000 aus, um die entsprechenden Zeichen darzustellen.

Osbios

Nunja, dass mit dem Speicherbereich 0xB8000 muss ich berichtigen! ^^

Bei PCs gibt es zwei Möglichkeiten wie die CPU mit anderer Hardware kommunizieren kann. (Mal abgesehen von IRQ-Signalen)

Die erste Möglichkeit sind die sogenannten Ports. Das sind die beiden Befehle in und out.

Die Zweite Möglichkeit nennt sich Mapping. Dabei wird ein bestimmter Adressbereich des Speichers zu einer bestimmten Hardware umgeleitet.
Dies geschieht unter anderem auch bei dem Speicherbereich 0xB8000. In diesem Falle schreibt (oder liest) man direkt auf den Speicher der Grafikkarte. Das selbe gilt für 0xB0000 bei monochromen Grafikkarten. Und bei 0xA0000, welches für den Grafikmodus (Also kein Text, sondern Pixel) vorgesehen ist.

Es gibt einige Bereich welche standardmäßig gemappt sind. Diese kann man z.B. der osdev wiki entnehmen: http://wiki.osdev.org/Memory_Map_(x86)
Andere Bereiche werden je nach Hardware reserviert und können mittels bestimmter BIOS Funktionen ermittelt werden. Dazu gibts wieder in der osdev wiki alles Nachzulesen: http://wiki.osdev.org/Detecting_Memory_(x86)

Es ist SEHR wichtig dieses zu beachten, damit man nicht aus Versehen einen gemappten bereich wie ganz normalen Speicher benutzt!

Nobuo T

Zu 1:
AFAIK: nein.

Zu 2:
Dein Schluss aus dem Artikel aus den NASM-Docs ist falsch. Eigentlich finde ich den fuer einen Teil einer Assembler-Docu (merke: das ist keine Dokument, das x86-Assembler erklaeren will, dh. die Basics sollten dir eh schon bekannt sein) sogar recht gut geschrieben.

Aber der Reihe nach...
Erstmal: Was genau macht deine Zeile eigentlich wirklich?

mov ecx,[esp-sc]

Hier wird versucht, 4Byte an Adresse esp - sc nach ecx zu kopieren.
Dabei ist sc das Offset der "Variable" sc im Speicher.Dh. irgendeine konstante, 32Bit-breite Zahl und nicht der beim Offset sc gespeicherte Wert (bei dir 3).
Nun akzeptiert NASM so oder so AFAIK keine im Ergebnis negativen Offsets in seinen effektiven Adressen, deshalb klappt es nur mit dem "+", wird aber trotzdem nicht mal entfernt das liefern, was du dir vorstellst.

Also zusammengefasst: Wenn du in effektiven Adressen Variablen Verwenden willst, geht das nur ueber Register. Alles in einer Adresse, was nicht Register ist, ist eine Konstante, also idR. entweder irgendein Offset einer Variablen (ausgedrueckt durch den Variablennamen) oder sonstige, konstante Zahlen (direkt ausgeschrieben, oder mit equ definierte Konstanten).
So etwas wie dein

mov ecx,[esp-[sc]]

, wo du versuchst, eine Speicheradresse durch einen Speicherzugriff zu bilden, funktioniert also nicht.

Stattdessen koenntest du zum Zugriff auf das Byte 4 Bytes unter esp entweder direkt schreiben

mov ecx, [esp - 4]

oder per Konstante:

sc equ 4
;...
mov ecx, [esp - sc]

Noch zu deinem Verstaendnis der NASM-Docs:
Das hier war fast richtig:

mov eax,var1 ;<= legt die Adresse von var1 in eax ab
mov eax,[var1];<=legt den Wert, DER BEI var1 IM SPEICHER STEHT in eax ab

Wie gesagt: Variablennamen/Labels (praktisch eigentlich meistens Sprungmarken - siehe 1)
repraesentieren eigentlich immer die entsprechende Speicheradresse. (es sei denn mit equ definiert, dann entspricht das label davor der Konstanten selbst)
Eckige Klammern bedeuten idR., dass der Speicher mit der zwischen den Klammern stehenden effektiven Adresse adressiert wird.

Zu 3:

Brandy (TS) schrieb:

Zuerst ist mir unklar, warum die Konstanten außerhalb jeglicher Sektionem definiert werden. Wäre es möglich, davor einfach ein
section .data
zu setzen, bzw. wieso ist die .bss-Sektion vorhanden und .data nicht?

Es ist (zumindest bei mehreren Assemblerdurchlaeufen) fast komplett egal, wo du diese Konstanten definierst.
Ich nehme mal an, in diesem Fall geschah die Platzierung einfach aus Gruenden der Uebersichtlichkeit ganz am Anfang.

Diese Konstanten verhalten sich praktisch recht aehnlich wie Makros, die vom Praeprozessor vor der eigentlichen Assemblierung ersetzt werden (es gibt da jedoch Unterschiede - erstmal nicht so wichtig, sonst siehe docs).
Aus diesem Grund taucht eine solche Konstante auch praktisch nicht als einzelne Variable im Speicher deines Programms auf und braucht auch nicht in irgendwelchen sections definiert zu werden.

Also haettest du natuerlich auch ein "section .data" davorsetzen koennen, es waere aber ziemlich unnuetz.

Eine .data Section ist in diesem Beispiel im Grunde allgemein einfach ueberfluessig, da der Code so weit einfach keine vordefinierten Speicher-Variablen in dem Sinne enthaelt, die eine eigene section rechtfertigen wuerden.

Haette man natuelich prinzipiell machen koennen, hier aber wie gesagt einfach unpraktisch.

Eine .bss-Section braucht das Programm, um darin den Stack zu platzieren, der ja einfach aus einem uninitialisierten Speicherbereich besteht.

Zu 4:

Brandy (TS) schrieb:

Wie sieht dieser Vorgang intern aus, damit das so funktioniert?
Ein label bezeichnet normalerweise eine Sprungmarke, verwendet man also keinen jmp-befehl, so wird einfach diese Zeile ausgeführt?

Ein label heisst doch noch lange nicht, dass da in der Naehe irgendwas ausfuehrbares sein muss... Ein Label repraesentiert immer eine Zahl. Das ist idR. einfach das Offset der aktuellen Zeile im Speicher (im fertig assemblierten Programm natuerlich).
Da kann dann code folgen, nur dann macht es normalerweise Sinn, mit einem jmp hin zu springen, oder eben Daten, dann benutzt du das Label, um Variablen, bzw. Daten zu adressieren.
Folgt wirklich mal gar nichts im Quellcode, zeigt das Offset, das dieses Label repraesentiert, halt auf was auch immer im Speicher hinter dem Programm folgen mag. IdR. ist das undefiniert.

Brandy (TS) schrieb:

Alternativ (und das glaube ich eher) wird hier damit gespielt, dass das label _sys_stack direkt nach den 8KB im Speicher angelegt wird.

Das trifft es recht gut. Auf diese Weise kann man ueber das Label den "Anfang" (dh. "Ende", bzw. hoechste Adresse des Bereichs im Speicher, da Stack nach unten waechst) des Stacks adressieren.

Zu 5:

Brandy (TS) schrieb:

Hierbei wird der Videospeicher mit einem char-Cast einer Adresse initialisiert. Wieso dieser cast? Ist er nötig um die 32bit Adresse in 8bit unterzubringen?

Nein. Willst du mit Texten (Zeichen/Zeichenketten) arbeiten, ist es in C idR. sinnvoll, den Typ "char" zu benutzen. Aus diesem Grund ist der Pointer auf den Text-Buffer auch ein "char*".
Den cast brauchst du hier, damit der Compiler nicht meckert. Sollte ansonsten AFAIK theoretisch auch ohne gehen (probier es halt aus). Waere zwar kein guter Stil, wichtig ist aber vor allem der Typ.

Brandy (TS) schrieb:

Wird dieser Speicherbereich vom BIOS automatisch auf den Bildschrim gebracht? Das wäre imo die einzig schlüssige Möglichkeit, da der (anscheinend um Welten langsamere) int 0x10 nie aufgerufen wird.

Wieder: nein. Die selbst Graka (reine Hardware) lauscht (eigentlich) direkt am Bus auf diesen Adressbereich. Alles, was du da reinschreibst, geht also direkt an die Graka und damit "automatisch" auf den Schirm. Das BIOS hat damit dann nichts zu tun. Entsprechende int 10h-Funktionen machen dann intern letztendlich auch nichts anderes, als deinen Text in diesen Speicherbereich zu kopieren.
Laenger dauert das, weil ein int-Aufruf selbst einiges an Zeit frisst - vor allem im Protected Mode, und noch verschiedenster Schickschnack zusaetzlich abgearbeitet wird (Aufruf identifizieren, cursor setzen, interne Daten updaten, usw.).

Zu letzt:

Brandy (TS) schrieb:

PS: Mir ist durchaus bewusst, dass die letzte Frage wohl besser in das ANSI C Forum gepasst hätte. Da es hier allerdings um ein sehr maschinennaher thema geht, dachte ich, dass sich die Leute im ASM-Bereich wohl besser damit auskennen als die Cler (obwohl wohl beides im Endeffekt ein bunt gemischter Haufen ist )

Richtig. Zumindest der C-Teil hat nichts mit Assembler zu tun und gehoert eigentlich nicht hier her. Solltest du also weitere Fragen zu Typen und casting in c haben -> bitte im C-Forum stellen.

Ansonsten hoffe ich, dass meine Antworten halbwegs verstaendlich waren.

camper

Osbios schrieb:

Nunja, dass mit dem Speicherbereich 0xB8000 muss ich berichtigen! ^^

Bei PCs gibt es zwei Möglichkeiten wie die CPU mit anderer Hardware kommunizieren kann. (Mal abgesehen von IRQ-Signalen)

Die erste Möglichkeit sind die sogenannten Ports. Das sind die beiden Befehle in und out.

Die Zweite Möglichkeit nennt sich Mapping. Dabei wird ein bestimmter Adressbereich des Speichers zu einer bestimmten Hardware umgeleitet.
Dies geschieht unter anderem auch bei dem Speicherbereich 0xB8000. In diesem Falle schreibt (oder liest) man direkt auf den Speicher der Grafikkarte. Das selbe gilt für 0xB0000 bei monochromen Grafikkarten. Und bei 0xA0000, welches für den Grafikmodus (Also kein Text, sondern Pixel) vorgesehen ist.

Es gibt einige Bereich welche standardmäßig gemappt sind. Diese kann man z.B. der osdev wiki entnehmen: http://wiki.osdev.org/Memory_Map_(x86)
Andere Bereiche werden je nach Hardware reserviert und können mittels bestimmter BIOS Funktionen ermittelt werden. Dazu gibts wieder in der osdev wiki alles Nachzulesen: http://wiki.osdev.org/Detecting_Memory_(x86)

Es ist SEHR wichtig dieses zu beachten, damit man nicht aus Versehen einen gemappten bereich wie ganz normalen Speicher benutzt!

Alles schön und gut, aber was daran ist Korrektur und relevant fürs Thema?

Wow, ich bin wirklich beeindruckt.
Kaum hebt man sich von der Fernsehsendung gewordenen Volksverdummung mit Stefan Raab im Speckmantel ab, schon bekommt man hier zahlreiche und äußerst gute Antworten präsentiert - echt top!

Nobuo T schrieb:

Eigentlich finde ich den fuer einen Teil einer Assembler-Docu (merke: das ist keine Dokument, das x86-Assembler erklaeren will, dh. die Basics sollten dir eh schon bekannt sein) sogar recht gut geschrieben.

Mit Augenkrebs erregend meinte ich eigentlich, dass solche Dokumentationen, in allen Ausführungen und Kopien, mMn immer entweder zu groß oder zu klein geschrieben, zu bunt oder zu farbarm sind und in jedem Fall mit einem grausigen Font geschrieben worden. Zumindest habe ich diese Erfahrung oft gemacht (besonders auf www.gnu.org).

Nobuo T schrieb:

(...) wo du versuchst, eine Speicheradresse durch einen Speicherzugriff zu bilden, funktioniert also nicht.

Ich werde es dann so regeln wie camper es vorgeschlagen hat, da ich meine Variable (also wirklich nur den wert an der Adresse von sc) verändern muss.

Zu 3:
Da habe ich wohl den Wald vor lauter Bäumen nicht gesehen, wie es, wie mir im Nachhinein jetzt klar wird, wohl öfter passiert ist.

Zu 4:
Ist jetzt auch klar.
Hätte ich wohl einfacher haben können

zu 5:
Eigentlich hätte ich das merken müssen. Ich komm mir grad ein wenig belämmert vor. Ich habe irgendwie nicht registriert, dass die Adresse hier nicht nacht char sondern nach char* gecastet wird.
Gut zu wissen, was da eigentlich passiert (damit meine ich die Memory Map etc., nicht den cast ).
Ich hatte nur eine sehr vage (und letztendlich ja falsche) vorstellung und bin froh, dass das nun geklärt ist.

camper schrieb:

Alles schön und gut, aber was daran ist Korrektur und relevant fürs Thema?

Ein paar Zusatzinformationen können eigentlich nicht schaden.

Auf jeden Fall sind meine Fragen nun mehr als ausführlich beantwortet.
Sollte irgendjemand sich noch dazu berufen fühlen noch etwas zu ergänzen freue ich mich natürlich, aber fürs erste, denke ich, ist das Thema abgehakt.

Danke an die Leute die mir so schnell, nett und auch verständlich geantwortet haben (was allgemein ja nicht selbstverständlich ist)

MfG
Brandy

Osbios

camper schrieb:

Alles schön und gut, aber was daran ist Korrektur und relevant fürs Thema?

Erstens ist die Aussage falsch, da die Grafikkarte nicht den Speicher vom PC ausließt.

Zweitens macht Brandy anscheinend etwas im Bereich OS-Dev für x86. Dabei ist das Wissen über Mapping von fundamentaler Bedeutung. Ich finde jedoch, dass man alle diese Informationen schon aus meinem ersten Post entnehmen kann.

camper

Osbios schrieb:

camper schrieb:

Alles schön und gut, aber was daran ist Korrektur und relevant fürs Thema?

Erstens ist die Aussage falsch, da die Grafikkarte nicht den Speicher vom PC ausließt.

Welche? Wo bitte wurde von Grafikkarten gesprochen? Und zweifellos wird irgendein Speicher ausgelesen werden. Ob das nun regulärer RAM oder dedizierter Grafikspeicher ist für die Problematik völlig irrelevant - und praktisch treten beide Formen auf (man denke z.B. an integrierte Grafik) - und ich habe mich überhaupt nicht festgelegt.

Osbios schrieb:

Zweitens macht Brandy anscheinend etwas im Bereich OS-Dev für x86.

Kann sein oder auch nicht, jedenfalls wurde es nicht thematisiert.

Osbios schrieb:

Dabei ist das Wissen über Mapping von fundamentaler Bedeutung.

Zweifellos. Allerdings gibt es eine Menge "fundamentaler" Dinge von Bedeutung bei der OS-Entwicklung. Ich sehe nicht, dass du über all diese anderen Dinge ebenfalls berichtet hast.

Osbios schrieb:

Ich finde jedoch, dass man alle diese Informationen schon aus meinem ersten Post entnehmen kann.

Ich nicht. Ich sehe immer noch nicht die Relevanz. Wie glaubst du, hat dein Beitrag dem OP bei seinen Fragen konkret geholfen?