Themen

1

Lowlevel-Coding / 64Bit Debugger gesucht

« am: 16. October 2008, 21:13 »

Hallo,
ich suche derzeit nach einem guten, freien 64Bit Debugger, der sowohl 64Bit Befehle assemblen als auch disassemblen kann. Derzeit benutze ich den WinDbg von Microsoft. Der kann in der 64Bit-Version zwar 64Bit Befehle disassemblen, assemblen kann er allerdings nur 32Bit.

Hat da einer von euch eventuell einen Tipp für mich?

2

Lowlevel-Coding / 64Bit Integer mit FPU oder 32Bit CPU

« am: 27. April 2008, 00:27 »

Hallo, ich möchte auf meiner 32Bit CPU gerne mit 64Bit Integers arbeiten (in Assembler). Daher bin ich am Überlegen, was besser geeignet ist:
Alle Rechenoperationen zweistufig mit 32Bit Registern durchzuführen oder die 64Bit Integer für die Berechnung in die FPU zu laden.
Die Integer werden zwar in die Floating-Point Register der FPU geladen, können dort aber ohne Genauigkeitsverluste für Berechnungen benutzt werden und lassen sich ohne Probleme danach wieder als Integer auslesen (ohne manuelle Konvertierung).

Hat da einer von euch schon mal Erfahrungen mit gesammelt und kann mir eventuell einen Tipp geben, was schneller geht?

3

OS-Design / Hauptspeicher defragmentieren

« am: 24. October 2006, 20:36 »

Hallo, ein bekanntes Problem bei Betriebssystemen ist ja die Fragmentierung des Hauptspeichers, wenn es lange genug läuft. Bei dem Speicher, der von den User-Prozessen belegt wird ist das ganze ja weniger schlimm, da dieser vom System ja oft nur als 4kB Pages betrachtet wird, aber was ist mit dem Heap des Kernels? Wenn das System mehrere Tage läuft und einige tausend malloc und free Operationen ausgeführt hat dürfte es schon recht schwierig werden einen größeren zusammenhängenden Block zu allocieren. Nun habe ich mal irgendwo gelesen, dass zB Linux die Möglichkeit hat den Speicher zu "defragmentieren". Ist so etwas eigentlich bei einem in C geschriebenen Kernel möglich, oder ist damit womöglich nur das Defragmentieren der Page-Tabelle gemeint?

4

Lowlevel-Coding / Groß- und Kleinschreibung bei 8.3 Dateien

« am: 16. September 2006, 22:36 »

Hallo, man kann ja auch bei Dateien die per 8.3 (also im DOS-Format) gespeichert wurden zB zwischen test.txt und TEST.TXT unterscheiden und zwar ganz ohne zusätzlich lange Dateinamen zu verwenden, wie es zB bei Test.txt von Nöten wäre. Ich hab da mal etwas rumgespielt und herrausgefunden, dass dabei das Byte 0xC in dem Directory-Eintrag eine Rolle spielt. In sämtlichen Dokumentationen sind jedoch die 10 Bytes nach dem Attributsbyte als Platzhalter markiert. Hat da Jemand genauere Informationen drüber?
Wie ich herausgefunden habe gibt es folgende Einstellungsmöglichkeiten:
Bei Files:
0x00 TEST.TXT
0x10 TEST.txt
0x08 test.TXT
0x18 test.txt

Bei Dirs:
0x08 dir
0x00 DIR

5

Lowlevel-Coding / Gap3 bei einer 720kb Floppy

« am: 30. August 2006, 14:22 »

Hallo, kann mir einer sagen welche Länge ich für die GAP3 Bereiche bei einer 720kb Floppy-Disk einstellen muss (zum Formatieren und zum lesen/schreiben)? Alle anderen Werte sind klar: 2 Heads, 80 Tracks und 9 Sektoren/Track.
Danke schonmal im Voraus.

6

Lowlevel-Coding / Farbtabelle im Textmodus setzen

