Autor Thema: Einstieg in die Systemprogrammierung  (Gelesen 24721 mal)

AGGROStar1991

  • Beiträge: 29
    • Profil anzeigen
Gespeichert
« Antwort #20 am: 12. September 2010, 19:23 »
naja quellcodebeispiele u.a. auch wie man was beschleunigen kann ;)
zum beispiel zwei tipps die ich da so kenne für asm:
zum register nullen das register mit sich selber xorn, also xor eax,eax statt mov eax,0x0.
bringt ne ersparnis von einem byte und is gleich nochn bisschen schneller. gut. kennen viele.
2.( und das kennen bedeutend weniger leute) bei pentium aufwärts IMMER statt inc iwas
add iwas,1 nehmen. weil ab pentium braucht das erste einen cpu-takt, das andere nur nen halben weil die ALU bisschen optimiert wurde ;)

Für allgemein bessere Algos( ausserhalb von asm) bin ich net so der Experte, da könnten sich ja unsere Hochsprachler mal äussern ;)


mfg

Chris Code

  • Gast
Gespeichert
« Antwort #21 am: 12. September 2010, 19:37 »
das mit dem register in sich selbst naja.. ok für asm anfänger... ^^vieleicht sollten wir einfach anfangen und mal sehen ob es sich lohnt :-D

AGGROStar1991

  • Beiträge: 29
    • Profil anzeigen
Gespeichert
« Antwort #22 am: 12. September 2010, 19:42 »
ja wie gesagt, ich hätte auch noch mehr tipps und kniffe parat so is ja nui nich :D aber wenn wir nich nochn paar hochsprachler überreden können wirds doof weil lang nich jeder schreibt in asm( eig die wenigsten) wär dann bissel verschwendete arbeit.


mfg

Chris Code

  • Gast
Gespeichert
« Antwort #23 am: 12. September 2010, 19:47 »
ja wie gesagt, ich hätte auch noch mehr tipps und kniffe parat so is ja nui nich :D aber wenn wir nich nochn paar hochsprachler überreden können wirds doof weil lang nich jeder schreibt in asm( eig die wenigsten) wär dann bissel verschwendete arbeit.


mfg

Ich schreib in Hochsprachen aber mir fallen keine Tipps ein außer das grundlegende... sauberer Code und so

Ich habe mal ein Tipp für übersichtlichen Code gehört, dass man jeden Schritt eines Algorithmus in eine eigene Funktion packen sollte , was ich aber für großen MIst halte O.O

AGGROStar1991

  • Beiträge: 29
    • Profil anzeigen
Gespeichert
« Antwort #24 am: 12. September 2010, 19:50 »
deswegen mein ich ja die Hochsprachler mit Ahnung sollen sich äussern^^
ich kann zu asm usw bestimmt vieles schreiben das zumindest ich selbst interessant finde aber das was ich mich halt frage ob sichs lohnt weil wegen nachfrage ;)

Und zu deinem Tipp: zumindest in asm mach ich das in nahezu allen fällen so ;)

mfg

Chris Code

  • Gast
Gespeichert
« Antwort #25 am: 12. September 2010, 19:57 »
deswegen mein ich ja die Hochsprachler mit Ahnung sollen sich äussern^^
ich kann zu asm usw bestimmt vieles schreiben das zumindest ich selbst interessant finde aber das was ich mich halt frage ob sichs lohnt weil wegen nachfrage ;)

Und zu deinem Tipp: zumindest in asm mach ich das in nahezu allen fällen so ;)

mfg

Nach deinem letzen Satz zu urteilen tust du also jede einzelne Anweisung wie mov ax, ex in eine eigene Funktion schreiben xD... ich glaub du hast das nicht verstanden und wenn doch solltest du deine Art und Weise zu proggen nochmal überdenken xD

AGGROStar1991

  • Beiträge: 29
    • Profil anzeigen
