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

Seiten: 1 ... 75 76 [77] 78 79 ... 81
1521
tyndur / Re: Codestil
« am: 01. May 2005, 14:44 »
Zitat von: hannibal
argh! bitte nicht. ich find das irgendwie bloedsinn hier extra klammern zu machen, wo man doch alles schon so aufschreiben kann:


if(x == y)
    y = ((x + y) * (x - y))/2;

ok, meinetwegen
1522
tyndur / Device-Filesystem
« am: 29. April 2005, 16:31 »
Bei Linux hat so weit ich das verstanden hab jeder Treiber eine probe()-Funktion. Die wird vom Kernel aufgerufen und der Treiber sagt dann ob er mit dem Device was anfangen kann oder nicht.

@mastermesh: ich glaube, du meinst die PCI IDs. Die sind leider wie der Name schon sagt nur für PCI-Devices...
1523
tyndur / Codestil
« am: 29. April 2005, 16:18 »
Welchen Codestil werden wir für die Assembler und C-Dateien nehmen? Ich bin dafür, dass wir uns auf einen möglichst einheitlichen Stil einigen, damit der Code gut lesbar und wartbar bleibt.

Für Assembler würde ich vorschlagen, dass Instruktionen mit einem Tab eingerückt werden. Labels werden nicht eingerückt. Dadurch heben sich Labels sofort sichtbar von den Instruktionen ab und die Struktur des Codes ist gut sichtbar. Außerdem sollten Doppelpunkte hinter Labels Pflicht sein, es sei denn es folgt ein db, dw oder ähnliches. Zeilenumbrüche vor Labels und zusammenhängenden Codeabschnitten können die Lesbarkeit noch verbessern, aber strecken bei übermäßigen Einsatz auch die Länge des Codes deutlich.

Beispiel
label1:
    mov eax, foo
    sub [bar], eax
label2:
    or eax, eax
    jnz label1
foo db "Foo Bar", 13, 10, 0


Das wars eigentlich schon speziell zu Assembler, was mir so einfällt. Fangen wir also mit dem wohl strittigsten Punkt bei der C Formatierung an: Dem Einrücken und dem Setzen von Klammern. Ich halte folgendes für sinnvoll: (ist glaub ich Kernighan&Richie Style)
 - Immer einrücken mit 1 Tab (im Editor sollte es auf 4 Zeichen eingestellt sein)
 - Hinter einer geöffneten, geschwungenen Klammer ("{") folgt ein Zeilenumbruch und es wird eine weitere ebene tiefer eingerückt.
 - eine Einrückstufe zurück vor einer geschlossenen, geschwungenen Klammer ("}")
 - geschwungene öffnende Klammern bei Funktionensdeklarationen immer auf die nächste Zeile
 - geschwungene öffnende Klammern nach if, for, while, etc immer auf die selbe Zeile.


Beispiel:
void tuwas(char *arg);

int main(int argc, char **argv)
{
    int i;
    for(i = 0; i < argc; i++) {
        tuwas(argv[i]);
    }
}

void tuwas(char *arg)
{
    char *foo, *bar;
    if(arg != NULL) {
        if(arg[0] == '-') {
            /* ... */
        } else if(arg[0] == '/') {
            /* ... */
        } else {
            /* ... */
        }
    }
}


Auch hinter einem einzeiligen if, for, while usw, kommen immer geschwungene Klammern. Aber ich denke bei sehr kurzen {}-Blöcken ist es auch sinnvoll den komplett auf die Selbe Zeile wie die if-Abfrage zu schreiben.
if(arg == NULL) { doSomething(); }

Im Beispiel habe ich die Pointer-Sternchen auch schon direkt an den Variablennamen geschrieben. Eigentlich gehört der Pointer zum Typ, aber es ist eine fiese Falle, wenn man schreibt:
char* foo, bar;
und glaubt foo und bar wären beide jeweils Pointer. Deswegen gewöhne
ich mir an * und & immer an den Variablennamen.
Wobei es am einfachsten so ist:
char * foo;
char * bar;

