Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
81
tyndur / LOST - Logo
« am: 30. June 2005, 16:10 »
Ihr habt echt einen an der Waffel *g*
26. April 2024, 19:32
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.
82
Lowlevel-Coding / Linken nicht möglich
« am: 30. June 2005, 10:57 »
Ja das mit dem selbstcodieren das farjumps und des 2stufigen pmode aktivierens kommt von TJ. Grund: er wusste nicht, wie man das anders machen konnte^^
83
tyndur / LOST - Logo
« am: 25. June 2005, 11:38 »
Im Moment sind glaub ich soweit alle Aufgaben verteilt, mehr Helfer würden wir kaum noch unterbringen können.
84
Lowlevel-Coding / RISC CPU
« am: 25. June 2005, 11:33 »
Wenn ein Befehl nur Register betrifft mags ja stimmen. Braucht er aber noch weitere Werte und die zähle ich eben mit dazu...
85
tyndur / Datentypen
« am: 24. June 2005, 17:13 »
richtig pointer zu schiften halte ich für sehr dämlich
86
tyndur / Datentypen
« am: 24. June 2005, 16:27 »
Zum Adressieren sollte mein eigentlich auch pointer verwenden^^ die passt der compiler ja automatisch mit an
87
Lowlevel-Coding / Einbinden von Dateien mit dem NASM-ASM
« am: 24. June 2005, 16:25 »
Google hätte da sicher auch geholfen^^ ->nasm.sourceforge.net
88
Lowlevel-Coding / RISC CPU
« am: 24. June 2005, 16:22 »
4-Byte kann garnicht stimmen
mov R0,dword
da braucht das dword schon allein 4 byte dann 1 byte fürs register ein für den opcode.
Also es sind mit sicherheit mehr als 4 byte die ein befehl brauchen wird.
15 war nur ein Bsp, weil ich glaube auf x86 ist der längste Befehl 15 Byte gross ka welcher das war
(Zu einem Befehl zählt nicht nur der Opcode selbst, sondern auch die Ziel und Quelloperanden)
mov R0,dword
da braucht das dword schon allein 4 byte dann 1 byte fürs register ein für den opcode.
Also es sind mit sicherheit mehr als 4 byte die ein befehl brauchen wird.
15 war nur ein Bsp, weil ich glaube auf x86 ist der längste Befehl 15 Byte gross ka welcher das war
(Zu einem Befehl zählt nicht nur der Opcode selbst, sondern auch die Ziel und Quelloperanden)
89
Lowlevel-Coding / RISC CPU
« am: 23. June 2005, 15:53 »
Genau deswegen sind auch kleine opcodes nicht möglich, braucht einer 15 Byte muss auch einer der eigentlich nur 1 benötigt auch auf 15 erweitert werden
91
Das Wiki / Korrekturlesen
« am: 23. June 2005, 00:03 »
Ich kann so ziemlich alles unsichtbar machen^^
92
Lowlevel-Coding / RISC CPU
« am: 22. June 2005, 23:59 »
Bei RISC haben meistens OpCodes allerdings eine feste länge um das decoding zu erleichtern, meine ich mal irgendwo gelesen zu haben. und die muss so gross sein, um die maximale auslastung aufnehmen zu können, obwohl viele so viel nicht brauchen werden->Platzverschwendung
93
Lowlevel-Coding / Interrupt Vector Table
« am: 22. June 2005, 23:53 »
Ausgabe 3 stammt von Mastermesh, mein Name steht nur da, weil die Datenbank erst viel später von mir erstellt wurde.
94
tyndur / Datentypen
« am: 22. June 2005, 23:51 »
Ich benutze persönlich die typen db dw dd wie in assembler, sieht einfach besser aus, mein Syntaxhighlighting passe ich darauf auch an^^
95
Das Wiki / Korrekturlesen
« am: 22. June 2005, 10:50 »
Muss doch nicht jeder wissen, dass das Team ein Geheim-Forum hat^^
96
Lowlevel-Coding / RISC CPU
« am: 22. June 2005, 10:49 »
Aus der Sicht des Programmierers macht es wenig unterschied ob RISC oder CISC. Zumindest für gute(!) Programmierer dürfte es keine Schwierigkeit darstellen die etwas komplexeren CISC-Befehle in einige wenige RISC-Befehle zu zerstückeln.
Ob Little oder Big-Endian ist letztlich egal, man muss nur wissen was grade vorliegt.
Das die zusätzlichen Befehle wie du sie nennst mehr Opcode produzieren ist eigentlich nicht richtig, im Gegenteil sie reduzieren eher die Menge an Bytes weil nicht mehrere Befehle Codiert werden müssen, die z.b. die selben Register bearbeiten, so gibt man das Register nur einmal an, was letztlich Grössenreduzierend wirkt (wirken kann).
Allerdings ist bei Prozessores alles relativ und nur unter bestimmten Bedingungen richtig. Wer dämlich Programmiert produziert das 3-fache an Code wie ein guter Progger, das heisst aber nicht, dass kürzerer Code schneller ist, wenn der grössere für den Prozessor besser zu parallelisieren und zu verarbeiten ist.
x86 ist keine schlechte Architektur, ist allerdings Verbesserungswürdig, durch diese elende Abwärtskompatibilität die mitgeschleift werden musste (man hatte da eigentlich kaum eine Wahl) hat sich vieles Arg verkompliziert. Man könnte einiges an Transistoren und somit Kosten für Herstellung und Betrieb sparen, würde man den RealMode einfach wegtreten, der eh nicht mehr benutzt wird. Ãhnlich die Deskriptoren die wegen dem 286er-PM ziemlich verkorkst und zerstückelt sind, sollten aufgeräumt werden->Transistorenabnahme.
Da gibt es viele Dinge die man weglassen könnte und aus Sicht der Programmierer wäre das einfach nötig.
Ob Little oder Big-Endian ist letztlich egal, man muss nur wissen was grade vorliegt.
Das die zusätzlichen Befehle wie du sie nennst mehr Opcode produzieren ist eigentlich nicht richtig, im Gegenteil sie reduzieren eher die Menge an Bytes weil nicht mehrere Befehle Codiert werden müssen, die z.b. die selben Register bearbeiten, so gibt man das Register nur einmal an, was letztlich Grössenreduzierend wirkt (wirken kann).
Allerdings ist bei Prozessores alles relativ und nur unter bestimmten Bedingungen richtig. Wer dämlich Programmiert produziert das 3-fache an Code wie ein guter Progger, das heisst aber nicht, dass kürzerer Code schneller ist, wenn der grössere für den Prozessor besser zu parallelisieren und zu verarbeiten ist.
x86 ist keine schlechte Architektur, ist allerdings Verbesserungswürdig, durch diese elende Abwärtskompatibilität die mitgeschleift werden musste (man hatte da eigentlich kaum eine Wahl) hat sich vieles Arg verkompliziert. Man könnte einiges an Transistoren und somit Kosten für Herstellung und Betrieb sparen, würde man den RealMode einfach wegtreten, der eh nicht mehr benutzt wird. Ãhnlich die Deskriptoren die wegen dem 286er-PM ziemlich verkorkst und zerstückelt sind, sollten aufgeräumt werden->Transistorenabnahme.
Da gibt es viele Dinge die man weglassen könnte und aus Sicht der Programmierer wäre das einfach nötig.
97
tyndur / Datentypen
« am: 22. June 2005, 10:33 »
Ich finde die Datentypen eh logisch, da sie nach ASM zumeist so definiert sind. Die meisten nutzen hier ja nasm und da ist word=2byte dword=4 usw.
Ich finds logischer wird anstatt short zu nutzen und kürzer qword anstelle von long long zu benutzen. Aber das ist alles Geschmackssache, irgendwie müssen ja Standards definert werden, derjenige der zuerst was festlegt bestimmt halt wos lang geht, so einfach ist das.
Ich finds logischer wird anstatt short zu nutzen und kürzer qword anstelle von long long zu benutzen. Aber das ist alles Geschmackssache, irgendwie müssen ja Standards definert werden, derjenige der zuerst was festlegt bestimmt halt wos lang geht, so einfach ist das.
98
tyndur / Datentypen
« am: 20. June 2005, 19:06 »
man kann doch die standarts trotzdem nutzen wo is das problem?
99
tyndur / GUI-Design-Vorschläge
« am: 17. June 2005, 16:02 »
Zum Glück ist bei Netzwerkkarten aber vieles relativ gleich. Bei USB-Sticks gibt es defacto nur 3 verschiedene Treiber die man bräuchte (siehe Linux).
Ich hab das Gefühle, dass viele Lost falsch verstehen
Ich hab das Gefühle, dass viele Lost falsch verstehen
100
tyndur / Doku-Team?
« am: 17. June 2005, 15:57 »
Erstmal Milestone 1 fertig stellen und dann an Milestone 2 denken...