« am: 28. July 2006, 20:46 »

Hallo, ich habe ein Problem beim Setzen der Farbtabelle im Textmodus. Ich benutze zum Setzen der Farbe den folgenden Code:

Code: [Auswählen]

outb(0x3c8,farbnr);
outb(0x3c9,r);
outb(0x3c9,g);
outb(0x3c9,b);
Wenn ich nun zB in einer Schleife die Farben 0-15 (die 16 Fordergrundfarben) auf Graustufen (0-63 je r,g,b) setzen will, so funktioniert das für alle Farben wunderbar, außer für die Farbe mit dem Index 6. Die bleibt weiterhin braun.
Kann mir einer Sagen nach welchem Muster die Farben im Textmodus verteilt sind in der Farbtabelle?

7

Lowlevel-Coding / Zeichenbreite im Textmodus

« am: 27. July 2006, 01:53 »

Hallo, im Textmodus ist es ja möglich übder die Anzahl der Scanlines (Index 0x9 des Ports 0x3D5) die Maximale Anzahl an Scan-Lines zu setzen (von 0-31), wobei 15 der Standard ist bei 80x25 und bei 80x50 dies einfach auf 7 gekürzt wird. Ist es möglich auch die Breite eines Zeichens zu verändern?

Und wo wir schonmal dabei sind: Gibt es eigentlich einen 160x? Textmodus, oder wird das (bei Linux zB) einfach im Grafikmodus gemacht (was sehr warscheinlich ist, da man sonst beim Booten in der Konsole keinen lustigen Pinguin sehen könnte...)?

8

OS-Design / Implementierung des Exception-Handlers

« am: 26. July 2006, 15:44 »

Hallo, ich bin grad dabei in mein OS einen richtigen Exception-Handler zu implementieren, bisher habe ich einfach nur Interrupt-Gates benutzt, die auf entsprechende Stellen in meinem Kernel-Code verwiesen haben. Ich habe nun vor den Exception-Handler in einem eigenen Task laufen zu lassen und diesen per Task-Gate aufzurufen, dies hätte den Vorteil, dass ich mittels des TSS-BackLink-Feldes bestimmen kann, welcher Task unterbrochen wurde und gleich in dessen TSS zB den eip und alle anderen Register ausöesen kann. Nun ist aber mein Problem, dass ich bei einem Task-Gate keinen Offset angeben kann, da ja der eip des gerufenen Tasks verwendet wird, wie könnte ich nun unterscheiden welche Exception aufgetreten ist ohne für jede einen eigenen Task definieren zu müssen? Oder hab ihr das ganz anders implementiert, und wenn ja, wie?

9

Lowlevel-Coding / Realisierung von Exception Handling

« am: 15. July 2006, 17:47 »

Hallo, ich überlege seit einiger Zeit wie genau bei C++ Programmen das Exception Handling realisiert wird. Damit meine ich, wie genau es funktioniert, dass der richtige catch-Block aufgerufen wird, nachdem eine Exception "geworfen" wurde? Ein kleines Beispiel:

Code: [Auswählen]

try{
  throw(5);
}catch(float f){
}catch(int i){
}
Das Einfachste wäre es ja nun, wenn die throws fest mit den entsprechenden catch-Blöcken verdratet wären, aber das geht ja schonmal aus dem Grunde nicht, da es ja auch "unerwartete" Exceptions gibt (wie zB Divison durch 0).
Meine Vorstellung wäre nun, dass beim Eintritt in den Try-Block eine Liste mit allen Exception-Typen, die gefangen werden sollen, angelegt wird (hier float und int (für die, die es nicht wissen, man kann auch primitive Datentypen "werfen", nicht nur Exception-Objekte)) und zusätzlich zum Typ die Adresse des Behandlungsblocks. Wenn nun ein throw auftritt wird diese Liste durchgeschaut und der entsprechende Block aufgerufen (falls vorhanden). Aber nun ist die Frage (falls dies so gemacht wird), ob diese Liste vom Programm, oder vom Betriebssystem verwaltet wird, da dieses ja auch Exceptions wirft, wenn das Programm mist baut (wie zB bei Division durch 0). Außerdem werden die Exceptions ja über ihren Datentyp auseinandergehalten, wie aber geschieht das zur Laufzeit? Ich meine C++ ist ja nicht Java, wo jedes Objekt seinen Typ weiß...