Dann können solche Fehler nicht passieren und die Position des * ist eigentlich egal.

Kommentare sollten C-Style Kommentare sein: Also /* ... */, aber ich denke wir haben alle Compiler, die nicht noch aus dem kalten Krieg stammen, also sollten C++-Style //-Kommentare auch völlig ok sein.

Sonst noch was allgemeines zu beiden Sprachen: (Die Beispiel lasse ich einfach mal in C, wobei sie auch in ASM zutreffen sollten.)

Hinter Kommata und Semikolons ein Leerzeichen, davor keins, wie auch in der deutschen Sprache üblich. Vor und hinter +, -, *, /, %, |, &, ||, &&, <<, !=, !, ~, = usw immer ein Leerzeichen, außer wenn +, -, ~ der ! ein Vorzeichen sind (oder * oder & als Pointer verwendet werden.) Hinter einer öffnenden Klammer und vor einer schließenden Klammer kein Leerzeichen.
int foo = !bar;
int foo = -1;
int foo = bar * ((49 + foobar[i] + quux) % 100);
int foo = &bar;
int foo = *bar;


Nicht sofort eindeutige vorrangigkeiten von Rechenoperationen sollten wegen der besseren Lesbarkeit mit Klammern verdeutlicht werden.
Nicht so gut:
int foo = bar << foobar & mask; /* was wird zuerst ausgeführt? der shift oder die &-operation? */
Besser:
int foo = bar << (foobar & mask); /* so ist es eindeutig */

Konstanten und Makros immer in Großbuchstaben schreiben.

// C:
#define KERNEL_LOAD_ADDRESS 0x10000
; NASM-Syntax:
%define KERNEL_LOAD_ADDRESS 0x10000
; oder
KERNEL_LOAD_ADDRESS equ 0x10000


Wir müssen nicht unbedingt mit Tab arbeiten um einzurücken, aber es ist einfach sinnvoller, weil dann das Einrücken konsistent ist. (Kein Leerzeichen zählen. Außerdem ist Speicherschonend ;).) Wer sein Tab auf 8 Zeichen eingestellt hat und sich darüber aufregt, dass bereit nach 4 Tabs der Code schon über den rechten Bildschirmrand hinausragt, sollte seine Editoreinstellungen korrigieren. (Oder auf meinen Lieblingseditor Code::Blocks umsteigen. ;))

Ich hoffe mal ich hab das Wichtigste genannt. Auf jedenfall hab ich mich nicht grad kurz gefasst. ;) Die Vorschläge basieren alle auf meinem persönlichen Stil und ich halte sie somit für das non-plus-ultra :P Das muss aber nicht mit eurer Meinung übereinstimmen und deswegen denke ich, wir sollten uns schnell auf einen Stil einigen, damit dadurch nicht die eigentliche Programmierung aufgehalten wird. Ich bin auch bereit mich an eure Code-Stile anzupassen, sofern sie denn sinnvoll sind und sich alle dran halten.

Wenn wir uns geeinigt haben, ist dies sicherlich aus was, das man ins Wiki übertragen sollte.
1524
Lowlevel-Coding / A20-Gate
« am: 29. April 2005, 12:42 »
einmal liest du von 0xFFFF:0x0100 = 0x001000F0 und einmal schreibst du nach 0x0100 statt 0x00F0 ...
1525
Offtopic / Os für andere geräte
« am: 28. April 2005, 22:36 »
Zitat von: The-Programmerfish
Dann kann ich dir nicht mehr helfen ich habe leider keine PS2 sondern nur nen Gamecube, schade dass es dafür noch kein Linux gibt.

