Beiträge anzeigen

Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.


Nachrichten - FreakyPenguin

Seiten: 1 2 [3] 4 5 ... 15
41
Offtopic / Re: wo sind TeeJay und mastermesh eig. gebilieben?
« am: 24. June 2009, 21:57 »
Zitat von: matheguru am 24. June 2009, 21:39
werden eig. mal wieder admins gewählt?
Warum sollte man neue wählen wenn die Aktuellen ihre Sache gut machen und sogar aktiv sind? ;-)
42
Lowlevel-Coding / Re: 64 bit fpc und elf32
« am: 17. June 2009, 18:32 »
Zitat von: bitmaster am 17. June 2009, 16:52
PS: Was sind eigentl. so die Unterschiede zwischen fpc und gpc?
Der eine(gpc) ist offensichtlich kaputt, der andere erst wenn man genauer hinsieht. *g*
43
tyndur / Re: 0.2.1 - Beta- und RC-Phase
« am: 14. June 2009, 21:35 »
So, nach den zahlreichen Tests und Bugreports hier(;-)) ist jetzt der erste Release Candidate für die 0.2.1 bereit. Darin wurden im Vergleich zur Beta hauptsächlich Bugs gefixt(die oben angegebenen, und noch ein paar weitere). Wir würden uns jetzt besonders über Tests freuen und hoffen, dass sie vorallem Positives zu Tage führen werden, auch wenn wir Bugreports wohl oder übel auch akzeptieren müssen... ;-)

So nun aber genug Text, hier die Links:

Wir wünschen euch Viel Spass damit!
44
Lowlevel-Coding / Re: GRUB und Windows
« am: 11. June 2009, 20:58 »
Die wurden ursprünglich über Nacht generiert, von den einzelnen Revisionen im SVN. Heute geht das aber wmnat häufiger. Und nein, das sind nicht die offiziell stabilen, sondern eben die aktuellsten Entwicklerversionen.
45
Lowlevel-Coding / Re: GRUB und Windows
« am: 11. June 2009, 19:14 »
Am besten nimmst du einfach irgend ein Floppy-Image auf dem schon GRUB drauf ist. Beispielsweise eine Nightly von tyndur(http://nightlies.tyndur.org) und löschst den tyndur-Kram. ;-)
46
Offtopic / Re: Disassembler
« am: 06. June 2009, 11:38 »
Naja auch bei einem Assembler musst du das in die richtigen Sections der Objektdatei packen, läuft also aufs selbe raus.
Und bei flachen Binaries kann das eh nicht unterschieden werden, aber die will man auch nicht wirklich benutzen.
47
OS-Design / Re: Programm laden und ausführen
« am: 05. June 2009, 13:16 »
Zitat von: ChristianF am 05. June 2009, 13:03
Anmerkung:
program_header->p_memsz beinhaltet 0x1b. Führe ich nur "program_header->p_memsz % PAGE_SIZE" aus und gebe das Ergebnis aus, bekomme ich 0x1b, was ja nicht korrekt ist.

Warum ist das falsch? Ich nehme mal an, PAGE_SIZE ist grösser als 0x1b, dann stimmt das doch genau?
48
Lowlevel-Coding / Re: Aufbau der GDT
« am: 02. June 2009, 17:16 »
Wenn ich dich richtig verstehe, bist du nicht sicher in welcher Reihenfolge die Bytes der Zahlen zusammengesetzt werden? i386 ist eine little endian-Architektur. Das heisst, das niederwertigste Byte, einer Zahl wird zuerst abgelegt.

Nehmen wir als Beispiel die Hexdezimale Zahl 0x12345678. Hex deshalb, weil da 2 Ziffern immer einem Byte entsprechen, hier also vier Bytes. So ist das etwas übersichtlicher als mit den binären Zahlen.
Die Bytes werden nun, wie schon gesagt, mit dem niederwertigsten Byte voran gespeichert. Also: 0x78 0x56 0x34 0x12

Deine zwei Bytes ergeben also die Zahl: 1111110101000000b (0xFD40).
49
Lowlevel-Coding / Re: PowerPC
« am: 02. June 2009, 10:36 »
Ich hab da mal ein Bisschen was zusammengefrickelt, mit viel rumprobieren und Code wälzen tut es schliesslich was ich möchte. Wie korrekt es ist, weiss ich aber nicht... ;-)

Code: [Auswählen]
/* Libc und so... */
#define NULL ((void*) 0)
void* memcpy(void* dest, const void* src, int len);
void* memset(void* dest, int c, int len);
int strlen(char* str);