Hat irgendwer da eine Idee, oder auch eine Webadresse (alles was ich gefunden habe erklärt lediglich die Benutzung von Exceptions)?

MM

10

Lowlevel-Coding / Division ohne div

« am: 01. April 2006, 02:41 »

Hallo. Ich möchte eine 64-Bit Division mit 32-Bit Registern realisieren (oder allgemein für Datentypen >32-Bit). Mit Addition/Subtraktion ist das ja kein Problem mit zB dem ADC Befehl, jedoch wie kann man das mit der Division bzw Multiplikation lösen? Man stelle sich einfach mal die folgende Rechnung vor:

Code: [Auswählen]

0x10 0000 0000 / 0x02 0000 0000
Das ist mit div nicht zu lösen. Aber es gibt ja soweit ich weiß einen Algorithmus mit dem man die Multiplikation/Division recht effizient durchführen kann (noch aus der Zeit als es keine dib/mul Befehle gab). Hat den zufällig jemand von euch grad zur Hand?

MM

11

Lowlevel-Coding / Eigener C++ Compiler

« am: 19. February 2006, 21:54 »

Hallo, habe in den letzten Tagen meinen aktuellen C-Compiler zu einem C++ Compiler aufgebohrt. Neben C und Assembler Code kann man nun auch die meisten fortgeschrittenen Techniken der OO nutzen (ich hatte keine Lust mir eine Lib für dynamische Listen in C zu schreiben, da man mit C++ ja auch einfach eine Klasse List machen kann...).

Wäre nett, wenn der Eine oder Andere sich das Teil mal ansehen würde und mir seine Meinung schreibt (oder auch wenn was nicht geht):
http://wwwstud.fh-zwickau.de/~micmo/compiler.html
oder direkt
http://www.fh-zwickau.de/~micmo/files/coding/dc2.zip

MM

12

Lowlevel-Coding / Seltsamer Opcode von loop

« am: 17. February 2006, 01:09 »

Hallo, ich habe heute mit erstaunen festgestellt, dass beim loop Befehl die Bedeutung der Prefix-Bytes offenbar umgedreht zu sein scheint:
Dieser Code geht nur ein mal durch die Schleife (ich gehe von einem 16-Bit Codesegment aus (gelöschtes D-Bit) oder im RealMode):

Code: [Auswählen]

mov ecx,0x10001
mark:
loop mark ; Mit Prefix 0x66

Dieser Code geht 0x10001 mal durch die Schleife:

Code: [Auswählen]

mov ecx,0x10001
mark:
loop mark ; Mit Prefix 0x67

Laut Intel ist der Prefix 0x66 für Operand Size Overrides und 0x67 für Address Size Overrides. Warum wird also wenn ich ecx ansprechen will der Prefix für das Ändern der Adressgröße verwendet und nicht das für den Operand?

Damit ist aber noch nicht genug: Wenn ich das Loop in einem Codeteil verwenden will der an einer Adresse über 0xFFFF liegt, so muss ich den Prefix 0x66 (zusätzlich) verwenden. Ich hätte die Belegung der beiden Präfixe genau umgekehrt erwartet.

Könnte da Jemand zur Klärung beitragen?

MM

13

Lowlevel-Coding / Zeiger auf lokale Variablen

« am: 11. February 2006, 14:10 »

Hallo, ich bin grade am Grübeln wie man das folgende Problem am besten Lösen kann:
Mal angenommen man hat diese zwei Funktionen:

Code: [Auswählen]


