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 - XanClic

Seiten: 1 2 [3] 4 5 ... 14
41
Lyrisches Eck / Re: Frohes Fest
« am: 25. December 2011, 13:11 »
Frohe Weihnachten und gleðileg jól. :-)

PS: Dies dürfte das dritte Jahr sein, dass ich einen Weihnachtssmilie in meine Signatur hab. Jedes Jahr war ich zu faul, ihn zu wechseln und dann war wieder ein Jahr rum und die Zeit gekommen, in der er wieder gepasst hat. :-D
42
OS-Design / Re: Verrückte Idee
« am: 23. December 2011, 17:02 »
Wenn du überhaupt in den LM gehst, ja (wobei du dann auch im PM den Code emulieren könntest, wenn du den Emulator einmal eingebunden/geschrieben hast).

Wenn nicht, dann meine ich das auch, wobei die letzten sieben Worte dann natürlich wegfallen. :wink:
43
OS-Design / Re: Verrückte Idee
« am: 23. December 2011, 03:26 »
  • vm86 ist keine Emulation, sondern native Ausführung des Codes.
  • Vor allem für x64-Betriebssysteme wurden bereits fertige, relativ portable 8086-Emulatoren geschrieben, die auf die Ausführung von BIOS-Interrupts ausgelegt sind.
  • Die Idee der Rekompilierung anstatt Emulation des Codes wurde nach dem, was ich so gelesen habe, generell letzten Endes als zu hoher Aufwand angesehen. Geschwindigkeit spielt bei der Ausführung von BIOS-Code keine Rolle. Nachdem nun besagte Emulatoren bereits vorhanden sind, gibt es also keinen Grund, eine solche Rekompilierung ernsthaft zu erwägen (PoC ausgenommen).

Man bedenke vor allem, dass es im PM wirklich keinen sinnvollen Grund gibt, überhaupt BIOS-Code zu emulieren. vm86 ist vorhanden, funktioniert und ist wirklich prinzipiell sehr einfach zu implementieren, jedenfalls wesentlich einfacher, als es ein Emulator jemals sein könnte.