Gespeichert
« Antwort #26 am: 12. September 2010, 20:00 »
Ok wir reden aneinander vorbei^^
aber z.B. bei nem Interrupt den ich auslösen will mit mehr als 1-2 parametern, das ist ein algorithmenschritt der augelagert wird^^

Chris Code

  • Gast
Gespeichert
« Antwort #27 am: 12. September 2010, 20:07 »
Ok wir reden aneinander vorbei^^
aber z.B. bei nem Interrupt den ich auslösen will mit mehr als 1-2 parametern, das ist ein algorithmenschritt der augelagert wird^^


Meiner ''professionellen'' meinung nach sollte eine Auslagerung nur aus folgenen Grund statt finden

Spätere Wiederverwendung oder mehrere Algos die den gleichen Teilschritt ausführen .. bestes Beispiel wäre einen String ausgeben

AGGROStar1991

  • Beiträge: 29
    • Profil anzeigen
Gespeichert
« Antwort #28 am: 12. September 2010, 20:24 »
naja du vergisst den grund warum ich das in assembler mache: damit man noch iwann mal durchsieht ;)
allerdings mach ich das dann oft nich als richtige funktion, sondern mit jumps

mfg

Chris Code

  • Gast
Gespeichert
« Antwort #29 am: 12. September 2010, 20:27 »
naja du vergisst den grund warum ich das in assembler mache: damit man noch iwann mal durchsieht ;)
allerdings mach ich das dann oft nich als richtige funktion, sondern mit jumps

mfg

tja das ist wieder definitionssache .. morgen abend hab ich viel zeit ... da fang ich mhh mit den Computergrundlagen an

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #30 am: 13. September 2010, 01:48 »
Moin,

die Sache mit "xor ax,ax" gegenüber "mov ax,0" spielt keine Rolle mehr (du hast heute an Cache, was früher RAM war). Die "inc ax" statt "add ax, 1" ist auch irrelevant geworden (ab PPro superskalar, außer Intel Atom grundsätzlich OutOfOrder-Ausführung, die Pipelinegeschichte ist wichtiger). Wenn du solche Tricks magst, dann denke lieber an loop-unrolling oder andere - höher angesiedelte - Tricks. (Aber hier noch einer: AMDs Opteron hat schnelle 64bit-Multiplikation, Intels Core2 braucht das Vielfache an Zeit.) Der Compiler kennt ohnehin wesentlich mehr Tricks als du, außerdem kennt er auch Fehler besser (ältere Opterons machen bei Branch-Prediction alles falsch, wenn ein RET kommt, daher nutzt man REP RET und der folgende Code ist wesentlich schneller).

Bei Algorithmen denke ich spontan an Quicksort, Hashtables u.ä. Da ich damit aber nur selten arbeite, müssten die Leute ran, die sowas kennen. Auch bei Schedulingfragen gibt es schnelle und langsame Algorithmen (z.B. Prozess-Scheduler O(1) von Linux, der inzwischen nicht mehr benutzt wird, oder die I/O-Scheduler fallen mir da ein). Solche Optimierungen - oder Planungen im Voraus - bringen meist wesentlich mehr, als einzelne Instruktionen zu optimieren.

