Nachrichten

21

Offtopic / Re: Weihnachten!

« am: 25. December 2012, 01:34 »

Nun, da auch endlich Weihnachten ist (:3), wünsche auch ich allen frohe Weihnachten.

In jedem Jahr bin ich nach Weihnachten zu faul, den Weihnachtssmiley aus meiner Signatur zu nehmen. Und jedes Jahr vor Weihnachten zahlt es sich aus, weil ich mir dann nicht die Mühe machen muss ihn wieder reinzunehmen.

Also, zudem auf ein Jahr, in dem mir meine Faulheit zwei Signaturbearbeitungen erspart hat!

22

Lowlevel-Coding / Re: Über Zeiger auf nächste Variable zugreifen

« am: 17. December 2012, 00:02 »

das ablegen Auf dem stack kann man aber auch mit auto short var1 erzwingen

Ich würde behaupten, auto ist so, als würde man es weglassen (ist also die Default Storage Class). Wenn ich das benutze, erzwingt das im -O3-Fall auch gar nichts.

oder mit gcc -O0

Praktisch schon, theoretisch garantiert dir immer noch keiner, dass es wirklich draufliegt. Es ist halt undefiniert. Behaupte ich.

23

Lowlevel-Coding / Re: Über Zeiger auf nächste Variable zugreifen

« am: 16. December 2012, 21:59 »

Das kann von vielem kommen. Unter anderem daher, dass der Compiler überhaupt nicht verpflichtet ist, irgendwas auf den Stack zu legen. Er kann die Werte auch alle in Registern halten, wenn ihm danach ist. Und da du var2 überhaupt nicht benutzt, sondern nur initialisierst, ist es sogar wahrscheinlich, dass diese Variable komplett wegoptimiert wird und damit im Programm gar nicht existiert.

Desweiteren ist es dem Compiler natürlich auch freigestellt, die Variablen auf dem Stack zu ordnen, wie er das will. Ob var2 nun über var1 oder darunter liegt, ob es direkt darunter liegt oder 42 Bytes dazwischen frei sind – das kannst du nicht wirklich beeinflussen.

Sehen wir uns den objdump mal an, der bei gcc -m32 rauskommt (mit einem printf statt des prints):

Code: [Auswählen]

8048405:       66 c7 44 24 16 0a 00    mov    WORD PTR [esp+0x16],0xa
804840c:       66 c7 44 24 1e 1e 00    mov    WORD PTR [esp+0x1e],0x1e
8048413:       8d 44 24 16             lea    eax,[esp+0x16]
8048417:       83 e8 04                sub    eax,0x4
804841a:       89 44 24 18             mov    DWORD PTR [esp+0x18],eax
804841e:       8b 44 24 18             mov    eax,DWORD PTR [esp+0x18]
8048422:       8b 00                   mov    eax,DWORD PTR [eax]
8048424:       89 44 24 04             mov    DWORD PTR [esp+0x4],eax
8048428:       c7 04 24 d0 84 04 08    mov    DWORD PTR [esp],0x80484d0
804842f:       e8 9c fe ff ff          call   80482d0 <printf@plt>
Erstmal werden also beide Variablen auf den Stack gelegt, da hast du sogar Glück. var1 liegt an [esp+0x16], var2 an [esp+0x1e]. Also liegt var2 hier mal über var1, dazwischen sind 6 Bytes Platz.

Dann wird die &var1 nach eax geladen, anschließend wird 4 abgezogen („&var1 - 2“ ist dank Pointerarithmetik das gleiche wie „(short *)((uintptr_t)&var1 - 4)“; es entspricht eben „&(&var1)[-2]“). Das heißt, eax zeigt dann auf [esp+12]. Da liegt nichts, also, undefinierte Daten. An 8048422 werden diese Daten dann geladen und im nächsten Befehl für printf bereitgelegt. Bei mir liegt da übrigens 63347.

Dein Problem hier ist also erstens die Pointerarithmetik (vermutlich willst du eher „&var1 - 1“) und zweitens die generelle Tatsache, dass nur der Compiler weiß, wie der Stack tatsächlich aussieht, also was überhaupt draufliegt, und wenn es da ist, wo es ist.


Mit -O3 ist das Ergebnis übrigens noch deutlich kürzer:

Code: [Auswählen]

