Nachrichten

41

Lowlevel-Coding / Re: GAS: ASCII-Strings (für INT10/13h) in ASM-Programm einbinden

« am: 23. December 2011, 21:37 »

Bei NASM gibt es da dieses Direktiv incbin (http://www.nasm.us/xdoc/2.09.10/html/nasmdoc3.html#section-3.2.3). Wie das unter gas aussieht weiß ich nicht.

42

Lowlevel-Coding / Re: GAS: ASCII-Strings (für INT10/13h) in ASM-Programm einbinden

« am: 23. December 2011, 20:05 »

Wenn du auf den Grafikspeicher Direktzugriff hast, kannst du das mit dem INT10 sausen lassen und deine Strings direkt in den Grafikspeicher kopieren.

43

OS-Design / Re: Verrückte Idee

« am: 23. December 2011, 15:38 »

Du meinst also ich soll im PM Mode den BIOS Code mithilfe des VM86-Modes ausführen und den VM86/Realmode im LM emulieren.

44

Softwareentwicklung / Re: OS-Dev mit Intelassembler

« am: 23. December 2011, 15:30 »

Es gibt ein paar Unterschiede beim Syntax der Befehle:

MASM:
mov BYTE PTR[EAX], 1
NASM:
mov BYTE[EAX], 1

NASM akzeptiert aber auch die Schreibung mit "PTR"

MASM:
mov esi, OFFSET SPEICHER
NASM:
mov esi, SPEICHER

Nasm kennt nur eine Sorte von Symbolen, das Label. Dahinter wird immer die Referenz auf ein Objekt verstanden. Für den Speicherzugriff müssen also immer eckige Klammern verwendet werden.

45

OS-Design / Re: Verrückte Idee

« am: 22. December 2011, 20:06 »

Naja, man muss ja nicht gleich alle Opcodes umwandeln. Wenn man dem Prozessor sagen könnte, das er sich bei bestimmten Opcodes beschweren soll (Interrupt auslösen), wäre mir schon geholfen.

46

OS-Design / Re: Verrückte Idee

« am: 22. December 2011, 18:00 »

Eigentlich gehts mir dann schon ehr um die Videofunktionen.

47

OS-Design / Verrückte Idee

« am: 22. December 2011, 17:34 »

Mir ist grad eine ziemlich verückte Idee gekommen:
Und zwar:
Was haltet ihr davon, wenn ich ein Programm schreibe, das das BIOS und die IVT ausließt und den BIOS Code (Besonders die wichtigen Teile) dann so umschreibt, das er auch im PM läuft (Addresse müssen natürlich relokalisiert werden und Segmentladebefehle werden durch Interrupts ersetzt.)

Was haltet ihr davon?

48

OS-Design / Re: Wie geht ihr an die Entwicklung eures OS heran?

« am: 19. December 2011, 17:19 »

Naja, ich bin ehr so der Planer. Da ich mir aber vorgenommen habe, kein OS zu schreiben. Das wird eh nichts und ich will ja schon einen Compiler bauen Deshalb sind die OS-Ideen ehr wenig konkret. Auf der anderen Seite probiere ich natürlich trotzdem das ein oder andere aus, auch im OS Dev Bereich.

49

Softwareentwicklung / Re: Welche Compiler

« am: 18. December 2011, 19:09 »

Naja du hast recht. Ich hab unter MinGW noch nichts gescheites Compiliert bekommen. Meinen Clang hab ich mir unter Linux gebaut.

50

Softwareentwicklung / Re: Welche Compiler

« am: 15. December 2011, 20:21 »

Ich weiß nicht ob es schwieriger ist einfach nen Linux in einer VM aufzusetzen und dort den vorhandenen GCC zu nutzen. Kann dafür nur den VMWare-Player empfehlen, einfach die Tools installieren und man kann dann nen Shared-Ordner anlegen, unter Windows coden und unter Linux (in der VM) kompilieren. Bei mir ist das ganze um das 3.5fache schneller.

Könntest du auch machen. Ist aber mit Abstand lahmer (Compilieren ist harte CPU-Arbeit) und weniger elegant. MinGW funktioniert für das reine Compilieren von Programmen gut, und ist auch nicht als so schwer aufzusetzen, gcc, g++, gccirgentwas, gdb und die Binuits werden unterstützt und laufen ziemlich vernünftigt. msys stellt eine vernünfige Umgebung (Pfade, Shell zu Verfügung). Schwierig wird es natürlich wenn du Python (Mein Remote-control-Shellscript klappt hierbei nicht immer richtig, bei git und fbc aber schon.), oder irgendwelche ausgefallenen Sachen wie iso-maker, usw. brauchst.

51

Offtopic / Re: Auf Android entwickeln

« am: 15. December 2011, 20:14 »

Naja, so teuer ist die Abwärtskompatiblität dann doch nicht. Wenn man sich die Effekte mal anschaut fällt einen auf ....

Auf die Gefahr hin das man mir gleich Unhöflichkeit vorwerfen wird aber das ist eine recht naive Betrachtung, in Wirklichkeit ist das schon ein wenig komplexer. AMD hat damals bei den ersten 64Bit-Opterons was von 5% mehr Transistoren für den 64Bit-Modus erzählt und 5% sind bei einem Chip der schon einige Millionen Transistoren hat ne ganze Menge und dabei darf man nicht vergessen das ein Großteil der Transistoren für Cache usw. drauf gehen und da dürften die Änderungen eher marginal gewesen sein so das ich persönlich vermute wenn man nur den puren CPU-Kern betrachtet kommen da eher 15 bis 20% Zuwachs bei raus.

Du solltest aber auch die Leitungen betrachten. Eine Verdopplung der Wortbreite und 8 zusätzliche Register kosten einfach, auch wenn man keine Abwährtskompatibilität berücksichtigt. Dazu kommen noch die kosten für zusätzliche SIMI Befehle usw., die ebenfalls unabhängig von der Abwährtskompatiblität sind.

Gruß Sannaj

52

Offtopic / Re: Auf Android entwickeln

« am: 12. December 2011, 21:20 »

Kann man nicht so ne Hijektin-Option einbauen, die beim Start fragt, ob ein bestimmtes Kernelmodul geladen werden soll, das das System Hiject und ein neues Startet?

53

Softwareentwicklung / Re: Welche Compiler

« am: 12. December 2011, 21:18 »

Das Umschalten des Syntax erfolgt über das Assemblerdirektiven

Code: [Auswählen]

.intel_syntax noprefixund

Code: [Auswählen]

.att_syntax prefoxHierbei bedeutet .intelsyntax das der Intelsyntax benutzt wird und nopräfix, das die Register ohne vorrangestelltes "%" angesprochen werden können. Der Assembler nimmt zu Beginn AT&T Syntax an.
Zu beachten ist, das gcc, diese Option nicht kennt oder irgendwie bearbeitet. (Gcc hat überhaupt keine Ahnung was die Inline Assemblerbefehle bedeuten.) Aus diesem Grund muss der Assembler am Ende des Aufrufs wieder auf das eingestellte Emitdirektiv (normal AT&T-syntax, mit „-masm=intel“ Intelsynatx) umgestellt werden.

54

Lowlevel-Coding / Re: Speicherzugriffe

« am: 10. December 2011, 13:35 »

Code: [Auswählen]

Seg dw 0x0800
...
mov bx, Seg
mov es, bx
mov dword ptr [es:0x100], 1

Alternativ kannst du den Opcode auch manuell schreiben, auch wenn das nicht so wahnsinnig angenehm ist.

Code: [Auswählen]

Seg dw 0x0800
...
mov bx, Seg
mov es, bx
db 0x26, 0xC6    ; Use ES, MOV r/m8, imm8
db 0x06            ;r/m8=add16 (modR/M byte)
dd 0x100           ; add16=0x100
db 1                 ; imm8=1


55

Softwareentwicklung / Re: Welche Compiler

« am: 10. December 2011, 13:15 »

Bei den Assemblern ist es genauso. Gas ist bei MinGW dabei, für Nasm, Fasm und Yasm gibt es Windowsportierungen.

56

Offtopic / Re: Auf Android entwickeln

« am: 10. December 2011, 12:49 »

Naja, so teuer ist die Abwärtskompatiblität dann doch nicht. Wenn man sich die Effekte mal anschaut fällt einen auf, das die Unterschiede gar nicht so groß sind.
Für den 16 Bit PM braucht man nur eine Flag und ein Xor Gatter. Bei Opcode 0x66 wird die Flag gesetzt. Bei jeder Operation wird dann  mit dieser Flag und der is32bitCode Flag im versteckten Teil von CS ein exclusives Oder durchgeführt. Kommt dann 1 raus, braucht man eine 32 Bit Operation.
Auch für den Real Mode, braucht man blos eine bisschen andere Ladevorrichtung für den versteckten Teil der Segmentregister und einen anderen internen Interupthandler.

Aber zurück zum Thema. Ich kritisieren an ARM auch gar nicht die mangelnde Abwärtskompatiblität. (ARM ist nämlich größtenteils schon abwärtskompatibel.), sondern einfach, das es keine verlässliche Plattform gibt. Paging war jetzt vielleicht ein bisschen unglückliches Beispiel, schließlich steht x86 in der Hinsicht auch nicht besser dar. Sondern ehr die Tatsache, das das, was sich um die CPU befindet nur mangelhaft standardisiert ist. Natürlich brauche ich in einem sprechenen Teddybären keine Bildschirmfunktionalität (und auch kein Paging), aber es wäre doch schön, wenn man bei allen Geräten, die einen Bildschirm haben, diesen auch gleich ansprechen können, zumindest wenn man nur ne primitive Fehlerausgabe haben will.

Durch geeignete Betriebssystem kann das ganze natürlich ein wenig standardisiert werden.

57

OS-Design / Re: Nicht unterbrechbarer Kernel

« am: 09. December 2011, 20:06 »

Also es gibt unterbrechbare Kernel, Linux kann das zum Beispiel. Allerdings macht so etwas nur bei Monolithischen Kernels Sinn. Hierbei werden die ehr unwichtigen Kernelmoduel (sprich Hardwaretreiber), als Task mit Ring 0 Rechten behandelt. Die Idee, das du ein Kernel internes cooperatives MT, über ein externes präemeratives Multitasking legen willst, macht die Sache natürlich komplizierter. Eine Interessante Idee ist es aber trozdem. Du musst dir auch im klaren sein, das Funktionen wie vmm_alloc immer atomar ausgeführt werden sollten, weil es sonst zu bösen Überraschungen kommst. Wenn du meinst, das es sich lohnt den Aufwand trotzdem zu betreiben würde ich eine Funktion einbauen, die dem Schedule sagt, das er eine bestimmte Aktion atomar ausführen werden muss. Der Schedule sollte in diesem Fall nur eine Markierung setzten, die Uhr aktualisieren und dann weitermachen. In die entsprechenden Kernelfunktionen müsste dann so etwas wie eine "atomar Anfang"/"atomar Ende" Algorithmus eingebaut werden. Die "atomar Anfang"-Funktion setzt eine dafür markierte Flag auf den "no shedule interrupts - time out not reached mode". Wird nun der Shedule aufgerufen setzt er " den "no shedule interrupts - time out reached mode". Die "atomar Ende" - Funktion setzt den Wert auf den Standart zurück und führt den Rest des Shedules aus, wenn "time out reached mode" da war. (Aufpassen, das nicht zusätzlich auf noch der PIT gleichzeitig den Shedule starten kann.)

Das ein Programm, das auf einen Schlag einen ganzen Gigabyte Speicher haben will, halte ich für relativ unwahrscheinlich. Ausführbare Dateien und dylib's selbst sind in der Regel wesentlich kleiner und auf solch große Dateien sollte man nur noch partiell zugreifen.

58

Offtopic / Re: Auf Android entwickeln

« am: 09. December 2011, 19:29 »

Das ist halt der Große Nachteil von ARM, die Architektur wurde bei ihrer Verbreitung ziemlich in den Mikrokontrollerbereich abgedrängt, wo sie sich nur extrem unzureichend standardisiert wurde. Auch heute konnte sich die Architektur nicht vernünftig von ihrem  Bei x86, kannst du sicher sein, das sich alle Sachen ab der Plattform auf der sie eingeführt wurden auch immer genauso verhalten.
Bei ARM ist das nicht so. Deshalb wird im Wiki auch nicht beschrieben, wie man den Bildschirm mit Zeichen bestückt, sondern nur die "Debug"-Ausgabe über die serielle Schnittstelle an den Emulator. Auch das dort beschriebene Paging ist mit leichter Vorsicht zu genießen. Aus diesem Grund denke ich dass ARM nicht keine echte Chance bei Systemunabhängien Plattformen haben wird, es sei denn es ändert sich in naher Zukunft irgendetwas.

59

Offtopic / Re: [erledigt] Komisches Problem ...

« am: 06. December 2011, 22:51 »

Nennt das ganze doch in Hardwarediskussion um. 

60

Offtopic / Re: [erledigt] Komisches Problem ...

« am: 06. December 2011, 21:55 »

Ich glaube ihr hab den Rekord für das Thema gewonnen, bei dem am längsten weiter disskutiert wurde, obwohl es geschlossen ist.