/** Struktur, die bei OFW-Aufrufen uebergeben wird */
struct ofw_args
{
  const char* func;
  int arg_count;
  int ret_count;
  void* args[10];
} __attribute__((packed));

/** Zeiger auf den OFW-Entrypoint */
int (*ofw_call)(struct ofw_args* args);

/* Nette Openfirmware-Funktionen */
int ofw_finddevice(char* name)
{
    struct ofw_args args_chosen = {
        .func = "finddevice",
        .arg_count = 1,
        .ret_count = 1,
        .args = {
            name
        }
    };
    ofw_call(&args_chosen);
    return (int) args_chosen.args[1];
}

void ofw_getprop(int device, char* prop, void* buf, int len)
{
    struct ofw_args args_getprop = {
        .func = "getprop",
        .arg_count = 4,
        .ret_count = 1,
        .args = {
            (void*) device,
            prop,
            buf,
            (void*) len
        }
    };
    ofw_call(&args_getprop);
}

void ofw_write(int handle, void* buf, int len)
{
    struct ofw_args args_write = {
        .func = "write",
        .arg_count = 3,
        .ret_count = 1,
        .args = {
            (void*) handle,
            buf,
            (void*) len
        }
    };
    ofw_call(&args_write);
}

int ofw_read(int handle, void* buf, int len)
{
    struct ofw_args args_read = {
        .func = "read",
        .arg_count = 3,
        .ret_count = 1,
        .args = {
            (void*) handle,
            buf,
            (void*) len
        }
    };
    ofw_call(&args_read);
    return (int) args_read.args[3];
}

void ofw_exit()
{
    struct ofw_args args_exit = {
        .func = "exit",
        .arg_count = 0,
        .ret_count = 0,
    };
    ofw_call(&args_exit);
}

void ofw_puts(char* str)
{
    int handle;
    ofw_getprop(ofw_finddevice("/chosen"), "stdout", &handle, sizeof(handle));
    ofw_write(handle, str, strlen(str));
}

char ofw_getc(void)
{
    int handle;
    char c;
    ofw_getprop(ofw_finddevice("/chosen"), "stdin", &handle, sizeof(handle));
    if (ofw_read(handle, &c, 1) == 0) return 0;
}



/* Hier wird in unser "Kernel" gesprungen */
void _start(unsigned long r3, unsigned long r4, unsigned long r5)
{
    ofw_call = (void*) r5;

    ofw_puts("Hello World!\r\n");
    ofw_puts("Willst du EXIT druckst du Taste...\r\n");
    while (ofw_getc() == 0);
    ofw_exit();
}



/* Tolle Libc */
void* memcpy(void* dest, const void* src, int len)
{
    char* dc = dest;
    const char* sc = src;
    while (len--) *dc++ = *sc++;
    return dest;
}
void* memset(void* dest, int c, int len)
{
    char* dc = dest;
    while (len--) *dc++ = c;
    return dest;
}
int strlen(char* str)
{
    int len = 0;
    while (*str++) len++;
    return len;
}
50
OS-Design / Re: Managed Operating System
« am: 25. May 2009, 16:10 »
Prinzipiell ja, die Frage ist nur wie klein der werden wird... ;-) Mono wird sicher auch einige Ansprüche an die Libc haben.
51
OS-Design / Re: Managed Operating System
« am: 25. May 2009, 14:40 »
Jo da kommt man nicht drum rum.
52
OS-Design / Re: FreeBasic: Software Multitasking
« am: 25. May 2009, 12:41 »
Eigentlich musst du nur alle Program Headers (mit Typ LOAD) der ELF-Datei durchgehen und den Inhalt der Datei an die angegebene Stelle im Adressraum des Prozesses legen, und noch mit Nullen auffüllen wo mehr in den Adressraum soll als in der Datei ist.

In Code ausgedrückt (zwei unabhägnige Versionen):

Und zur Frequenz: Es kommt darauf an. ;-) Da probierst du am besten selbst aus, was für dich am besten tut.
53
OS-Design / Re: Managed Operating System
« am: 25. May 2009, 10:28 »
Hm diesen Begriff habe ich so bis jetzt noch nicht gehört. Aber ich gehe mal davon aus, dass das ein Betriebssystem ist, das in managed Code geschrieben ist. Das heisst, dass der Code nicht direkt von der CPU ausgeführt wird, sondern von einer virtuellen Maschine. Eine solche Architektur hat den Vorteil, dass die VM je nach Sprache, viele Fehler abfangen kann (beispielsweise buffer overflows).
54
tyndur / Re: 0.3 - Ideen und Ziele
« am: 24. May 2009, 12:17 »
Hm jo, das mit der Bash stimmt natürlich. Und da müsste man mal testen, wie die so mit unseren netten Pfaden auskommt. ;-)