Ein Cache-Miss kostet bei einem Pentium M etwa 240 Zyklen, ein L1-Cache-Hit etwa 3 Zyklen (http://www.akkadia.org/drepper/cpucache-slides.pdf), das ist wesentlich teurer. Ob die Angabe in Buszyklen ist (die sind wesentlich langsamer), weiß (und glaube) ich nicht.

Gruß,
Svenska

AGGROStar1991

  • Beiträge: 29
    • Profil anzeigen
Gespeichert
« Antwort #31 am: 13. September 2010, 07:15 »
Danke für den Tipp Svenska (:
gut das mit dem ersten war mir auch mehr oder weniger klar, aber das 2., das das obsolet is wusst ich wirklich nich^^ naja das es bei mir klappt liegt vllt an den CPUs mit denen ich arbeite(testpc pentium 200Mhz) :D
omg ich brauch wirklich nen neuen PC, fühl mich wien Dino :P
und naja das ein compiler alles so ausnutzt, wage ich manchmal ein bisschen zu bezweifeln wenn ich mir disassemblierten code angucke ;) aber im grossen und ganzen stimmts schon das die ASM-nischen wenn man kein freak is( so wie ich :P) immer kleiner werden^^


mfg

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #32 am: 13. September 2010, 11:33 »
Hallo,


aber im grossen und ganzen stimmts schon das die ASM-nischen wenn man kein freak is( so wie ich :P) immer kleiner werden^^
Diese Nischen sind schon seit Jahren quasi ausgetrocknet. Es gibt nur sehr wenige Dinge die von den Compiler-Entwicklern (und auch den CPU-Entwicklern) nicht berücksichtigt werden.

Und wie hier schon andere geschrieben haben: Ein guter Algorithmus reißt in aller Regel mehr raus als jeder Assembler-Trick!


Grüße
Erik
Reality is that which, when you stop believing in it, doesn't go away.

Programm Noob

  • Gast
Gespeichert
« Antwort #33 am: 13. September 2010, 11:53 »
Man kann aber den besten Algorithmus noch mit solchen Asm Tricks verbessern ;)

Programm Noob

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #34 am: 13. September 2010, 16:07 »
Ist aber nicht realistisch.

Entweder du opferst xy Stunden für ASM-Ticks oder für ein sauberes, schnelles Design. Mal abgesehen handelt es sich hier um Freizeitbeschäftigungen, richtig? Da ist beides ohnehin nicht drin.

Sag dem Compiler lieber, dass du speziell für die CPU erzeugten Code möchtest, lies dich ein bisschen ein (z.B. hier) und erzeuge les- & wartbaren Code. Und kenne deinen Compiler. :-)

Gelegentlich ist es sinnvoll, dem Compiler ein paar Hilfen zu geben, wenn er bestimmte Sachen nicht automatisch (weg)optimiert. Zumindest GCC und LLVM sind da aber besser als jeder Programmierer. Abgesehen davon hat niemand was davon, wenn du per Hand auf einen Pentium 180 Stepping 3 optimierst - den hat eh keiner.

Aggro: Nutzt du eigentlich auch MMX oder eher nicht? Weil der Compiler kann das auch nutzen, wenn du ihm davon erzählst... und MMX ist schneller als kein MMX.

Schlusswort: Es gibt einen Grund für handoptimierten ASM-Code: Videocodecs. Riesige Datenmengen, unglaubliche Wiederholungen des gleichen Codes, komplizierte Operationen. Da gibt's ein paar Blogposts von den x264- und ffmpeg-Leuten, die da ein paar Sachen ausplaudern. Das trifft aber nicht wirklich auf OS-Dev zu.

Gruß,
Svenska,
und tschuldigung für die langen Posts von mir.

edit: aktuellere Fassung verlinkt, von 2008 statt von 2007... also auch nicht ultramodern, aber gut.

AGGROStar1991

  • Beiträge: 29
    • Profil anzeigen
Gespeichert
« Antwort #35 am: 13. September 2010, 17:16 »
ja ich nutz mmx aufm testpc, auf dem andern wo ich glatt nen amd 2400 xp+ hab sogar neben mmx SSE und 3dNOW. aber naja das es solche diskus war ich vorbeteitet^^
Ich bin halt ASM progger und das weils halt einfach meine Lieblingssprache(und "Muttersprache", bin nebenbei virenschreiber usw und entwickle für DOS) ist, auch wenn ihr jetzt alle sagt es macht geschwindigkeitsmässig keinen sinn^^ tdem seh ich da halt wesentliche vorteile ;)
aber jedem das seine^^
Nochn kleiner Nachtrag: schliesst denn ASM ein sauberes, schnelles Design aus???