8048309:       8b 44 24 1a             mov    eax,DWORD PTR [esp+0x1a]
804830d:       c7 04 24 b0 84 04 08    mov    DWORD PTR [esp],0x80484b0
8048314:       89 44 24 04             mov    DWORD PTR [esp+0x4],eax
8048318:       e8 b3 ff ff ff          call   80482d0 <printf@plt>
Hier weiß gcc gleich, dass es vollkommen egal ist, welche Werte var1 und var2 annehmen, weil die eh nie von Belang sind (da du mit der Pointerarithmetik sowieso aus dem Bereich von var1 rausgehst und es wie gesagt nicht definiert ist, ob du so auf var2 landest). Damit liest er einfach den Wert von irgendwo auf dem Stack ([esp+0x1a] deutet darauf hin, dass var1 somit an [esp+0x1e] liegen würde, wenn sein Wert denn relevant wäre) und gibt den aus.

24

Offtopic / Re: Das war's - verabschieden wir uns vom 80386.

« am: 15. December 2012, 02:02 »

Hatten wir nicht schonmal eine Diskussion hier, ob man lock cmpxchg für Mutexes durch xchg ersetzen kann? Soweit ich mich erinnere, war der Stand damals, dass das geht. Und das ist dann keine Emulation, xchg ist atomar.

Mir ging es (wie kurz erwähnt) auch nicht darum, ob SMP auf 386 dadurch auch besonders schön möglich ist, sondern nur, dass es im Prinzip funktional genauso gut wird wie auf 486+ – natürlich gibt es da klitzekleine Leistungseinbußen, wenn man jedes invlpg durch ein mov eax,cr3; mov cr3,eax ersetzt und jede atomare Operation durch einen xchg-Mutex lockt, aber das ändert ja an der prinzipiellen Funktionalität nichts (wohingegen du meintest, „Eine gleichzeitige Unterstützung von ‚80386‘ und ‚SMP-kompatibel‘ in einem Betriebssystem ist nicht möglich“).

25

Offtopic / Re: Das war's - verabschieden wir uns vom 80386.

« am: 14. December 2012, 18:37 »

Hm, die Befehle braucht man für atomare Operationen? Ich dachte, xchg ist automatisch ge-LOCK-t, oder war das beim 386 noch nicht so?

Und invlpg kann man auch durch Schreiben von CR3 in sich selbst bekommen. Auch wenn das nicht schön ist.


Mit xchg kann man sich also Mutexes bauen. Und mit Mutexes wiederum kann man faktisch alle Operationen atomar machen, auch wenn sie im Prinzip nicht atomar sind – oder nicht?

Gut, es wird alles nicht sehr schön, aber die Aussage, dass man für 386er keinen SMP-kompatiblen Code schreiben kann, wage ich doch anzuzweifeln… Es sei denn, xchg war auf dem 386 nicht atomar.

26

OS-Design / Re: Was kann das OS

« am: 31. October 2012, 13:31 »

Wir sind mittlerweile ja ziemlich offtopic, aber da bin ich ja nun nicht schuld dran. Glaube ich. Auf jeden Fall kann ich da auch in diese Diskussion einsteigen:

Mag Linux eigentlich nVidia-Karten eher?

Meine Erfahrung ist, dass es heutzutage ziemlich egal ist. Bei normalen Desktopgrafikkarten, bei denen es nicht besonders auf Stromsparfunktionen ankommt (zumindest nicht in dem Maße wie auf Laptops), tun sowohl die nVidia- als auch die AMD-Closed-Source-Treiber ziemlich gut. Ich persönlich kann nur für AMD sprechen, aber für nVidia haben wir das erstens schon in diesem Thread gehört und zweitens hab ich mir auch von anderen sagen lassen, dass nVidia heute ohne große Probleme funktioniert.

Das größte Problem ist einfach meistens die Treiberinstallation (Arch bspw. hat die AMD-Treiber aus den offiziellen Repos verbannt, weil sie einfach nicht besonders gut mit dem Rest des Systems interagieren; da muss man sich also erstmal das inoffizielle Repo finden). Aber so in der Funktion sind sie nach meiner Erfahrung zumindest so leistungsfähig wie die Windowstreiber (was OpenGL angeht).

Die interessantere Frage meiner Meinung nach ist, ob nVidia oder AMD OpenGL besser unterstützt. Soweit ich informiert bin, wird das seit einigen Jahren (mindestens seit D3D10) bei beiden recht stiefmütterlich behandelt. Umso erstaunlicher, dass Valve mit OGL bessere Ergebnisse als mit D3D erzielt...

PS: RMS würde sich bei all dem vermutlich heftig den Bart zwirbeln (auch wenn er das nicht tut, das klingt aber gut; und das reimte sich, und was sich reimt, ist auch gut), aber die FOSS-Treiber... Na ja, es dauert eine Weile, bis sie tun (ich habe jetzt eine AMD (HD) 7xxx, und ich glaube nicht, dass der radeon-Treiber besonders weit ist, was 3D angeht; zumindest 2D kann er mittlerweile, glaube ich), und wenn sie tun, sind sie i. A. bei weitem nicht so schnell wie die Closed-Source-Treiber.