ganz sicher? ;)
1526
... und sicherheitshalber ds und es mit 0 initialisieren.
1527
OS-Design / Wie Windows arbeitet ...
« am: 22. April 2005, 16:41 »
hi mit rundll32 wirds nicht klappen. das tool kann nur spezielle dlls und da auch nur spezielle funktionen ausführen. (schnickschnack wie systemsteuerung öffnen, webseite öffnen, netzwerkumgebung öffnen etc...) IO-Funktionen werden wohl nicht dazu gehören. Außerdem ist rundll32 auch kein godlike tool. es wird genau wie jedes andere programm, dass versucht ohne berechtigung auf die io-ports (sei es nun mit oder ohne dll) gekillt werden. so wie legend es beschrieben hat, wird es rundll32 auch ergehen.
1528
Lowlevel-Coding / Meldungen ausgeben
« am: 21. April 2005, 19:01 »
afaik gibt es dafür keine int 0x10 funktion.

dafür aber 1000 selbst zusammengeschusterte funktionen, die alle in etwa so aussehen:

; input: ds:si -> null terminierter string
print_str:
lodsb                               ; nächstes zeichen nach al laden
or al, al                           ; ist al = 0?
jz short print_str_done             ; ja => jmp print_str_done
mov ah, 0x0E                      
int 0x10                            ; int 10h, function 0Eh - Teletype Output (zeichen in al ausgeben)
jmp short print_str                 ; noch ein zeichen lesen
print_str_done:
ret

scrollt automatisch
1529
Lowlevel-Coding / PUSHA
« am: 21. April 2005, 18:56 »
Zitat von: DarkThing
Diese Register werden in der Reihenfolge hier gepusht:
o AX
o CX
o DX
o BX
o SP
o BP
o SI
o DI

um genau zu sein wird der original sp gepusht. also so

Temp = SP
push AX
push CX
push DX
push BX
push Temp
push BP
push SI
push DI
1530
Lowlevel-Coding / Bootloader Problem
« am: 20. April 2005, 21:31 »
Bei 1.: Die Segmentregister müssen 0 sein, wegen dem org 0x7C00. mov ax, cs ist falsch

Zitat
2. Hier ist die Frage ob das ES Update nach dem ReadSectors okay ist:


ES=0x7C00 und DI=0x200, damit wird der kernel nach 0x0007C200 geladen was wohl nicht der sinn ist ...
1531
Lowlevel-Coding / 64bit Kernel
« am: 19. April 2005, 13:43 »
das mit dem [BITS XYZ] ist was NASM spezifisches. andere assembler haben dafür andere befehle. der NASM unterstützt kein 64 bit, der YASM schon. der hat dann auch wieder die direktive [BITS 64].

eine 64 bit cpu (genauer gesagt einen AMD64) erkennst du so: (laut AMD64 Manual)
mov eax, 0x80000000
cpuid
cmp eax, 0x80000000 ; sind 0x8000000?-CPUID-funktionen verfügbar
jbe no_long_mode
mov eax, 0x80000001
cpuid
bt edx, 29 ; long mode bit testen ...
jnc no_long_mode

; => wir haben 64 bit ...

no_long_mode:
; => wir haben kein 64 bit ...




die adress größe der instruktionen ist ohne 0x67-präfix 64 bit, mit präfix 32 bit. 16 bit gibts nicht. für die operand größe gibt es neue präfixes. dazu wurden die 1 byte großen instruktionen INC und DEC entfernt und werden nun als präfix verwendet. wo das 0x66 präfix gelandet ist weiss ich jetzt auch nicht so schnell ...
das steht sicherlich im AMD64 Manual "Volume 1: Application Programming" unter punkt 3.4 oder so ...
1532
Lowlevel-Coding / Nach dem Seitenfehler
« am: 18. April 2005, 21:07 »
die lineare adresse ist in dem register cr2.
1533
zu 1. du musst ein End-of-Interrupt-Signal an den PIC senden, wenn du mit einem IRQ-handler fertig bist. Einmal 0x20 an Port 0x20 und noch einmal 0x20 an Port 0xA0
zu 2. den keycode bekommst du, wenn du port 0x60 ausliest.
1534
Das Wiki / Blöde Frage zum CommOS
« am: 16. April 2005, 19:49 »
ich denke schon. wenn ext2 das nicht so wie FAT direkt am anfang unterstützt könnte man z.b. die stage2 (also alles ab zeile 52) auch aus dem dateisystem nachladen. so macht das z.b. GRUB.