Befindet man sich jedoch im LM, so sind wie gesagt bereits fertige 8086-Emulatoren vorhanden, die den vm86 ersetzen können. Zu selbigen wird mWn auch jedem geraten, der eine entsprechende Frage auf osdev.org stellt (http://forum.osdev.org/viewtopic.php?f=1&t=23203#p187714).

Abschließend noch fünf Sekunden googlen: https://gitorious.org/x86emu.


Wie gesagt, als PoC ist Rekompilierung des BIOS sicherlich interessant. Einen ernsthaften Nutzen kann man daraus jedoch imho nicht ziehen.

PS: Ich mag PoCs. :wink:
44
OS-Design / Re: Verrückte Idee
« am: 22. December 2011, 23:43 »
Du müsstest aber praktisch alle Opcodes umwandeln, da zum Beispiel die meisten Word-Operationen im 32-Bit-PM einen Prefix bekommen, im RM nicht; bei den DWord-Operationen ist es dementsprechend genau umgekehrt. Und bei jeder Operation eine Exception auslösen... Das kannst du, nennst sich Trapflag, aber da kannst du gleich den ganzen Code emulieren.
45
OS-Design / Re: Verrückte Idee
« am: 22. December 2011, 19:39 »
Ich halte davon, dass mir die Idee vor allem bekannt vorkam. Und siehe da (nur eine Auswahl):

Ich äußere mich jetzt nicht weiter zu dem Thema (außer, dass ich bei jedem solcher Threads immer dachte „viel zu viel Aufwand für viel zu wenig Nutzen“), weil eigentlich alles in diesen Threads gesagt wurde. Ansonsten einfach mal weiter auf osdev.org nach “BIOS code translation” oder so suchen.
46
Softwareentwicklung / Re:Virtual Box
« am: 01. June 2011, 13:52 »
Also, wenn ich das „far“ durch ein „dword“ ersetze, tut es bei mir mit NASM ohne Probleme (also „jmp dword 0x0000:_start“).
47
Softwareentwicklung / Re:Virtual Box
« am: 30. May 2011, 13:28 »
(des kann doch bestimmt simple .img-Dateien)
Bei Festplatten nicht.

Also folgendes (FASM, sollte auch mit NASM tun):
use16
org 0x7C00

jmp     far 0x0000:_start
_start:

xor     ax,ax
mov     ds,ax
mov     ss,ax
xor     sp,sp

mov     si,string
push    word 0xB800
pop     es
xor     di,di

mov     cx,80*25
rep     stosw

xor     di,di

print_loop:
lodsb
test    al,al
jz      printing_done
stosb
mov     al,7
stosb
jmp     print_loop

printing_done:
cli
hlt

string: db "WORKSFORME", 0

times 510-($-$$) db 0

dw 0xAA55

times 1474560-($-$$) db 0

tut bei mir wunderbar:


PS: Mein Manko mit FETT-Schreiben kenn ich bereits, aber bitte keine neuen Antworten, dass man es auch ohne FETT lesen kann.
Ändert nichts daran, dass es stimmt. :roll:
48
Lowlevel-Coding / Re:Fehler bei IRQ-Behandlung
« am: 05. May 2011, 21:06 »
An sich würde ich darauf tippen, dass du entweder a) den PIC nicht geremappt hast, dass also IRQ 0 zu einem Interrupt 8 führt (der dann wie eine Exception aussieht), oder b) die IDT initialisiert, geladen und das IF gesetzt hast, bevor du den PIC geremappt hast, sodass sich ein IRQ 0 als Interrupt 8 durchmogelt, bevor der PIC nach deinen Wünschen initialisiert ist. Zumindest mit letzterem hatte ich auch schon Probleme, wenngleich das eher Race Conditions waren (hin und wieder kam an der Stelle zwischen IDT- und PIC-Initialisierung eben zufällig ein IRQ 0 an).
49
IRQ 1 ist nach dem Start des Computers Interrupt 9, das ist mit Sicherheit ein Grund, warum dein Interrupthandler nicht aufgerufen wird (der sich um Interrupt 1, die Debugexception, kümmert). :wink:
50
OS-Design / Re:relocatable kernel
« am: 12. March 2011, 14:52 »
Das man unter x64 RIP-relative Code schreiben kann, weiß ich, aber ich bin mir eigentlich verdammt sicher das shared Libraries unter Linux PIC Code ist und da benutzt man keine relocatable´s.
Na gut. :-)
51
OS-Design / Re:relocatable kernel
« am: 11. March 2011, 23:15 »
Wie kommst du darauf, dass PIC erst ab x64 möglich ist? Wie funktionieren dann shared Libraries?
Anders als das, was er meint, nehme ich an. Der PIC bei x64 verwendet RIP-relative Adressierung, soweit ich weiß. Dadurch kann man Executables schreiben, die man irgendwo in den Speicher packen kann, wo sie dann einfach laufen. Bei x86 muss man im Allgemeinen eine Relocatable generieren, die erst von einem dynamischen Linker verarbeitet werden muss, bevor man sie ausführen kann. So funktionieren zumindest auch Shared Libraries.

Man kann natürlich auch auf x86 echten PIC schreiben, aber es gibt einen Unterschied zwischen Relocatables (Shared Libs) und PIC.

52
OS-Design / Re:relocatable kernel
« am: 11. March 2011, 18:53 »
Hm, mal eine ganz blöde Frage: Wozu willst du denn den Kernel zur Laufzeit (also nach der Initialisierung) überhaupt relozieren? Mir fällt dafür kein vernünftiger Grund ein.
Naja grub kann den kernel ja nicht in adressen packen, wo man ihn aber vielleicht gerne hätte. zB. an die 4GB grenze.
Wieso will man den Kernel nach so weit oben im RAM packen (vor allem, wenn man nicht weiß, wie viel RAM der Rechner hat)? :?