Frage ist: Welche Grafikkarte soll ich denn dann nehmen, damit ich Linus glücklich mache?

Wo ich gerade bei RMS war: Der würde dir bestimmt sagen, dass Torvalds das doch egal ist. Der mag auch die Closed-Source-Treiber.
Ansonsten würde ich behaupten, eine Intel-CPU und den eingebauten Grafikchip. Intel gibt die Treiber immer als OSS frei, soweit ich weiß.

Oder irgendwas ganz altes natürlich, bei dem die komplette Dokumentation offen ist.

27

Softwareentwicklung / Re: Systemnahe Programmierung mit C#

« am: 14. October 2012, 20:39 »

Sinnvoll ist das mMn immer noch nicht.
Du mähst ja auch nicht mit der Schere den Rasen.
Gehen tut's.
Sinnvoll ist es nicht.

Ich finde, es ist geradezu kaputt!

„We do what we must because we can.“ sollte Motto dieses Forums werden, denke ich.

Was bleibt also?

Asche. Alles ist vergänglich, wie Staub im Wind. Aus Sternen geboren, zu Silizium gebrannt. Zerstäubt in unendliche Weiten, mit unglaublicher Gewalt zerrissen, landet es heute unter deinem Schreibtisch in deinem Computer. Nach Milliarden von Jahren, in denen ihm so sehr zugesetzt wurde, von gewaltigem Druck zu endloser Leere – da wird es jetzt das bisschen C# für OS-Dev auch noch aushalten.

28

Lowlevel-Coding / Re: Relocatable ELF

« am: 18. September 2012, 02:59 »

Also, mein Code von Paloxena3.5 sah noch irgendwie so aus, als würde er die Program Header nutzen.

Allerdings hatte ich das anders in Erinnerung und der Code von Paloxena4 wiederum ignoriert ziemlich eindeutig die PHs, wenn es um Relocatables geht und geht stattdessen durch die SHs durch und lädt alle Sections mit ALLOC-Flag.

Demnach würde ich zu „Die PHs ignorieren und nur die Sections ansehen“ neigen, ja.

29

Offtopic / Re: Welchen Desktop benutzt ihr?

« am: 12. July 2012, 20:07 »

Ich benutze KDE (4) aus drei Gründen:

• Tradition (inb4 „aber KDE 3 wäre doch viel traditioneller!“), bei meinem ersten Linux, SuSE 9.2, stand KDE in der Auswahl zwischen KDE und Gnome einfach oben, also benutze ich seitdem KDE
• Konversation
• Konsole

Die meisten Neuerungen an KDE 4 mag ich nicht, aber ich hab auch keine großen Probleme, beispielsweise den Desktop so einzurichten, dass er wie der alte KDE-3.5-Desktop arbeitet, und weil ich denn doch lieber Ressourcen wegwerfe als mir die Mühe mache, explizit KDE 3.5 irgendwoher zu bekommen, benutze ich eben KDE 4.

PS: Ich würde bei den Gründen oben gerne sagen, dass mir einer am wichtigsten ist, aber ich kann mich nicht entscheiden: Konsole ist das von mir wohl am häufigst benutzte Programm, andererseits sind die Terminals von anderen DEs auch nicht so viel schlechter. Konversation ist geil, aber ich benutz es halt nicht ganz so oft wie Konsole (wenngleich es natürlich die ganze Zeit im Hintergrund läuft). Dennoch ist der erste Punkt der eigentliche Grund, warum ich überhaupt KDE benutze.

30

Das Wiki / Re: Tutorial Teil 7: GPF Problem

« am: 28. May 2012, 19:27 »

Juuut, wenn ich mir das Bild nochmal ansehe, dann tritt der Fehler erst auf, nachdem noch ein B geschrieben wurde. Müsste ich also weiter raten, dann ist vielleicht der Syscallhandler schuld – prinzipiell ist aber ziemlich sicher, dass du irgendwo ESP auf NULL setzt.

31

Das Wiki / Re: Tutorial Teil 7: GPF Problem

« am: 28. May 2012, 17:34 »

Wenn ich mir die Werte so ansehe, dann liest du da irgendwo die Registerinhalte von NULL. Und da ESP nur knapp über 0 ist, nehme ich mal an, das wird genau der Punkt sein. Wenn ich also raten müsste, dünkte ich, dass du im Scheduler ESP auf NULL setzt und dann beim Springen in den Task alle Register von dort gelesen werden – was natürlich nicht so doll ist.