oder man verschiebt die ext2-partition mit ein wenig nach hinten und tut den bootloader in eine eigene partition ... (auf disketten geht das natürlich nicht so)

und wenn man das nach ext2 porten will, müsste man den dateisystem abhängigen teil von dem bootloader komplett neuschreiben. ich denke mal, wenn keiner da ordentlich druck macht, wird es eh nicht so schnell einen ext2-port geben ...
1535
Das Wiki / Blöde Frage zum CommOS
« am: 16. April 2005, 19:18 »
dann gib einfach die operand size an:

push word blabla
1536
Lowlevel-Coding / PutPixel (24Bit)
« am: 15. April 2005, 23:09 »
ich verstehe die funktion nicht, aber das ist glaub ich egal.

mul ändert auch edx. edx enthält die oberen 32bit des ergebnisses. wenn das ergebnis <= 0xFFFFFFFF ist, ist edx = 0.

du solltest also edx vor dem mul zu edi addieren.
1537
Das Wiki / Community-OS
« am: 15. April 2005, 15:39 »
was ist jetzt mit einem wiki? und wie wärs mal mit einem unterforum, für das CommOS? es werden ja auf jedenfall eine menge diskussionsstoff und viele fragen zum CommOS auftauchen. sollten diese vielleicht besser recht früh von den anderen lowlevel fragen getrennt werden? (und dass auch dieser thread nicht so endlos lang wird...)
1538
Das Wiki / Ausgabe 7
« am: 15. April 2005, 15:36 »
@T-Head: hehe, du hast recht ;)
1539
Das Wiki / Ausgabe 7
« am: 15. April 2005, 14:53 »
ja würd ich auch so übersetzen. aber heisst es nicht mihi statt meam? kann sein muss aber nicht. egal ...

klingt ein bisschen komisch, ich hätte es eher so gesagt:
latinam linguam non bene dico.
1540
Das Wiki / Community-OS
« am: 15. April 2005, 08:51 »
ich würde da gerne was ergänzen:

erstmal eine puts-funktion:
// Name:      puts
// Returns:      ---
// Parameter:   Anzuzeigende Zeichenkette
// Description:   Gibt die angegebene Zeichenkette auf dem Bildschirm aus
void drvDisplay_puts(const unsigned char *s)
{
   while(*s) {
      drv_Display_putch(*s++);
   }
}


dann noch was damit, wenn der cursor unten angekommen ist, nach obengescrollt wird:

void drvDisplay_scrolld(void)
{
register int i;
unsigned short *vidmem = vgaadr;

        // zeile 2-25 um eins nach oben kopieren
for (i=0; i<scrwidth*(scrheight-1);i++)
vidmem[i]=vidmem[i+scrwidth];

        // und zeile 25 leer machen
for (i=scrwidth*(scrheight-1); i<scrwidth*scrheight;i++)
vidmem[i]=0;

if (cur_cursorY > 0)
cur_cursorY--;

return;
}

void drvDisplay_newline(void)
{
// carriage return
cur_cursorX = 0;

// line feed
cur_cursorY++;
if (cur_cursorY > 24)
kvideo_scrolld();

return;
}


müsste dann in void drvDisplay_putch(unsigned char c) hier hin:
  // New Line?
   else if (c == '\n')
   {
      drv_Display_newline();
   }

und hier
  // Evtl. nächste Zeile
   if (cur_cursorX >= scrwidth)
   {
      drv_Display_newline();
   }


basiert auf meinem "video-treiber"
Seiten: 1 ... 75 76 [77] 78 79 ... 81

Einloggen