Zum Startupcode: Wieso nicht einfach gleich den Kernel an die gewünschte (virtuelle) Adresse linken und dann halt im Startupcode schnell Paging initialisieren¹? Ich kenne keinen Higher-Half-Kernel, der dafür relozierbar sein muss…

¹Da gibt es natürlich auch noch andere Wege, s. z. B. http://wiki.osdev.org/Higher_Half_Kernel.
53
OS-Design / Re:ACPI - Referenzimplementation
« am: 31. January 2011, 18:55 »
deswegen nutzt es hier keiner.
Och, doch, aber nur ein bisschen Code zum Herunterfahren, den ich mir von osdev.org geklaut habe. :wink:

Und die andere Frage ist natürlich auch, was ACPI sonst so bringt (außer Tabellen für SMP, aber da gibt es auch die Floating Pointer Structure, die im Allgemeinen ausreichen dürfte)...
54
OS-Design / Re:L4-ähnlicher Kernel
« am: 23. January 2011, 15:56 »
Bei dem Vergleich mit den 100m Lauf ist aber 0,1s schon gewaltig ;)
Tja. Wenn du fünf Jahre deines Lebens vergeuden möchtest, von mir aus. :wink:
Und auf nem Computer kommt es halt drauf an wie oft der Code ausgeführt wird (auch Kleinvieh macht mist).
Es geht hier eben nicht um die Frage, ob ich einen C-Kernel verbessern kann, wenn ich an einigen Stellen handoptimierten Assemblercode einfüge. Es wurde oft genug gesagt, dass das auf jeden Fall so ist. Wie MNemo schreibt, es geht darum, ob es sinnvoll ist, den ganzen Kernel in Assembler zu schreiben.

Zitat von: xanclic
Mir persönlich ist es ziemlich egal, ob sich ein Compiler sein „Wissen“ selbst beibringt, oder ob er es beigebracht bekommt.
Das ist die typische Aussage "der Strom kommt ja aus der Steckdose".
Ich weiß zwar nicht genau, was du damit meinst, aber ich würde dem zustimmen. Mir geht es ziemlich am Hinterteil vorbei, wer den Compiler wie geschrieben hat. Das Ergebnis zählt, und dieses ist gut.

Naja, ein OS hat igendwo auch nen strlen, aber der Compiler sollte das eigentlich ganz gut optimieren können ;)
Was er im Allgemeinen sogar tut. Und nochmal: Es geht nicht darum, dass der Compiler immer den perfekten Code erzeugt. Es ist nur eine Frage vom Verhältnis von Aufwand zu Nutzen. Von fünf Jahren gegen 0,1 Sekunden.

Hat eigentlich irgendjemand hier das gelesen was ich gequotet habe?
Wenn du die Aussage von Svenska meinst: Ja, und ich stimme ihr sogar zu. Dennoch würde ich das so nie als Argument verwenden und auch Svenska hat das imho eher wieder zurückgenommen.