int gvar;
void func(int *ptr){
  *ptr=0;
}
void main(void){
  int lvar;
  func(&lvar);
  func(&gvar);
}
Die Variable lvar befindet sich auf dem Stack und gvar im Datensegment. Wenn man nun keine Far-Zeiger verwendet (also nur 32-Bit Adressen) so müssen Stack und Datensegment sich ja überlappen, so dass man auch mit ds: auf die Adresse von lvar zugreifen kann (der Stack befindet sich also im Datensegment).
Weiß jemand von euch, wie dieses Problem zB bei Windows gelöst wird? Eventuell genauso?

Für normale Anwendungen funktioniert dieses Konzept zumindest recht gut, jedoch jetzt will ich einen Kernel schreiben, dessen API-Funktionen per Interrupt aufgerufen werden. Das Problem ist nun, dass ich zwar das Datensegment des Kernels in der API-Funktion laden kann, jedoch weiterhin das Stacksegment des Aufrufers benutzen muss. Dadurch würde das Programm abstürtzen, wenn wie in func() auf einen Zeiger einer lokalen Variable zugegriffen würde.
Wie könnte man dieses Problem am elegantesten lösen?

MM

14

OS-Design / Idee für Kernelmodule

« am: 07. January 2006, 21:25 »

Hallo, ich habe vor diverse Funktionen meines Kernels in Module auszulager und mein bisheriges Konzept sah so aus, dass ich im Datensegment des Kernels beim Laden eines Moduls speicher allociere und das Modul an diese Stelle lade. Dann wird ein Codesegment eingerichtet, welches den Code des Moduls umfasst (immernoch im Kerneldatensegment). Als Daten und Stacksegment soll das des Kernels mitbenutzt werden. Um auf globale Daten des Moduls zugreifen zu können (welche per standard ja bei Offset 0 beginnen würden) habe ich es so gemacht, dass in Modulen beim Zugriff auf globale Daten noch edx auf die Adresse draufgezählt wird (wo der Offset der Moduldaten im Kerneldatensegment drinsteht).
Dies funktioniert auch soweit ganz gut, nun ist nur das Problem, dass ich nun alle Libs die ich so habe ein zweites mal compilieren müsste um eine spezielle Modulversion zur Verfügung zu stellen (mit +edx für globale Daten).
Hat da Jemand eine besser Idee?
Wie ich in einigen Threads gelesen habe ersetzen einige von euch nach dem Laden des Moduls alle Adressen mit dem richtigen Offset, das scheint mir aber etwas zu aufwändig zu sein, ebenso wie ein extra Datensegment für jedes Modul zu spendieren.

MM

15

Lowlevel-Coding / 48 Bit-LBA, warum?

« am: 04. December 2005, 14:28 »

AUf der Seite von Microsoft kann man nachlesen, dass man für Festplatten über 137GB 48-Bit-LBA braucht:
http://support.microsoft.com/default.aspx?scid=kb;en-us;305098
(ich habe es auch selber erfahren, als ich mir meine 320GB Platte gekauft habe).

Aber warum muss das sein? Wenn man per LBA bei 0 beginnend 512 Byte große Blocks ansprechen kann, dann kommt man ja immerhin auf 4294967295 Blocks (2048GB) und bei 137GB ergebens sich maximal 287309824 Blocks. Warum braucht man da also 48-Bit-LBA?

MM

16

Lowlevel-Coding / Ermittlung des Roots bei Festplatten

« am: 01. December 2005, 16:53 »

Hallo,