32

Das Wiki / Re: outb in Tutorials

« am: 11. April 2012, 11:08 »

Moin,

Unter anderem sicherlich deshalb, weil es ziemlich egal ist. Man könnte behaupten, aufgrund des static inline wird der Compiler die Funktion praktisch überall direkt in den Code einfügen, so, als ob es eigentlich ein Macro wäre – praktisch würde gcc das wohl auch ohne das inline tun, weil sie so kurz ist.

Und ansonsten ist es imho meist sauberer, eine Funktion zu erstellen als ein Macro in Funktionsform.

tl;dr: So ein Macro brächte keinen echten Vorteil, daher wird eine Funktion definiert.

33

Lowlevel-Coding / Re: bInterfaceProtocol 80

« am: 31. March 2012, 18:22 »

Auf http://www.usb.org/developers/devclass_docs gibt es die wichtigsten Geräteklassen.

http://www.usb.org/developers/devclass_docs/usbmassbulk_10.pdf Ist die Spec zu Bulk-Only.

Wenn ich mir die Protokollcodes in der Massenspeicherspec so ansehe, finde ich da nur 0x00 für CBI, 0x01 für CB und 0x50 für BBB (Bulk-Only). Dementsprechend würde ich mal raten, dass 0x50 und 80 das gleiche sind, das eine nur in hexadezimal und das andere in dezimal.

34

OS-Design / Re: Monotholitisher Kernel oder Microkernel

« am: 28. March 2012, 20:42 »

Monolithischer Kernel!

35

Lowlevel-Coding / Re: memset();

« am: 25. March 2012, 03:04 »

Ich würde dir auf jeden Fall die Implementierung empfehlen, da heutige C-Compiler gut genug sind, das ziemlich stark zu optimieren (ich denke, gcc erkennt da direkt, dass das ein memset werden soll und packt seinen eigenen Code rein, weiß ich aber nicht genau).

Bei den Typen… Pfiua. Ich denke mal, es steht für „type“ oder „typedef“. Macht man zumindest häufiger, dass an Typen von typedefs ein _t rankommt, bei mir ist es also mehr oder weniger Gruppenzwang.

36

Lowlevel-Coding / Re: memset();

« am: 24. March 2012, 23:22 »

Nö, erstes müsste es in der ersten while-Schleife

Code: [Auswählen]

*pt = (value << 24) | (value << 16) | (value << 8) | value;heißen (oder ähnlich) und zweitens müsste das letzte if da noch eine Schleife sein, so ist es ziemlich falsch, aber das ist der Inhalt des ifs selbst auch. Sinnvoller wäre vielleicht

Code: [Auswählen]

uint8 *bpt = (uint8 *)pt;
while (carry--)
    *(bpt++) = value;
Prinzipiell spricht aber nichts dagegen, den ganz naiven Ansatz zu gehen:

Code: [Auswählen]

void *memset(void *ptr, uint32 value, size_t bytes)
{
    uint8 *pt = ptr;
    while (bytes--)
        *(pt++) = value;
    return ptr;
}
In der Annahme, dass du ein einigermaßen standardkonformes memset schreiben willst, das eben byteweise arbeitet und in der weiteren Annahme, dass deine uintXX-Typen den normalen uintXX_t-Typen entsprechen.

37

OS-Design / Re: C oder C++

« am: 19. March 2012, 16:37 »

Das kann man doch mit C11 bestimmt ganz toll machen, so ungefähr:

Code: [Auswählen]

#define new(X, ...) *X = _Generic((*X), point: new_point)(__VA_ARGS__)

38

OS-Design / Re: C oder C++

« am: 16. February 2012, 21:49 »

(Überladung sollte man inzwischen in C auch mit einer kräftigen Prise Präprozessormagie hinbekommen).

Hm, du meinst, mit diesem C11-Union-Parameter-Dingsda-Zeug? Würde ich gern mal in Code sehen, wenn du sowas gebastelt hast.

Sowas hab nicht ich gebaut.

Irgendwann hab ich mal in den Tiefen des Internets Code gesehen, um Funktionen mit verschiedener Parameteranzahl per CPP zu überladen – mit den _Generic-Sachen sollte das nun auch für verschiedene Parametertypen funktionieren. Aus dem Stegreif hätte ich da also nichts parat.