Ich glaube make geht ohne fork/exec, wie ich bei genauerem Hinsehen festgestellt habe. Zumindest solange man keine Jobs will. Was nicht einfach so gehen dürfte im Moment, ist das $(shell), wenn ich das richtig in Erinnerung habe.

Das wäre auch mal eine nette Erweiterung für unsere libc: ein popen(), oder allgemein pipes. Wobei das vielleicht noch ein bisschen frickelig werden könnte...
55
Lowlevel-Coding / Re: C Kernel, ld : Unrrecognized File format
« am: 23. May 2009, 18:50 »
Welchen Kompiler benutzt du denn nun? mingw? Oder den von PorkChicken?

Und welches Format spuckt dein gcc aus? (Kannst du mit objdump -h nachsehen)
56
tyndur / Re: 0.3 - Ideen und Ziele
« am: 23. May 2009, 18:42 »
Hm ich glaube da fehlt nicht mehr viel. Das habe ich schon mal angefangen, weiss aber nicht mehr, wieviel noch fehlt.

Überhaupt hätte ich gerne so die wichtigsten Tools, die man so braucht, auf tynur gesehen. Einige Beispiele: tar,bzip2,bc,wget,grep,find,... Die meisten davon sollten eigentlich nicht allzu aufwändig sein zu portieren.
57
OS-Design / Re: Programm laden und ausführen
« am: 22. May 2009, 19:20 »
Zitat von: ehenkes am 22. May 2009, 18:08
Brauche ich hier schon einen user stack oder ist der hier identisch mit dem kernel-stack? Muss das in TSS->esp3 TSS->ss3 eingetragen werden?
Sobald du Ring3-Prozesse hast, brauchst du einen zusätzlichen Stack. Dieser sollte dann auch mit User-Privilegien gemappt sein, sonst fliegen die Pagefaults frischfrölich. ;-)
58
tyndur / Re: 0.3 - Ideen und Ziele
« am: 22. May 2009, 18:37 »
Ist doch toll, da kann man die  Erwartungen nur übertreffen.  :-P
59
OS-Design / Re: Programm laden und ausführen
« am: 22. May 2009, 11:24 »
So, ich versuche mich jetzt auch mal daran, das zu erklären. Ich bin zwar nicht PorkChicken, aber vielleicht hilfts ja trotzdem. ;-)

Also gehen wir das Ganze mal Schritt für Schritt durch, ausgegangen vom folgenden einfachen Usermode-Programm:
Code: [Auswählen]
int main() {
    puts("Hallo Welt!");
    return 0;
}
Nun wie schon von taljeth erwähnt ist die main()-Funktion nicht der direkte Einsprungspunkt in den Task. Dafür hast du in der libc eine Funktion _start:
Code: [Auswählen]
void start() {
    int result;
    // Hier würde man normalerweise noch sowas machen wie Parameter vom Kernel holen und parsen, aber das lassen wir der Einfachheit halber mal weg.

    result = main();
    syscall_exit(result);
}
Dabei ist es wichtig, dass die Funktion syscall_exit() nie zurückkehrt von einem Aufruf. Es handelt sich dabei ja, wie der Name sagt, um einen Syscall, der als Interrupt umgesetzt wird.

Wenn nun der Kernel diesen Syscall erhält, entfernt er den aktuellen Task aus dem Scheduler, und zestört (Speicher des Tasks und interne Strukturen werden freigegeben) ihn. Danach muss er logischerweise einen neuen Task schedulen, da der bisherige nicht mehr existiert.

In tyndur geht das so, dass der Interrupt-Handler eh immer den nächsten zu benutzenden Stackpointer zurueckgibt, und auch cr3 für den neuen Task lädt, wenn er gewechselt hat. Damit muss der Syscall-Handler im Wesentlichen nur current_task neu setzen und der Interrupthandler übernimmt dann den Rest.

So, ich hoffe, dass ich dich damit nicht noch mehr verwirrt habe.

Edit: Bäh, der PorkChicken war schneller. Aber ich lasse das jetzt trotzdem mal stehen. ;-)
60
tyndur / Re: Pascal
« am: 22. May 2009, 08:54 »
Du musst das rtl-Verzeichnis aus dem FPC-Quellcode nach src/modules/pas/lib/rtl/include kopieren oder verlinken. Danach nochmal make clean und make und es sollte tun.
Seiten: 1 2 [3] 4 5 ... 15

Einloggen