Nachrichten

1

Lowlevel-Coding / Re: 'Invalid or unsupported executable format' bei übergabe von Parametern

« am: 23. November 2009, 12:27 »

Das ist der selbe fehler wie bei mir. Wie groß ist der Kernel? > 1.0MB?

Übergib -n oder --nmagic and ld und es sollte wieder gehen.

2

Lowlevel-Coding / Re: ld gibt falsche Addressen raus

« am: 16. November 2009, 15:23 »

Na ja ich hab den GRUB ja nicht gebaut, das ist noch eine uralt-version. Seit Ewigkeiten benutz ich die weil sie ja immer funktioniert hat. Gebaut hab ich die noch auf Ubuntu 8.04, glaub ich.

Aber es klappt ja und das kernelende wird offenbar auch ordentlich aligned mit --nmagic.

3

OS-Design / Re: Spezialisierter GC

« am: 14. November 2009, 14:34 »

Noch ne Frage:

Ein absolut simpler Memory Manager wäre doch einfach einfach ein Pointer, der auf das ende des kernels zeigt. Wenn man zB 8 byte haben will, wird der pointer zurückgegeben und um 8 byte erhöht.
Natürlich ist das absolut unpraktisch, aber wäre doch für den anfang einfach genug.

4

Lowlevel-Coding / Re: ld gibt falsche Addressen raus

« am: 12. November 2009, 10:32 »

Jetzt geht's. 

Vielen Dank.

5

Lowlevel-Coding / ld gibt falsche Addressen raus

« am: 11. November 2009, 20:41 »

Hi,

ja eigentlich wollte ich an was anderem Arbeiten, aber nachdem ich mein Ubuntu geupdatet hab, weigerte sich GRUB plötzlich, meinen Kernel zu laden. Nach einem kurzen Blick auf die Datei erklärte sich die Weigerung: Die Datei war ohne zusätzlichen Code oder irgendwelche Änderungen von 12 KB auf 1.0012 MB gewachsen. Weil der ld nach dem Update die 1 MB Grenze in die Datei eingefügt hatte (der typ ist .elf). Ich hab es mir im Hexcode angesehen, das erstem Megabyte ist mit 0x00 gefüllt.

Ich hab nicht mal was am linkerscript geändert. Ich werd das hier mal posten:

Code: [Auswählen]

OUTPUT_FORMAT(elf32-i386)
OUTPUT_ARCH(i386)
ENTRY(start)
phys = 0x100000;
SECTIONS
{
.text phys : AT(phys)
{
code = .;
*(.text)
*(.rodata)
start_ctors = .; *(.ctors) end_ctors = .;
start_dtors = .; *(.dtors) end_dtors = .;
. = ALIGN(0x1000);
}

.data : AT(phys + (data - code))
{
data = .;
*(.data)
}

.bss : AT(phys + (bss - code))
{
bss = .;
*(COMMON)
*(.bss)
. = ALIGN(0x1000);
}
end = .;
}
Ist die selbe, die ich immer nehme. Hab ich vielleicht eine gravierende Änderung verpasst? Ich hab nichtmal bemerkt, dass es so einen großen Versionssprung beim ld gab...

Ich hoffe ihr könnt mir helfen, weil mich das nervt, dass ich sonst nicht weiterarbeiten kann =/

6

OS-Design / Re: Spezialisierter GC

« am: 11. November 2009, 20:26 »

Ich glaub dazu muss ich gleich mal einen neuen Thread aufmachen... ich krieg meinen Kernel nicht mehr gestartet bie gleichem code und setup! 

7

OS-Design / Re: Spezialisierter GC

« am: 09. November 2009, 22:51 »

Mein Plan ist - auch wenn es jetzt absolut unnütz klingt - eine Art LISP-Machine. Der Kernel ist praktisch nur ein Interpreter, und die Interpreter eben eine Prozedur. Erstmal soll es single-tasked sein, aber es spricht eben nichts dagegen, dass mehrere Instanzen des Interpreters laufen (die praktisch vom interpreter gestartet werden). Diese würden dann alle auf den selben Pool zugreifen für die Daten, und weil die Programme alle LISP sind, ist eigentlich egal, woher die Daten kommen - sind ja alles listen und pointer gibt es nicht.

--Aber vorerst muss das alles liegen bleiben. Seid dem Update spuckt der ld nur noch einen 1 MB kernel aus, und ich weiß nicht warum. Es hat wohl damit zu tun, dass ich eben 1 MB als Grenze angebe beim Linken, aber vor dem Update hat das super funtioniert. Ich hab das linkerscript ein paar mal umgestellt, aber er kompiliert die 0x100000 in alle Addressen mit ein. Das wiederum lädt der GRUB nicht mehr, also totalverlust 

8

OS-Design / Re: Spezialisierter GC

« am: 09. November 2009, 21:38 »

Ich wollte ohne paging auskommen, aber wäre dass dann nicht besser? Ein pool ist immer zusammenhängend mit den pages, das klingt doch verlockend.

9

OS-Design / Re: Spezialisierter GC

« am: 09. November 2009, 11:53 »

Müssten die denn nicht konstant groß sein während der gesamten laufzeit, damit die sich nicht untereinander stören? Wenn ein Pool über den speicher fragmentiert ist, ist der vorteil dahin.

10

OS-Design / Re: Spezialisierter GC

« am: 09. November 2009, 11:27 »

Danke, ist mir auch irgendwie aufgefallen, dass ich eigentlich einen Memory Manager meine. Aber ich will eben auch, dass während der Interpretation speicher wieder freigelegt wird.

Außerdem weiß ich noch nicht, ob nun die String-Daten oder die Listen-Daten überwiegen, daher wären ja die Speicherpools mit fester Größe keine so gute Idee, oder? Natürlich könnte ich ja die LISP-Strings als Listen aus char darstellen...

Aber danke für die Antwort, ich sehe mir erstmal ein klassisches malloc an.

11

OS-Design / Spezialisierter GC

« am: 06. November 2009, 20:16 »

Hallo,

Ich wollte mal ein paar Experten dazu befragen, bevor ich mich an die Konzipierung mache.
Mein Kernel hat bisher Keyboard und einen einfachen Bildschirm-Support (also das einfachste). Was ich wollte, war, den Kernel sofort in einen Interpreter für meinen LISP-Dialekt überzuleiten, so dass die Konsole praktisch der Interpreter ist. Dann sind die Befehle praktisch LISP-Funktionen.

Alle LISP-Daten sind natürlich Listen, die ich mit einen GC verwalten wollte. Dieser alleine Wäre kein Problem, da alle Elemente der verketteten Liste gleich groß sind und ich daher die Elemente aus einem großen Array picken kann, verwaltet mit einer Bitmap.

Aber ich brauche auch String-Daten - eben für strings, symbolnamen und die Closures. Ich weiß nicht genau, wie ich diese verwalten soll.

Sollte ich vielleicht 2 GCs basteln, einer für listen und einer für "sonstiges"? Oder einen komplizierten, der alle Datentypen verwalten kann (auch wenn ich nicht genau weiß, wie dieser aussehen sollte). Ich wollte nur fragen, ob ihr dazu professionelle Meinungen habt, die mir helfen könnten.

Danke.