Und zuletzt gehört in so eine Diskussion, dass C++ längst keine Obermenge mehr von C ist. Seit C99 und jetzt zusätzlich mit C11 gibt es in C Features, die es in C++ nicht gibt (v. a. wären da für mich Arrays variabler Länge zu nennen, sind aber noch einige andere). Wenn du die aber eh nicht nutzt, dann kannst du mit C++ wohl zumindest wenig falsch machen, denke ich.

Ui, dass C++ keine Arrays variabler Länge kann, war mir gar nicht bewusst. Die benutze ich ständig.

Tjo, in gnu++ sind die auch drin, aber im ISO-C++ afaik nicht.

39

OS-Design / Re: C oder C++

« am: 16. February 2012, 02:09 »

Erstmal ist das ja sowieso eine Glaubensfrage. Wenn du C++ willst, dann solltest du den Kernel auch in C++ programmieren. So einfach ist das.

Um auch noch mehr Senf loszuwerden, könnte ich noch anbieten, dass man in C nichtsdestotrotz auch objektorientiert programmieren kann – die Frage ist dann nur, ob man das will, mit Funktionspointern für Methoden, ohne impliziten this-Pointer und ohne so aparte¹ Sachen wie Konstrukturaufrufen mit new und Destruktoraufrufen mit delete. Ansonsten kenne ich mich vermutlich nicht genug mit C++ aus, um zu wissen, was man sonst noch so haben können wöllte (Überladung sollte man inzwischen in C auch mit einer kräftigen Prise Präprozessormagie hinbekommen). Aber das nur, weil das meiner Meinung nach in jede Diskussion um C vs. C++ gehört.

Und zuletzt gehört in so eine Diskussion, dass C++ längst keine Obermenge mehr von C ist. Seit C99 und jetzt zusätzlich mit C11 gibt es in C Features, die es in C++ nicht gibt (v. a. wären da für mich Arrays variabler Länge zu nennen, sind aber noch einige andere). Wenn du die aber eh nicht nutzt, dann kannst du mit C++ wohl zumindest wenig falsch machen, denke ich.

¹ Das hat mir dict.leo.org als Übersetzung für „fancy“ angeboten, weil mir selbst kein apartes deutsches Wort dafür eingefallen ist. Ich wäre ja für die Einführung des Wortes fehnzig.

40

Lowlevel-Coding / Re: Frage zu UHCI Setup Control Transfer

« am: 29. January 2012, 18:02 »

Prinzipiell kann es richtig sein, genau müsste ich natürlich wissen, was du tun willst.

Mögliche Fehlerquellen wären:

• Fehler in den TDs: Das Depth/Breadth-Select-Bit in den Linkpointern ist nicht gesetzt, das heißt, die TDs werden nicht direkt hintereinander abgearbeitet. Willst du das so? Außerdem ist das Active Bit im Control-and-Status-Feld nicht gesetzt, demzufolge wird der UHC die TDs gar nicht ausführen.
• USB-Fehler: Ich möchte mich nicht festlegen, aber es kann sein, dass man einen Frame warten muss, nachdem man ein SETUP-Paket gesendet hat, bevor man die Antwort liest. Da ich deine Vorgehensweise nicht kenne, könnte es sein, dass das noch beachtet werden möchte.
• Probleme beim Einrichten von UHC(I) und USB: Vielleicht hast du den Legacy Support nicht deaktiviert, vielleicht hast du den Stick noch gar nicht zurückgesetzt, … Da könnte auch noch einiges nicht ganz stimmen, unabhängig davon, ob die TDs korrekt sind oder nicht.

Hilfreich wäre es zunächst vor allem, mal nachzusehen, wie viel der UHC von deinen Befehlen überhaupt mitbekommt. Dazu kannst du dir sinnvollerweise einen IRQ senden lassen, sobald ein TD abgearbeitet wurde und ansonsten einfach mal in die Statusfelder schauen und nachsehen, ob da Fehlercodes oder sonst irgendwas drinstehen. Wenn die gar nicht verändert sind, weißt du zumindest schonmal, dass es vermutlich weder am USB selbst noch an deinen Paketen liegt, sondern eher daran, dass der UHC(I) noch nicht korrekt aufgesetzt wurde, o. ä..

Außerdem wäre es gut zu wissen, in welcher Umgebung du testest. Ich habe bisher noch keinen High-Speed-Stick gefunden, der auf einem echten Computer, nachdem er an einem High-Speed-Port steckte, auf Full-Speed-Anfragen geantwortet hat. Kann an meinem Unvermögen liegen, auf jeden Fall ist das eine knifflige Sache. Im Zweifelsfall auf echter Hardware also lieber mit Low-Speed-Sachen wie Maus o. ä. rumprobieren.