ich schreibe grad einen Bootsektorprogramm für eine FAT16 Partition und bin grad am Grübeln wie ich die Blocknummer rausbekomme an der 1. meine Partition beginnt und 2. mein Root (eher zweitrangig, da man es bei FAT32 ja mit im Bootsektor steht und ich es mir bei FAT16 zur Not ja auch ausrechnen kann). Ich lese von der Festplatte mittels LBA um die Umrechnung per CHS zu umgehen und nun ist mein Problem, dass ja zB meine erste Partition mit dem Block 63 beginnt, und die Zweite zB mit 65376. Gibt es noch eine andere Möglichkeit herauszufinden, wo sich der geladene Bootsektor auf der Platte befindet, außer im MBR nachzusehen?
Weil wenn ich erst im MBR nachsehen muss glaub ich nicht, dass ich das alles in einen Sektor quetschen kann...

MM

17

Lowlevel-Coding / Was kommt nach dem MBR

« am: 30. November 2005, 22:36 »

Hallo,

bei einer Festplatte liegt ja der MBR im Sektor 0 und der Bootsektor der ersten Partition liegt im Sektor 63, was ist aber mit den anderen 63 Sektoren 1-62? Ist dort Platz für einen Bootmanager, oder wie werden sie genutzt?

MM

18

Lowlevel-Coding / Page-Cache löschen

« am: 22. October 2005, 21:37 »

Hallo,

ich habe eine Funktion geschrieben, die im Protected Mode in einer Schleife immer 4096 Byte von der Adresse 0 ins Datensegment kopiert.
Dabei wird per Paging immer ein anderer Speicherbereich an die Adresse 0 gemappt. Mein Problem ist nun, dass ich in der Schleife aber immer nur die Daten lese, die ich schon im ersten Durchlauf geleseh hatte.
Meine Theorie ist nun, dass sich die Adresse aus dem ersten Schleifendurchlauf im TLB befinden, und also gar nicht in der Pagetabelle nach der aktuellen Adresse geschaut wird. Kann ich das irgendwie umgehen wie zB das Leeren der Pipeline mit dem Far-Jump beim einschalten der P-Modes?
Oder ist eventuell auch meine Theorie falsch?
Ich könnte ja einfach mal versuchen von 32 anderen Adressen zu lesen, um den TLB zu leeren, aber wer sagt denn, dass der TLB auch bei heutigen Prozessoren nur 32 Adressen speichert...

MM

19

Lowlevel-Coding / Nicht benutzbarer Speicher

« am: 16. October 2005, 20:25 »

Hallo,

ich habe eben nach lager Fehlersuche festgestellt, dass ich den Speicher so ab 0xE0000 nicht beschreiben kann (alle Bits bleiben immer gesetzt).
Ich dachte immer, dass im Protected Mode der einzige nicht benutzbare Speicher der von 0xA0000-0xDFFFF wäre, wo die Grafikkarte ihren Speicher reinmapt.
Jetzt entdecke ich aber bei mir in den Unterlagen, dass angeblich von 0xCC000-0xEFFFF irgend welche ROM-Erweiterungen sind, was zwar mein Problem erklären würde, sich aber mit dem Bereich der Grafikkarte überschneidet.
Der Fehler tritt nicht mehr auf, wenn ich den bereich 0xA0000-0xFFFFF meide.
Meine Fragen sind nun: Wie groß ist dieser Bereich genau, gibt es davon noch mehr und ist der Bereich überall gleich groß?
Und wo wir schonmal dabei sind, noch eine Frage, die mich schon immer interessiert hat: Kann man der Grafikkarte auch sagen, dass sie den Grafikkartenspeicher an eine andere Adresse mappen soll?

MM

20

Lowlevel-Coding / Grow Down Segmente

« am: 30. September 2005, 19:12 »

Hallo, ich möchte ein Grow Down Stack-Segment anlegen und hab da mal eine Frage, da es nicht genau aus meinem Buch hervorgeht, wie dabei die Größe des Segments festgelegt wird:

Wenn ich im Descriptor das ED (Expansion Direction) Bit setze, dann verstehe ich das so, dass man mit der Basisadresse die Adresse angibt, ab der der Offset gezählt wird und mit dem Limit-Feld gibt man die obere Segmentgrenze an. Aber wie wird dann die untere Grenze angegeben?

MM