mfg

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #36 am: 13. September 2010, 17:38 »
Hallo,


schliesst denn ASM ein sauberes, schnelles Design aus???
Nein, natürlich nicht. Aber sowas wird durch Assembler eben nicht gerade erleichtert, der Programmierer braucht noch mehr Selbstdisziplin als eh schon. Wenn Du das kannst ist das toll aber viele können es leider nicht. Es gibt etliche Leute die bekommen noch nicht mal in einer Hochsprache ein sauberes SW-Design hin, solchen Leuten kann man von Assembler nur dringend abraten. Ich selbst programmiere auch sehr gerne in Assembler, einfach weil es mir Spaß macht und ich es mag mit der CPU auf Tuchfühlung zu gehen, aber für größere Programme oder komplexe Algorithmen bevorzuge ich dann doch lieber C++ und überlasse dem Compiler die Drecksarbeit. Man hat als Programmierer schon genug damit zu tun seine Ideen und Konzepte dem Computer begreiflich zu machen, da kann ich persönlich gut drauf verzichten auch noch ständig an die Wünsche und Vorlieben der CPU denken zu müssen. Ich denke mal man bekommt ein bestimmtes Problem mit weniger Zeitaufwand programmiert wenn man nicht Assembler benutzt. Assembler verleitet dazu sich in unnützem Kleinkram zu verlieren (wie z.B. Optimierungen, die der Compiler sicher deutlich besser erledigen kann).


Grüße
Erik
Reality is that which, when you stop believing in it, doesn't go away.

Programm Noob

  • Gast
Gespeichert
« Antwort #37 am: 14. September 2010, 13:15 »
Wann ersvheint denn das erste Magazin?

Programm Noob

Chris Code

  • Gast
Gespeichert
« Antwort #38 am: 14. September 2010, 16:00 »
Wann ersvheint denn das erste Magazin?

Programm Noob

ich hoffe doch mal am wochenende ist es fertig.. das konzept gefällt mir noch nicht so ganz. ich bin nicht ganz sicher ob ich so grundlagen wie Zahlensystemumwandlung reinnehmen soll da sie ja eigentlich schon erklärt werden... ich wollte es halt nur in ein extra wiki machen als einstieg was man wissen sollte für die OS Entwicklung..
was auf jedenfall reinkommt ist wie der pc arbeitet.. von Peripherie über den aufbau eines rechners, cpu und was passiert wenn der rechner gestartet wird..
das ist alles was ins erste magazin soll.. fällt jemanden noch was ein?

DerHartmut

  • Beiträge: 236
    • Profil anzeigen
    • Mein Blog
Gespeichert
« Antwort #39 am: 14. September 2010, 16:30 »
Ich persönlich bin ja ein wenig skeptisch, was dein Magazin angeht. Denn vom Aufbau her würde ich behaupten ist es fast wie das alte Lowlevel-Magazin, und das schlummert nun auch in den Urweiten des Wiki ganz versteckt dahin.

Außerdem ist ein Magazin erhebliche Arbeit. Diese Arbeit könntest du bei gleichem Effekt minimieren, in dem du einfach Beiträge im Wiki erstellst bzw. ausarbeitest. Du könntest ja auch eine Tutorialreihe im Wiki machen "Assembler für Anfänger" oder "C für (Programm_)Noobs)" (;-)), welche auch für Leihen verständlich ist. Solche zwei Anleitungen wären vor allem dann für die gut, die gerade ein bissschen C gelernt haben und schon ein Betriebssystem schreiben wollen.

Natürlich sollst du, wenn du unbedingt willst, dein Magazin schreiben, aber denk mal über meine Vorschläge nach :-)
$_="krJhruaesrltre c a cnp,ohet";$_.=$1,print$2while s/(..)(.)//;
Nutze die Macht, nutze Perl ;-)

 

Einloggen