Ich fasse mal meine Meinung zusammen: Ein Compiler erzeugt selten perfekten Code. Wie gut der Code ist, den ein Mensch schreibt, das hängt von seinen Fähigkeiten ab, von der zur Verfügung stehenden Zeit, etc. pp.. Im Allgemeinen brauche ich für eine Optimierung des Codes hin zu einer Stufe, die compileroptimiertem würdig ist, ein Vielfaches der Zeit, die ich für das Schreiben des Codes in der Hochsprache benötige, abgesehen davon, dass ich persönlich eh länger dafür brauche, überhaupt Assemblercode zu schreiben als den Hochsprachencode (schon allein, weil es normalerweise mehr Zeichen sind, die man zu tippen hat).
Eine weitere Optimierung dauert dann nochmal so lange. Insgesamt ist es deshalb für den größten Teil eines Großprojektes sinnvoll, ihn in einer Hochsprache zu schreiben. Potenziert sich der Nutzen von Handoptimierung hingegen erheblich (extrem häufig durchlaufene Funktionen, etc.), so ist es wiederum für einzelne Teile sinnvoll, sie von Hand zu optimieren – wenn das Ergebnis besser als das des Compilers ist.
55
OS-Design / Re:L4-ähnlicher Kernel
« am: 23. January 2011, 15:16 »
Intelligenz erfordert doch aber auch die Fähigkeit zu lernen oder? Und dazu sind Compiler noch nicht fähig, man muss sie programmieren, aber von alleine schaffen sie es noch nicht.
Dass sie es jetzt können, habe ich ja auch nicht gesagt. Ich wollte nur zeigen, dass letzten Endes auch das menschliche Gehirn nicht viel mehr als ein Computer ist, wenn auch sehr viel komplexer als unsere heutigen Rechner.
Aber um auf das Lernen einzugehen: Ist es denn wichtig, dass Compiler von sich aus lernen können? Macht sie das besser? Mir persönlich ist es ziemlich egal, ob sich ein Compiler sein „Wissen“ selbst beibringt, oder ob er es beigebracht bekommt.

Man würde also unendlich lange für ein bestimmtes komplexes Problem in Assembler brauchen, das man in endlicher Zeit mit Hilfe eines Compilers/Hochsprache lösen kann?
Nein. Ich wollte nur zeigen, dass die Aussage „Es ist theoretisch möglich“ nicht viel Sinn in sich trägt, da ich dann nicht mal einen Menschen zum Programmieren brauche.

Und auch du setzt wieder Compiler mit GCC oder meinetwegen noch LLVM gleich. Es gibt aber noch andere Compiler, die weniger guten Code erzeugen.
Die nehme ich dann aber definitiv nicht.
Du kannst keinen guten Assemblerprogrammierer mit einem schlechten Compiler vergleichen. Geht nicht. :roll:

Um es mal auf einen anderen Fall zu übertragen. Man nehme sich 2 Sportler und die laufen gegeneinander 100m, aber es hat nicht der gewonnen der weniger Zeit benötigt hat, sondern der der das auch noch mit weniger Training geschafft hat.
Nicht ganz richtig. Es hat schon der gewonnen, der weniger Zeit benötigt hat, aber: Wenn der Zeitunterschied marginal (0,1 s), aber der der Trainingsunterschied gewaltig (drei Monate gegen fünf Jahre) ist, sollte sich der Gewinner mal fragen, ob es das wirklich wert war.

Auch ein moderner Compiler will erstmal auf eine neue Architektur portiert werden, dass nimmt Zeit in Anspruch. Es ist also durchaus möglich, das auf einem neuem Mikrokontroller, ein Assemblerprogrammierer wesentlich schneller ein Problem lösen kann (in Form von Code) als jemand der erst noch nen Compiler portieren muss (nur den Codegenerator und eventuell den Optimierer).
Klar. Das hat erik doch auch schon geschrieben. Und? Wer von uns, der nicht gerade seine eigene Architektur entwickelt, schreibt sein OS für eine nicht von GCC/Binutils unterstützte Architektur?
56
OS-Design / Re:L4-ähnlicher Kernel
« am: 23. January 2011, 14:12 »
Du sagst also im Endeffekt ist es durchaus möglich besseren Code als ein Compiler zu schreiben ;)
Es geht mir nur darum, das die Behauptung ein Mensch kann auf keinen Fall besseren Code erzeugen als ein Compiler nicht gehalten werden kann. Sicher wenn man Einschränkungen macht, aber rein theoretisch ist es halt möglich und das wird grundsätzlich ausgeschlossen.
Ich kann auch /dev/urandom (oder die Ausgabe von 10000 Affen an Schreibmaschinen) in eine Datei pipen, versuchen, die zu assemblieren und das Ergebnis ausführen, wenn der Dateiinhalt syntaktisch in Ordnung war. Dann teste ich, ob er auch semantisch in Ordnung ist. Das mache ich dann so oft, bis ich ein paar korrekte Ergebnisse zusammen habe, die schneller als der compilergenerierte Code sind und suche mir dann davon das schnellste aus.
Kann man auch machen, ist theoretisch möglich. Dauert nur halt ein kleines bisschen. Wenn man aber ∞ Affen nimmt, wäre das beste Ergebnis sogar sofort da. :lol:

Nach eurer Logik wäre dann ja jeder Computer intelligent, ist er aber nicht, nur so weit wie man ihn programmiert hat!
Du weißt schon, dass ein menschliches Gehirn (meiner Annahme nach das Ding, was wir zum Assemblercode schreiben nutzen) aus Synapsen besteht, die einzeln ohne Probleme von einem Computer simuliert werden können? Wenn man einen genügend leistungsfähigen Computer hätte, könnte der mal nebenbei ein ganzes menschliches Gehirn simulieren. Da könnte man dann auch einen intelligenten Compiler drauf laufen lassen.
Das menschliche Gehirn ist also auch nur so weit intelligent, wie es „programmiert“ worden ist. imho.
57
OS-Design / Re:L4-ähnlicher Kernel
« am: 20. January 2011, 21:59 »
Assemblerprogrammierer respektieren auch die Arbeit von C-Programmierern, auch dann wenn unsere Gründe etwas in Assembler zu programmieren für uns wichtiger sind, als jene Gründe die C-Progerammierer für ihre Arbeit haben.
Ich habe lange genug in Assembler programmiert, um ganz genau zu wissen, wieso ich jetzt lieber C nehme.
58
tyndur / Re:Name für die GUI
« am: 13. January 2011, 21:28 »
Ja, aber das ü wird recht kurz ausgesprochen und hinter dem r folgt ein halbes L (wenn ich mich an die Aussprache von XanClic erinnere).
Spreche ich so undeutlich? :-D

Abgesehen davon bin ich kein Isländer, ich weiß also auch nur, dass es ungefähr wie tindür ausgesprochen wird (mit gerolltem r), habe das Wort aber nie jemanden sagen hören (außer mich selbst und dich beim Wiederholen :-D).
59
Offtopic / Re:Welche Linuxdistro empfehlt ihr?
« am: 10. January 2011, 11:32 »
Ansonsten empfehle ich dir LFS, da haben XanClic und ich beste Erfahrungen mit ;-) (Gut, eher er, denn bei mir wollt's nicht booten -.-).
Bis ich eines Tages aus Versehen meine KDE-Bibliotheken gelöscht habe, ja. :-D
60
Offtopic / Re:Eigene CPU
« am: 28. November 2010, 23:11 »
Erik: Ich fand das nur komisch, weil du auch geschrieben hattest (wimre), dass die RM-Segmentierung lediglich ein merkwürdiger Weg zum Erhalten von einem MB Speicher mit 16-Bit-Adressen sei. Meiner Meinung nach ist das der einzige Zweck, und damit ist jede Dynamik nicht Sinn der Sache – inwiefern der Weg aber merkwürdig ist, erschloss sich mir nicht ganz. :-)
(Die Aussage von PNoob („Die Segmentierung ist Schei**“) klang für mich auch eher so wie „Wer hat sich das denn ausgedacht“ und nicht wie „Wieso kann die nicht so viel wie die x86-Segmentierung“)

PNoob: Da das hier angefangen wurde, schreib ich auch einfach hier rein und überlass den Rest frech den Mods. :-D
Seiten: 1 2 [3] 4 5 ... 14

Einloggen