Lowlevel
OffZone => Offtopic => Thema gestartet von: unsknown spammer am 28. December 2006, 19:27
-
http://c-worker.ch/humor/cppquatsch.php
Ist C und Unix nur ein Joke? :wink:
-
http://c-worker.ch/humor/cppquatsch.php
Ist C und Unix nur ein Joke? :wink:
Der ist echt gut. Deswegen progge ich ja in Assembler.
bitmaster
-
Dieser Artikel geistert ziemlich häufig im Netz.
Naja, Fakt ist, dass die größten "Stärken" von C gleichzeitig die größten Schwächen sind - halt je nach Sichtweise und nicht wegzuerklären.
Eigentlich ist C eine der ungeeignetsten Sprachen für Betriebssysteme - und trotzdem wird es seit Ewigkeiten genutzt.
Interessant finde ich dazu die Diskussionsseite zum Wikipedia-Artikel "C (Programmiersprache)". Dort wird dazu auch Stellung genommen - und man merkt genau, wer dafür und wer dagegen ist.
Ich halte mich an Bitmaster und schreibe Assembler.
Gruß,
Svenska
-
Daß nicht jeder C mag, kann ich durchaus nachvollziehen - für einen Kernel ist es zwar meines Erachtens durchaus brauchbar, aber für alles, was auf einer abstrakteren Ebene angesiedelt ist, tatsächlich nicht das Optimum, um es mal vorsichtig auszudrücken. Meine Kritikpunkte sind also Kompiliziertheit, Fehleranfälligkeit, Wartbarkeit, usw.
Was ich aber nicht verstehen kann ist, wieso man dann auf Assembler ausweicht. Die für mich einzig logische Ausweichrichtung wäre auf höhere Sprachen, wenn man sich an diese Kritikpunkte hält.
Was also sind eure Kritikpunkte an C? Die müssen ja wohl genau in die umgekehrte Richtung gehen wie meine, denn aus meinen kann ich beim besten Willen nicht folgern, daß Assembler die bessere Wahl wäre.
-
Ich halte mich an Bitmaster und schreibe Assembler.
/me too
@taljeth
Mir gefällt Assembler einfach, weil ich selber alles in der Hand haben kann.
Vor allem hilft mir Assemblerprogrammierung, systeminterne Dinge besser zu verstehen, z.b. wie ein Prozessor funktioniert, oder wie WinSockets funktionieren.
Dadurch, das ich in W32 ASM Sockets benutze, muss ich meine HTTP Header etc. selber zusammenbasteln, was wiederum dafür sorgt, dass ich weis, wie solcher aufgebaut ist.
Gäbe genügend solcher Beispiele.
Was ich an C nicht mag:
Ich finde, C Syntax ist unübersichtlicher als ASM Syntax.
Aber das wird wohl im Auge des Betrachters liegen.
Außerdem hab ich was gegen Datentypen, bzw. die strenge Kontrole derjenigen.
In ASM hab ich ein byte7word (16Bit) und in 32Bit ASM eben ein DoubleWord.
Da isses egal, ob der Rückgabewert einer Funktion eine Zahl oder ein Pointer oder ein Handle ist.
Wird alles in einem DoubleWord gespeichert, fertig aus, Amen.
Was für C (und jede andere höhere Sprache) spricht:
Grob über den Daumen gepeilt würd ich sagen, dass ein in C geschriebenes Prog nur 1/4 soviel quellcode hat wie ein in ASM geschriebenes, gleichwertiges Prog.
-
@taljeth: Na ganz einfach, warum soll ich eine hochkomplizierte Programmiersprache wie C nehmen, wenn es mit Assembler noch komplizierter geht? Außerdem versauen meiner Meinung nach alle Hochsprachen die Ausgabe.
bitmaster
-
Vor allem hilft mir Assemblerprogrammierung, systeminterne Dinge besser zu verstehen, z.b. wie ein Prozessor funktioniert, oder wie WinSockets funktionieren.
Prozessor verstehen - meinetwegen. Aber Winsocks? Das ist doch selbst in C geschrieben, ich bezweifle, daß man das besser versteht, wenn man es mit Assembler anspricht. Der einzige "Zusatznutzen" ist vielleicht, daß man die C-Aufrufkonventionen kennenlernen darf...
Dadurch, das ich in W32 ASM Sockets benutze, muss ich meine HTTP Header etc. selber zusammenbasteln, was wiederum dafür sorgt, dass ich weis, wie solcher aufgebaut ist.
Das ist vielleicht ein Argument, nicht unbedingt PHP zu benutzen, wenn man genau wissen will, wie es funktioniert, aber ansonsten schlägt es ziemlich genau ins Leere.
Ich finde, C Syntax ist unübersichtlicher als ASM Syntax.
Hm, ja... Ich persönlich finde ja Ausdrücke wie "(a + b) *c" schon übersichtlicher (oder sagen wir vielleicht lieber: aus dem richtigen Leben gewohnter) als ein paar Zeilen Assembler für dasselbe.
Außerdem hab ich was gegen Datentypen, bzw. die strenge Kontrole derjenigen.
Ist mir nicht direkt einsichtig. Kontrolle durch den Compiler bedeutet schonmal einige vermiedene Fehler. Einen Nachteil sehe ich dagegen nicht.
-
Das was ich dazu sage: Jeder das seine.
bitmaster
-
Genau...ich bin auch für Assembler!!
Es stimmt das ein C-Prog vielleicht nur einen 4tel Quellcode braucht...Hat man aber beides auskompiliert, ist der Assmbler nur noch ein 4tel so gross wie C....
Und dass Asm kompliziert ist kann man wirklich nicht sagen...Es ist auf das wesentliche konzentriert und deshalb einfach einfacher....
Und stimmt sich immer mit Datentypen usw. herumzuschlagen ist gerad für OS-Dev sehr mühsam...
Darum progge ich das tiefe an meinem OS in Asm...und wenn es dann irgendwann geht mit einer höheren Sprache...(wenns geht Java) weiter...
-
http://c-worker.ch/humor/cppquatsch.php
Ist C und Unix nur ein Joke? :wink:
Der ist echt gut. Deswegen progge ich ja in Assembler.
bitmaster
ganz meine meinung, aber wie du schon sagtest, jedem das seine
-
Also jetzt mal im Ernst Leute. Ich schreibe zwar gerne selber Asm, aber nur aus Spaß und der faszination wie klein der erzeugte Binärcode sein kann. Als richtige Programmiersprache taugt das eigendlich nicht mehr.
Ich kann mich daran erinnern, dass es jemanden in diesem oder einem anderem Forum gab, der Hardcode geschrieben hat (also mit nem Hexeditor alle Befehle eingetippt... -_- ). Trozdem war sich diese Person bewusst , dass das nicht sehr effektiv ist! Aber hier wird einem nun gesagt das schwache Typisierung von Variablen stört...
-
C-- :wink:
-
Als richtige Programmiersprache taugt das eigendlich nicht mehr.
Mach dich mir nicht zum Feint. ;-) ASM ist die einzig vernünftige Programmiersprache. Im Gegensatz zu den Hochsprachen ist das Ergebnis der Assemblierung/Kombilierung nicht verseucht. Ich progge alles in ASM (außer Web zeug), Programme und mein komplettes OS. Also sag nicht das ASM dafür nichts taugt. Es liegt nur dran wie gut der Progger ist. ätsch
bitmaster
-
Jop...wenn halt der Geist eines Proggers zu klein ist und man alles in Klassen und Subklassen und Methoden und Submethoden einteilen muss...na bidde....
-
Aber Winsocks? Das ist doch selbst in C geschrieben, ich bezweifle, daß man das besser versteht, wenn man es mit Assembler anspricht.
Jo, warn schlechtes Beispiel, zumal man in C und in ASM die WinAPI dafür nutzen muss, demzufolge war mein Argument ziemlich daneben gegriffen :-D
Hm, ja... Ich persönlich finde ja Ausdrücke wie "(a + b) *c" schon übersichtlicher (oder sagen wir vielleicht lieber: aus dem richtigen Leben gewohnter) als ein paar Zeilen Assembler für dasselbe.
ich mein den gesamten Syntax an sich, aber wie gesagt, das ist Ansichtssache.
Ist mir nicht direkt einsichtig. Kontrolle durch den Compiler bedeutet schonmal einige vermiedene Fehler. Einen Nachteil sehe ich dagegen nicht.
Naja, wenn ich erstmal ne Funktion suchen muss, um nen Bool in nen Integer umzuwandeln, oder z.b. in Delphi nen TString in nen String Datentyp (sind nur Beispiele), ist es mir lieber, wenn ich ein DWord habe, und sonst nix :-)
Ich bins von PHP schon gewöhnt, nur einen Datentyp zu haben, alles andere finde ich nich gerade berauschend :-P
Ich kann mich daran erinnern, dass es jemanden in diesem oder einem anderem Forum gab, der Hardcode geschrieben hat (also mit nem Hexeditor alle Befehle eingetippt... -_- ).
lol, das hab ich auch mal gemacht; da wirste verrückt mit der zeit :evil:
ich glaub, ich hab nen Tag gebraucht für ein Prog, das den ASCII Code einer Taste ausgibt.
aber ne Erfahrung wars wert :-)
-
Hm, ja... Ich persönlich finde ja Ausdrücke wie "(a + b) *c" schon übersichtlicher (oder sagen wir vielleicht lieber: aus dem richtigen Leben gewohnter) als ein paar Zeilen Assembler für dasselbe.
ich mein den gesamten Syntax an sich, aber wie gesagt, das ist Ansichtssache.
Was hat Assembler groß an Syntax, was übersichtlich sein könnte? Die Syntax vom Assembler ist recht primitiv, würde ich sagen. Primitiv heißt aber nicht unbedingt übersichtlich.
Naja, wenn ich erstmal ne Funktion suchen muss, um nen Bool in nen Integer umzuwandeln
Erklär mir bitte mal, welchen Sinn es machen soll, einen Wahrheitswert als Zahl zu behandeln. Wahr ist nicht 1 und nicht 42 und nicht 1337, sondern einfach wahr. Umwandlung in einen Integer ist sinnlos. Wenn nicht, war Boolean nicht der richtige Datentyp für die Variable.
Abgesehen davon: In C würde man (int) x schreiben, in Pascal integer(x). Das sind keine Funktionen, sondern billige Typecasts. Ist das wirklich kompliziert?
Ich bins von PHP schon gewöhnt, nur einen Datentyp zu haben, alles andere finde ich nich gerade berauschend :-P
Offensichtlich kannst du nicht besonders gut PHP, sonst wüßtest du, daß PHP Datentypen hat. Und wenn man das nicht beachtet, kann man auf die Schnauze fliegen. (z.B. Größer-/Kleiner-Vergleich auf Strings und auf Zahlen macht einen Unterschied!)
-
Im Gegensatz zu den Hochsprachen ist das Ergebnis der Assemblierung/Kombilierung nicht verseucht.
Und das würd ich dann doch gern erklärt haben. Mit was denn verseucht?
-
Erklär mir bitte mal, welchen Sinn es machen soll, einen Wahrheitswert als Zahl zu behandeln.
Wie gesagt, war nurn beispiel.
Mir ist die Funktion von Typecasts durchaus bewusst (bzw. ich weis, dass es sie gibt, benutzt habe ich sie mangels C(++) projekte nie), allerdings war meine Aussage nur, dass ich sowas in ASM nicht brauche.
Das, und nichts anderes, habe ich gesagt.
Wie einfach und simple TC's zu bedienen sind, ist mir relativ egal, in ASM brauche ich das nicht.
Offensichtlich kannst du nicht besonders gut PHP, sonst wüßtest du, daß PHP Datentypen hat. Und wenn man das nicht beachtet, kann man auf die Schnauze fliegen. (z.B. Größer-/Kleiner-Vergleich auf Strings und auf Zahlen macht einen Unterschied!)
Offensichtlich habe ich dann meine PHP projekte ohne große PHP Kentnisse geschrieben :-o
Damit meinte ich eher, dass es egal ist, das ich schreibe:
$a=5;
echo $a;
$a="abc";
echo $a;
oder:
$a="5";
$b=7;
$c=$a+$b;
echo $c;
Und das mach mal in C (ohne Typecast natürlich).
Ich bin zwar der C 'schen Sprache nicht mächtig, bin mir aber ziemlich sicher, dass das nicht geht...
Dass ich in PHP auf einen Buchstaben keinen Integer addieren kann, weis ich auch...
(z.B. Größer-/Kleiner-Vergleich auf Strings und auf Zahlen macht einen Unterschied!)
Wie? Willst du Buchstaben(-strings) mit zahlen vergleichen?
btw
Primitiv heißt aber auch nicht zwingend unübersichtlich... :wink:
-
bin mir aber ziemlich sicher, dass das nicht geht
Geht das denn in ASM? ;-)
bitmaster
-
$a="5";
$b=7;
$c=$a+$b;
echo $c;
a='5';
b=7;
c=a+b;
cout << c << endl;
Edit: Eigentlich wollte ich aber garnicht so eine Diskussion lostreten! :-(
-
bin mir aber ziemlich sicher, dass das nicht geht
Geht das denn in ASM? ;-)
bitmaster
Nicht ganz genauso, aber das hab ich nie behauptet :wink:
Weil wäre ASM = PHP würd ich nicht mit MOV Werte in Variablen kopieren sondern mit einem IstGleich Zeichen :-)
mov ax, "1"
add ax, 02h
--> Ergebnis="3"
:-D
geht solange das ergebnis nur eine Ziffer hat.
@us
Oh, das geht?
Sieh an, wusst ich nicht :-)
Dann muss ich wohl meine Behauptung zurückziehen :-P
Edit: Eigentlich wollte ich aber garnicht so eine Diskussion lostreten! sad
Ach, schadet doch nix.
So hat man wenigstens mal wieder ne ordentliche Diskussionsrunde :evil:
-
a='5';
b=7;
c=a+b;
cout << c << endl;
Sollte 60 ausgeben. (0x35 + 7)
Mit Assembler muss ich mich mit der Prozessorarchitektur auseinandersetzen. Das muss ich mit C nicht. Daher ist C oft sinnvoller als Assembler. Für Sachen, die keinen direkten Speicher/Registerzugriff erfordern, halte ich persöhnlich Bytecode Sprachen wie Java oder .NET am besten, da sie Binärkompatibel auf allen Platformen sind und sich durch die VM kontrolieren lassen.
-
@bitmaster: Ich hätt gern eine Antwort auf meine Frage :wink: Ich finde es nämlich nicht in Ordnung, dass du irgendwelche Behauptungen über C Compiler aufstellst.
In C++ könnte man sich zwei klassen schreiben und den + operator überschreiben, dann kann man auch so einen Blödsinn machen und folgendes:
char a = '0';
a += 9;
cout << a << endl;
gibt wirklich 9 aus :wink:
-
@bluecode
Funzt aber auch nur solange, wie das Ergebnis nur eine Ziffer hat, oder?
Oder wandelt der Compiller die Char variable erst in nen Integer, und dann wieder zu nem Char?
-
@Biehler Productions2: Das bezweifle ich, sonst wäre C/C++ unlogischer als ich dachte.
@bluecode: Schau dir compilierten Code an, dann weißt du was ich meine (ja auch mit allen möglichen zeugs rausgenommen).
bitmaster
-
Ja, funktioniert nur mit einer Ziffer, das funktioniert halt deshalb, weil der Ascii Code von 9 um 9 höher ist als der von 0 und man das ganze als Char ausgibt und nicht als Integer.
-
@bluecode: Schau dir compilierten Code an, dann weißt du was ich meine (ja auch mit allen möglichen zeugs rausgenommen).
Ich bin mir sicher, daß bluecode schon genug kompilierten Code angeschaut hat, genauso wie ich. Du sollst einfach nur mal beschreiben, was du genau damit meinst, statt auszuweichen.
-
@taljeth: Wenn das so ist, wieso soll ich es euch dann noch erklären? Ihr wisst doch dann was ich meine. Oder wieso ist ein C Kernel mit den selben Funktionen wie ein ASM Kernel so viel größer?
bitmaster
-
Ich persönlich habe nichts gegen C, C++, Assembler, Delphi usw.
Es kommt immer darauf an, was man genau tun möchte.
Allerdings gibt es in C (und damit in von C abgeleiteten Sprachen) Probleme, die man nicht hätte, wenn man die Sprache mal definiert hätte. So muss man immer das Verhalten des Compilers berücksichtigen. Linux 0.99 lässt sich nicht mit einem modernen gcc übersetzen - Linux 2.4 nicht mit dem ACK (Amsterdam Compiler Kit, dem Compiler von Minix - unter dem wurde Linux 0.99 entwickelt!) Soetwas darf nicht passieren. Darum rate ich auch gründsätzlich von C ab. Dann die Datentypen - ein Byte ist nicht zwingend 8 Bit, ein Integer nicht zwingend 16 Bit und ein Long nicht zwingend 32 Bit. Wäre das so, hätte man - egal, auf welcher Architektur - immer konstante Variablengrößen. Und wenn ein Byte 7 Bit hätte - na und?
Aber so gibt es #ifdef und #define, was die schöne "Architektur-Unabhängigkeit" ganz gezielt unterläuft.
Dafür kann man mit C vieles wieder rausschlagen und (je nach Compiler) ist kompilierter Code teilweise schneller/besser als handgeschriebener - denn schließlich kennt ein gcc mehr Prozessorbefehle als wir hier und kann darum auch besser optimieren. Dazu ist im Compiler meist auch das spezifische Verhalten der Prozessoren selbst eingebastelt.
Aber wem C passt, der soll es nutzen. Gleiches gilt für VB und Delphi - ich benutze beide. Delphi in der Schule, inzwischen auch zuhause; vorher war es VB. Der Grund ist einfach - zwei Syntaxen und zwei Probleme. Den Wechsel kriege ich nicht so leicht hin. Mit Assembler würde ich keine Windows-Programme schreiben wollen (in C auch nicht, aber das kann ich ohnehin nicht) - in Delphi kein maschinennahen Code. Der Zweck ist alles.
Gruß,
Svenska
-
@Svenska: Deine Aussage im 2. Absatz stimme ich zu. Aber das mit Compiler besser als Assember progger stimmt nicht. Wenn man natürlich keie Ahnung hat und nach jedem Befehl ein mov rcx,0FFFFh loop $ schreibt (übertreib) dann schon. Aber ansonsten ist der ASM wirklich bei weitem besser. Schau dir mal die aktuellen Werte für GCC an (oder noch schlimmer Borland c++). Das spricht ganz klar für Assembler.
bitmaster
-
@taljeth: Wenn das so ist, wieso soll ich es euch dann noch erklären? Ihr wisst doch dann was ich meine. Oder wieso ist ein C Kernel mit den selben Funktionen wie ein ASM Kernel so viel größer?
Nein, ich weiß es nicht. Und der LOST-Kernel hat momentan 22K (davon macht der Code etea 10K aus), das halte ich für in Ordnung. Bei einer derartigen Dateigröße noch weiter zu optimieren, lohnt sich eh nicht. Zumal mal üblicherweise sowieso eher auf Geschwindigkeit statt auf Dateigröße optimieren möchte...
Mit Assembler würde ich keine Windows-Programme schreiben wollen (in C auch nicht, aber das kann ich ohnehin nicht) - in Delphi kein maschinennahen Code. Der Zweck ist alles.
Pascal ist für maschinennahen Code genauso geeignet wie C. Nur nicht so verbreitet.
-
Yay! Und jetzt sitzen wir in einer grossen Firma und wollen ein OS programmieren. Was? Du kannst kein C? Auch kein C++? Wtf. Vergiss es - verschwinde!
Im Ernst..in Assembler zu programmieren ist nicht nur ineffizient, fehleranfaellig, unproduktiv, nicht nachhaltig, etc., sondern auch ausserordentlich gut fuer die Portierbarkeit. Wirklich gut. Vor allem, wenn man verschiedene Microprozessoren hat und die gleiche Applikation drauf laufen lassen will. Viel Spass.
*Kopf schuettel*
Wie heissts so schoen: Wenn man keine Ahnung hat...
-
Im Ernst..in Assembler zu programmieren ist nicht nur ineffizient, fehleranfaellig, unproduktiv, nicht nachhaltig, etc., sondern auch ausserordentlich gut fuer die Portierbarkeit. Wirklich gut. Vor allem, wenn man verschiedene Microprozessoren hat und die gleiche Applikation drauf laufen lassen will. Viel Spass.
Das hat hier auch niemand behauptet, zumindest habs ich nicht mehr im Kopf.
Klar ists fehleranfälliger, wenn ich mich selber um den Stack kümmern muss, wenn ich selber nach nem Funktionsaufruf die werte zurückholen darf, wenn ich vor ner Schleife nen Wert pushe und aus versehen den in der Schleife wieder poppe.
Wenn ich dann Stunden damit verbringe den fehler zu suchen und ihn nicht finde, weil ich jedesmal irgendwo ein "POP XY" übersehe.
Gelobt sei der Macro Assembler von Microsoft.
Den INVOKE Funktionsaufruf möcht ich in der W32 programmierung nicht mehr missen. :evil:
(http://www.world-of-smilies.com/smiliesgenerator/smilie_23_Sag+JA+zu+Assembler_8_000000_000000_fffffe.png) (http://www.world-of-smilies.com)
-
Yay! Und jetzt sitzen wir in einer grossen Firma und wollen ein OS programmieren. Was? Du kannst kein C? Auch kein C++? Wtf. Vergiss es - verschwinde!
Ich will in keiner Firma die in C Programmiert weil sie ASM nicht beherrscht.
Im Ernst..in Assembler zu programmieren ist nicht nur ineffizient, fehleranfaellig, unproduktiv, nicht nachhaltig, etc., sondern auch ausserordentlich gut fuer die Portierbarkeit. Wirklich gut. Vor allem, wenn man verschiedene Microprozessoren hat und die gleiche Applikation drauf laufen lassen will. Viel Spass.
Dann liegt es aber nur an den programmieren alleine. Wenn sie zu schlecht für ASM sind, na bitte. Portierbar? Seit dem Apple auf Intel umgestiegen ist, ist das kein Thema mehr für mich. Und wenn ihr jetzt mit anderen sachen wie Mobile-Phones kommt: Wenn mein OS gut genug ist sorg ich dafür das Intel/AMD was mit mir in der Richtung machen bzw. die sorgen für mich.
Wie heissts so schoen: Wenn man keine Ahnung hat...
Dann tu es auch.
Den INVOKE Funktionsaufruf möcht ich in der W32 programmierung nicht mehr missen.
Schau dir OS-64s APIs an!!!
Z.Z. gibt es kein vernünftiges großes OS. Linux/Unix Architektur ist der größte Rummel und Windows ist wie ein löchriger Käse (und Mac OS ist zu instabil). Bis ich mit meinem OS komme!!! Ja das ist mein Ernst und ich bin davon überzeugt.
bitmaster
-
Den INVOKE Funktionsaufruf möcht ich in der W32 programmierung nicht mehr missen.
Schau dir OS-64s APIs an!!!
Was hab ich davon? *dumm-frag* :oops:
-
Den INVOKE Funktionsaufruf möcht ich in der W32 programmierung nicht mehr missen.
Schau dir OS-64s APIs an!!!
Was hab ich davon? *dumm-frag* :oops:
Damit wollte ich nur demonstrieren das schlechte APIs nichts mit ASM zu tun haben. Meine lassen sich ganz einfach mit ASM ansprechen. Oder was wolltest du sagen mit den Win APIs?
bitmaster
-
Den INVOKE Funktionsaufruf möcht ich in der W32 programmierung nicht mehr missen.
Schau dir OS-64s APIs an!!!
Was hab ich davon? *dumm-frag* :oops:
Damit wollte ich nur demonstrieren das schlechte APIs nichts mit ASM zu tun haben. Meine lassen sich ganz einfach mit ASM ansprechen. Oder was wolltest du sagen mit den Win APIs?
bitmaster
Nö, ich meinte es im Bezug darauf, dass jemand schrieb, Programmierung in ASM sei generell fehleranfälliger.
Dem habe ich zugestimmt und habe als Bemerkung angeführt, dass der Macro Assembler von MS dem Programmierer einiges abnimmt, z.b. mit der INVOKE Direktive(?).
INVOKE sparrt dem Programmierer das Pushen und Poppen von Parametern.
z.b.: INVOKE DoSomething, Parameter1
Das verwandelt der Assembler automatisch um in:
PUSH Parameter1
CALL DoSomething
POP parameter1
Dadurch vermeiden sich fehler, die sich ergeben, wenn man z.b. die Parameter in der falschen Reihenfolge pushen würde oder nach dem CALL vergessen würde, den stackPointer wieder richtig hinzubiegen.
-
@Biehler Productions2: Jo, und darauf sagte ich: Schau dir meine API-Funktionen an.
bitmaster
-
Hab ich gemacht. Sehe keinen logischen Aufbau dahinter. Zur Parameterübergabe werden einfach irgendwelche Register benutzt, die dir bei der Entwicklung wohl gerade geschickt waren. Wieso soll sich ein Anwendungsentwickler merken müssen, was für den Kernelprogrammierer gerade geschickt war? An der Stelle würde etwas mehr Einheitlichkeit guttun, glaube ich.
-
Wenn man natürlich keie Ahnung hat und nach jedem Befehl ein mov rcx,0FFFFh loop $ schreibt (übertreib) dann schon. Aber ansonsten ist der ASM wirklich bei weitem besser.
Erstens programmier nichtmal ich so blöd und zweitens will ich auch schnell zu Ergebnissen kommen. Programmierer in der heutigen Zeit stehen nunmal unter enormem Zeitdruck - und da ist es schon praktisch, wenn man "Klick, Klick, Klick" und die einzelnen grafischen Elemente sind fertig. Dazu auch das Verhalten in bestimmten Situationen (wie war das mit dem Rad?) und fehlerfrei sollte das dann auch sein. Dann kann ich auch anfangen zu programmieren und brauch mich um den "Urschleim" nicht mehr kümmern.
Was interessiert heute noch Geschwindigkeit? Optimierung? Dann nimmt man eben 200 MHz mehr und die Sache ist erledigt. Wozu Gehirnschmalz investieren?
ASM ist besser, da stimme ich dir zu - aber es ist nicht praktikabel.
Mit Assembler würde ich keine Windows-Programme schreiben wollen (in C auch nicht, aber das kann ich ohnehin nicht) - in Delphi kein maschinennahen Code. Der Zweck ist alles.
Pascal ist für maschinennahen Code genauso geeignet wie C. Nur nicht so verbreitet.
Meinetwegen, Delphi ist dafür jedoch total ungeeignet. Unter Linux ist es inzwischen durch Kylix wenigstens meistens Quelltext-kompatibel.
Im Ernst..in Assembler zu programmieren ist nicht nur ineffizient, fehleranfaellig, unproduktiv, nicht nachhaltig, etc., sondern auch ausserordentlich gut fuer die Portierbarkeit. Wirklich gut. Vor allem, wenn man verschiedene Microprozessoren hat und die gleiche Applikation drauf laufen lassen will.
C ist keinen Deut besser, was Portierbarkeit angeht, nur dort hat man ein paar Krücken eingebaut, um den gleichen Quelltext (natürlich je nach Architektur mehrfach in der gleichen Datei vorhanden; #define & #ifdef) unter verschiedenen Architekturen unterschiedlich zu kompilieren. C ist nichtmal in der Lage, unter jedem C-Compiler vernünftig kompiliert zu werden. Ein Beispiel habe ich unten erwähnt.
Ich will in keiner Firma die in C Programmiert weil sie ASM nicht beherrscht.
Das kannst du nicht vermeiden, wenn du mal einen Job brauchst.
Dann liegt es aber nur an den programmieren alleine. Wenn sie zu schlecht für ASM sind, na bitte. Portierbar? Seit dem Apple auf Intel umgestiegen ist, ist das kein Thema mehr für mich. Und wenn ihr jetzt mit anderen sachen wie Mobile-Phones kommt: Wenn mein OS gut genug ist sorg ich dafür das Intel/AMD was mit mir in der Richtung machen bzw. die sorgen für mich.
Für ein einfaches "Anwendungs-Porgrammieren" ist Assembler die ungeeignetste Sprache überhaupt.
Denk mal nach, bevor du intelligente Sprüche abgibst - wie lange hat Linux gebraucht, um von Microsoft bemerkt zu werden? Wieviele Jahre?
Glaubst du wirklich, dein OS wird so toll, dass man -deswegen- Handys mit 64-Bit-AMD ausstattet? Du weißt schon, warum es verschiedene Prozessorarchitekturen gibt, oder? Stromverbrauch und Aufwand/Nutzen sind nur ein Beispiel.
Z.Z. gibt es kein vernünftiges großes OS. Linux/Unix Architektur ist der größte Rummel und Windows ist wie ein löchriger Käse (und Mac OS ist zu instabil). Bis ich mit meinem OS komme!!! Ja das ist mein Ernst und ich bin davon überzeugt.
Ich stimme dir im ersten Teil zu, aber glaubst du ernsthaft, du könntest
(a) Windows, Linux und Unix Konkurrenz machen?
(b) Hardwarehersteller dazu überreden, Hardwaretreiber für dein OS zu schreiben? Viele haben noch nichtmal mit Linux was am Hut.
(c) alle Anwendungsprogramme in allerbester Qualität und für jeden Geschmack selbst schreiben - oder große Firmen zu überreden, ihre Programme für dein OS zu schreiben/zu portieren?
(d) verlangen, dass Firmen in Assembler programmieren?
(e) besser sein, als Generationen von Programmierern vor dir? Ohne Studium? (Ironie)
Vergiss es. Überleg erstmal vorher.
Und wie taljeth schreibt, scheinen deine Gedanken auch nicht zwingend die allerbesten gewesen zu sein. Andere können soetwas nämlich auch, musst du wissen.
Ich finde diesen Krieg C/ASM/sonstwas so sinnlos ... C ist in sich Schrott, aber genauso verbreitet wie Windows - da kommt man nicht gegen an. Zudem ist jedes erwähnenswerte Betriebssystem (d.h. es läuft auf mehr als nur nem Dutzend PCs regelmäßig zur wirklichen Nutzung) in C geschrieben - auch darum kriegt man es nicht tot. Assembler macht die Situation ebenfalls nicht besser, sondern ist im Gegenteil dazu noch schwieriger/komplizierter.
Würde man eine vernünftige Programmiersprache benutzen, wäre ich gern bereit, 5% der Geschwindigkeit jedes Programms abzugeben, um Buffer-Overflows und andere derartige konzeptuelle Sicherheitsprobleme von vornherein zu vermeiden. Die Rechenleistung ist hoch genug, was man auch daran merkt, dass nicht mehr "sauber", sondern "schnell" programmiert wird. Windows ist ein Ergebnis davon, genauso wie viele andere Software (z.B. bei mir gerade Pinnacle Studio, was auf langsameren PCs nicht threadfest ist) nicht mehr ausreichend getestet werden kann.
Es wundert mich, dass man mit 4,77 MHz flüssig Videos und Musik abspielen kann (8088_Corruption) oder mit einem 286er grafisch ins Internet kommt (Arachne), aber Windows inzwischen mehrere hundert MHz voraussetzt, nur um überhaupt laufen zu können. Dass gewisse Software eine Rechentechnik voraussetzt, obwohl frühere Software mit gleichem / ähnlichem Funktionsumfang einen Bruchteil dessen benutzte.
Ein gutes Beispiel - und ich denke, da stimmen mir hier viele zu - sind Spiele. Waren es früher oft genügsame, schöne (fesselnde, interessante, tlws. lehrreiche) Spiele (z.B. Adventures), so sind es heute fordernde Spiele mit oftmals ähnlichem Inhalt (z.B. Baller-/Kriegsspiele) und wenig Story.
Gruß,
Svenska
-
@taljeth: Hast du schon mal was von Makroparameter gehört? Dort kann man dann meinetwegen die register zwischenspeichern damit man auch noch weiß welche Werte die haben. Für richtige Progger wie mich ist das aber so besser. Wenn euch Register nicht passen dann proggt nicht lowlevel sondern Fenster für Vista oder was weiß ich, am besten noch in Delphi. ^^
@Svenska: Schau dir deinen Text noch mal an, verbessere ihn und dann lese ich evt. Wenn du so proggst wie du schreibst und dir nicht mal anschaust ob das auch vernünftig aussieht (funktioniert) dann ist Assembler wirklich nichts für dich.
bitmaster
-
@taljeth: Hast du schon mal was von Makroparameter gehört?
Workaround. Damit wird das Problem nicht behoben, sondern nur versteckt. Ich sage nicht, daß das keine Möglichkeit ist. Aber mit einer besonders tollen API prahlen würde ich dann nicht, wenn man sie sowieso nicht direkt verwenden kann, weil man sich nicht merken kann, welches Register wofür zuständig ist.
Dort kann man dann meinetwegen die register zwischenspeichern damit man auch noch weiß welche Werte die haben. Für richtige Progger wie mich ist das aber so besser.
Wovon redest du? Was will ich denn zwischenspeichern?
Wenn euch Register nicht passen dann proggt nicht lowlevel sondern Fenster für Vista oder was weiß ich, am besten noch in Delphi. ^^
Ich habe kein Problem mit Registerübergabe, solange sie eine Art fastcall-Aufrufkonvention, also einheitlich ist. Sprich, der erste Parameter ist nicht mal eax, mal bl und mal r8, sondern konsequent eins davon.
-
@taljeth: Könntest du mir bitte zeigen wo ich mit meiner API geprahlt habe. Ich zeigte nur das man für eine API keinen Stack benötigt. Aber ihr wollt anscheinent keinen Stack und keine Register. Ja dann ist es in der Tat so, bleibt bei C / C++ etc. (Hochsprachen). Niemand braucht sich die Register zu merken. Dafür gibt es ja meine API Liste (die man bei Microsoft auch braucht, oder wisst ihr auswendig die Reihenfolge der auf den Stack zu speichernden Werte?)!
Wovon redest du? Was will ich denn zwischenspeichern?
ah ja
Ich habe kein Problem mit Registerübergabe, solange sie eine Art fastcall-Aufrufkonvention, also einheitlich ist. Sprich, der erste Parameter ist nicht mal eax, mal bl und mal r8, sondern konsequent eins davon.
Also die sind schon einheitlch. Schau dir DrawWindow und DrawWindowA, WritePixel, WriteMsg und WriteMsgA etc. an.
bitmaster
-
@Svenska: Du beantwortest mit dem unteren Teil deine oberen Fragen.
bitmaster
-
Ich zeigte nur das man für eine API keinen Stack benötigt.
Das ist mir durchaus bewußt. Und ob du es glaubst oder nicht - ich kann meinem Hochsprachencompiler sogar sagen, welche Aufrufkonvention er benutzen soll.
Aber ihr wollt anscheinent keinen Stack und keine Register. Ja dann ist es in der Tat so, bleibt bei C / C++ etc. (Hochsprachen).
Reine Polemik. Ich kümmere mich genau dann selbst um Stack und Register, wenn es nötig ist, und überlasse es dem Compiler, wenn nicht.
Niemand braucht sich die Register zu merken. Dafür gibt es ja meine API Liste (die man bei Microsoft auch braucht, oder wisst ihr auswendig die Reihenfolge der auf den Stack zu speichernden Werte?)!
Hm, ja, ich kann mir durchaus merken, welche Parameter eine Funktion braucht, solange es nicht irgendeine selten benutzte Funktion mit fünf oder mehr Parametern ist.
Also die sind schon einheitlch. Schau dir DrawWindow und DrawWindowA, WritePixel, WriteMsg und WriteMsgA etc. an.
Dann erklär doch mal, warum die X-Position mal rbx und mal r8 ist.
-
@taljeth: Schau dir die neuen Buttonfunktionen an. Da ist es wieder anders.
bitmaster
-
Hm, das macht es aber auch nicht einheitlicher. ;) Und der Vorteil gegenüber der Parameterübergabe auf dem Stack ist da auch minimal, wenn die Parameter sowieso im Speicher liegen müssen.
-
Hm, das macht es aber auch nicht einheitlicher. ;) Und der Vorteil gegenüber der Parameterübergabe auf dem Stack ist da auch minimal, wenn die Parameter sowieso im Speicher liegen müssen.
Das müssen sie ja sowieso. Oder meinst du das OS ratet wo jetzt der Button zum klicken ist? ;-) *nicht bös gemeint*
bitmaster
-
Ja, der minimale Vorteil besteht in dem Spezialfall, wenn du das Button-Objekt intern sowieso schon so speicherst, wie es als Parameter verwendet wird. Dann wird daraus einfach ein Pointer auf das Objekt, wogegen natürlich nichts einzuwenden ist. Und es spricht natürlich nichts dagegen, diesen Spezialfall zu benutzen. ;)
Aber jetzt hast du einmal rbx, einmal r8 und einmal rsi für den ersten Parameter (ich fasse den Pointer auf das Objekt mal als nur einen Parameter auf, wie es ja technisch ist). Warum nicht immer dasselbe Register?
-
@Warum nicht immer dasselbe Register?: Weil rsi einfach zum Offset eines Textes zeigt. Das war immer so und sollte immer so sein (ich weis außer bei DOS da war es dx). Aber was meinst du mit erster parameter?
Ob ich jetzt:
mov ecx,00FF00FFh ;color
mov rbx,10 ;x-pos
mov rdx,20 ;y-pos
WritePixel
oder
mov rbx,10 ;x-pos
mov ecx,00FF00FFh ;color
mov rdx,20 ;y-pos
WritePixel
oder
mov rdx,20 ;y-pos
mov rbx,10 ;x-pos
mov ecx,00FF00FFh ;color
WritePixel
oder ...
schreibe ist ganz egal. Da gibt es keinen ersten und letzten Parameter.
bitmaster
-
@Warum nicht immer dasselbe Register?: Weil rsi einfach zum Offset eines Textes zeigt.
In Fall des Buttons ist es aber kein Text. Aber gut, nehmen wir rsi für diese Fälle einfach mal als gegeben an. Dann bleiben immer noch rbx und r8, die anscheinend willkürlich verwendet werden.
-
@taljeth: Weil rsi immer einen Offset angeben sollte. ^^
rbx und r8 sehen irgendwie so X aus. Und r9 etc. wie Y. ^^
ja ist willkürlich
bitmaster
-
Allerdings gibt es in C (und damit in von C abgeleiteten Sprachen) Probleme, die man nicht hätte, wenn man die Sprache mal definiert hätte. [...] Dann die Datentypen - ein Byte ist nicht zwingend 8 Bit, ein Integer nicht zwingend 16 Bit und ein Long nicht zwingend 32 Bit.
Dieses Problem ist teilweise in C99 gelöst worden.
Es gibt nämlich die Datentypen int8_t, int16_t, ... die dann so viele Bits wie angegeben groß sein müssen.
-
du so proggst wie du schreibst und dir nicht mal anschaust ob das auch vernünftig aussieht (funktioniert) dann ist Assembler wirklich nichts für dich.
Ich kann kein C und programmiere in Delphi, Visual Basic und Assembler.
Es soll vernünftig ausprogrammiert sein und funktionieren. Vernünftig dabei in der Hochsprache, nicht im produzierten Code. Ich kann ja schließlich nicht jede Instruktion für i586 nachschlagen, wenn ich selbst auf i286 programmiere. Außerdem - und da scheinst du wohl anderer Ansicht zu sein - verlasse ich mich auf den Compiler (bzw. die Sprache) soweit, dass ich davon ausgehe, dass der Code das tut, was er zu tun vorgibt. Dabei fällt C schonmal raus, weil es unbestimmte - aber gültige! - Ausdrücke gibt.
@Svenska: Du beantwortest mit dem unteren Teil deine oberen Fragen.
Kannst du mir das mal quoten? Oben steht, wie es ist und unten steht, wie es sollte.
Allerdings gibt es in C (und damit in von C abgeleiteten Sprachen) Probleme, die man nicht hätte, wenn man die Sprache mal definiert hätte. [...] Dann die Datentypen - ein Byte ist nicht zwingend 8 Bit, ein Integer nicht zwingend 16 Bit und ein Long nicht zwingend 32 Bit.
Dieses Problem ist teilweise in C99 gelöst worden.
Es gibt nämlich die Datentypen int8_t, int16_t, ... die dann so viele Bits wie angegeben groß sein müssen.
Wie du schon sagst - teilweise.
Wenn mich mein Gedächtnis nicht betrügt, so stimmt es zwar, dass mit C99 solche Datentypen existieren, diese aber nur als Mindestgrößen vorgegeben sind. Das heißt, dass ein int8_t durchaus auch 9 Bit haben kann. Verlässt man sich auf die 8 Bit, steht man u.U. im Regen.
Gruß,
Svenska
-
@Svenska: Und schon wieder nicht vernüntig. Also ich hoffe wirklich das du nicht so proggst und nicht testest. Das wäre nämlich nicht so doll.
@Svenska: Du beantwortest mit dem unteren Teil deine oberen Fragen.Kannst du mir das mal quoten? Oben steht, wie es ist und unten steht, wie es sollte.
Na ja, du sagst wieso Assembler benutzen. Aber unten beschwärst du dich über die heutige Art der meisten Progger. Ich gebe dir unten recht, und damit beantwortest du gleichzeitig die Frage, warum ASM.
Ich habe nie gesagt das mein OS auf allen Privatrechnern laufen wird (und wenn doch dann habe ich übertrieben ^^). Ich sage nur:
Heute gibt es 2 Arten von Betriebssysteme:
1. Vernünftige Architektur aber unsicher und/oder relativ instabil.
2. Dämliche Architektur aber relativ sicher.
Und ich habe vor so ein OS zu erschaffen:
Vernünftige Architektur, stabil und sicher.
Ob ich das schaffe ist was anderes. :-P
bitmaster
-
Stabilität und Sicherheit eines OS hängen direkt von seiner Architektur ab. Ein System mit "vernünftiger Architektur aber unsicher und/oder relativ instabil" klingt für mich unwahrscheinlich, und eines mit "dämlicher Architektur aber relativ sicher" fast schon nach Widerspruch in sich.
Und ja, Sicherheit und Stabilität hängen natürlich auch von Fehlervermeidung, ergo der Wahl der richtigen Programmiersprache, ab. Je höher und abstrakter die Programmiersprache, desto geringer die Fehlerwahrscheinlichkeit. Und nein, auch du bist nicht so gut, daß du vollkommen fehlerfreien Code schreibst.
-
Und nein, auch du bist nicht so gut, daß du vollkommen fehlerfreien Code schreibst.
So gut ist wohl niemand :wink:
btw
ich habs mir mittlerweile angewöhnt, in ASM soviel in FUnktionen auszulagern wie möglich.
bzw. so machs ich mittlerweile in jeder anderen Sprache auch.
hat den Vorteil, dass man nur relativ geringe Codemengen auf "Fehleranfälligkeit" testen muss und wenn dann Fehler auftreten, man bestimmte Funktionen von vornerein ausschließen kann.
-
@taljeth: Dann verstehen wir beide unter meinem gewählten Ausdruck Architektur was anderes. Ich meinte:
Windows ist so aufgebaut das fast jeder es nutzen kann. Linux z.B. wird so nie von jedem benutzt werden können. Es ist einfach zu kommpliziert für einen der nur mal ebend ins Inet will, Fotos anschauen möchte, was Spielen will etc. Es liegt nicht an der gewohnten Windows Umgebung. Es ist nachgewiesen das sich Leute die noch nie am PC waren mit Windows sehr schnell vertraut sind aber unter Linux meist nicht mal ein Install hinbekommen. Man muss sich viel mit Linux beschäftigen um es gut nutzen zu können. Und deswegen ist Windows Architektur besser bzw. es ist benutzerfreundlicher.
Und ja, Sicherheit und Stabilität hängen natürlich auch von Fehlervermeidung, ergo der Wahl der richtigen Programmiersprache, ab. Je höher und abstrakter die Programmiersprache, desto geringer die Fehlerwahrscheinlichkeit.
Das hängt ganz allein vom Können des Programmierers ab.
Und nein, auch du bist nicht so gut, daß du vollkommen fehlerfreien Code schreibst.
Ich behaubte bei Sachen die ich verstanden habe und in ASM umsetze nur sehr wenige Fehler im Endergebnis zu haben.
@Biehler Productions2: Code den ich schon mal geproggt habe und für eine Sache benutzen kann, verwende ich auch dafür und progge ihn nicht noch mal neu.
bitmaster
-
Heute gibt es 2 Arten von Betriebssysteme:
1. Vernünftige Architektur aber unsicher und/oder relativ instabil.
2. Dämliche Architektur aber relativ sicher.
ich frage mich immer wieder wie sich das denn äußert, also die instabilität oder die unsicherheit Oô. ich hab seit jahren windows 2000 auf nem rechner drauf und... i.wie hatte ich noch nie probleme, weder mit system abstürzen, noch mit viren oder dergleich... dämliche architektur? da sach ich nur: na und, wenns denn funktioniert und wenn es einfach zu bedienen ist, wieso eine komplizierte, viel zu sehr durchdachte architektur nehmen? ... als programmierer finde ich z.b. die windows programmierung (also mit WinAPI) relativ gut Oô und ich seh jetzt keine wirklichen probleme da drin.
-
ich habs mir mittlerweile angewöhnt, in ASM soviel in FUnktionen auszulagern wie möglich.
bzw. so machs ich mittlerweile in jeder anderen Sprache auch.
Das macht jeder, der was von seinem Handwerk versteht. ;)
Windows ist so aufgebaut das fast jeder es nutzen kann. Linux z.B. wird so nie von jedem benutzt werden können. Es ist einfach zu kommpliziert für einen der nur mal ebend ins Inet will, Fotos anschauen möchte, was Spielen will etc.
An der Stelle widerspreche ich dir einfach mal. Spätestens seit Knoppix und Co. ist dem nicht mehr so. Aber diese Diskussion gehört hier nicht hin...
Es liegt nicht an der gewohnten Windows Umgebung. Es ist nachgewiesen das sich Leute die noch nie am PC waren mit Windows sehr schnell vertraut sind aber unter Linux meist nicht mal ein Install hinbekommen.
Äpfel und Birnen. Wieso verlangst du vom Windows-Neuling nur, daß er es bedienen kann, wenn es läuft, aber vom Linux-Neuling, daß er es installieren kann? Natürlich ist eine Installation schwieriger als reines Bedienen. Und die Linux-Installation ist im allgemeinen (Ubuntu, Suse) einfacher als die von Windows.
Man muss sich viel mit Linux beschäftigen um es gut nutzen zu können. Und deswegen ist Windows Architektur besser bzw. es ist benutzerfreundlicher.
Offensichtlich bist du dir nicht ganz im Klaren, was das Wort Architektur bedeutet, insofern reden wir in diesem Punkt aneinander vorbei. Aber gut, dann meinst du also Benutzerfreundlichkeit der GUI.
Und ja, Sicherheit und Stabilität hängen natürlich auch von Fehlervermeidung, ergo der Wahl der richtigen Programmiersprache, ab. Je höher und abstrakter die Programmiersprache, desto geringer die Fehlerwahrscheinlichkeit.
Das hängt ganz allein vom Können des Programmierers ab.
Nein. Erstens hängt es auch von der Architektur ab (Architektur hier nicht in deinem Sinne), und zweitens auch von der Programmiersprache, so sehr du es auch leugnst. Derselbe Programmierer, der sowohl gut Assembler als auch eine Hochsprache programmieren kann, wird in der Hochsprache immer schneller und fehlerfreieren Code produzieren.
Natürlich kannst du jetzt wieder sagen, aber wenn ein doppelt so guter Programmierer am Assemblercode sitzt, wird es genauso gut. Selbstverständlich - aber auch der doppelt so gute Programmierer würde mit der Hochsprache fehlerfreieren Code schreiben.
Das liegt einfach daran, daß der Assembler keine Chance hat, dir auf die Finger zu klopfen, wenn du Blödsinn machst. Ein Compiler einer Hochsprache hat da sehr viel mehr Möglichkeiten.
-
Und schon wieder nicht vernüntig. Also ich hoffe wirklich das du nicht so proggst und nicht testest. Das wäre nämlich nicht so doll.
Jetzt weiß ich wenigstens, was du meinst. Na gut, lass ich die Originalposter eben weg, wenn die Forensoftware zu blöd dazu ist ... ich mach es eigentlich überall so und bin halt davon ausgegangen, dass es funktioniert. Tut mir Leid.
Na ja, du sagst wieso Assembler benutzen. Aber unten beschwärst du dich über die heutige Art der meisten Progger. Ich gebe dir unten recht, und damit beantwortest du gleichzeitig die Frage, warum ASM.
Assembler macht die Nachteile von C noch schlimmer (kompliziert/komplex, schwierig, fehleranfällig, langsam). Damit sage ich nicht, dass man mit Assembler bessere Ergebnisse erzielt - denn das glaube ich nicht - noch, dass der Code übersichtlicher und damit gut wartbar ist.
Und ich stimme taljeth vollkommen zu; der kann sich besser ausdrücken als ich.
Übrigens: Es ist nachgewiesen, dass jemand, der noch die vorm PC gesessen hat, mit OS/2 bedeutend besser klarkam, als mit Windows (sowohl 3.1 als auch 95) und diejenigen, die mit OS/2 begonnen haben, nach wie vor die WPS (Workplace Shell) allem anderen vorziehen. Aber OS/2 ist so gut wie tot. Das mal ohne Kommentar.
ich frage mich immer wieder wie sich das denn äußert, also die instabilität oder die unsicherheit
Das liegt teilweise in der Architektur begraben - einerseits, wie ein Treiber oder Anwendungsprogramm, welches nicht zum System selbst gehört, fremde Prozesse beeinflussen kann, andererseits, inwiefern Programme Amok laufen dürfen. Je nachdem, wie dies in unvorhergesehener Weise möglich ist, ist das eine Stabilitätsfrage.
Beispiel: Windows 3.1 im Standard-Modus schaltet für DOS-Anwendungen in den Real-Mode des Prozessors zurück (80286) und somit den Speicherschutz effektiv aus. Dieses DOS-Programm kann sämtliche Windows-Daten seinerseits zerstören, ohne, dass Windows da etwas gegen tun kann. Das geht im V86-Modus natürlich nicht mehr.
Unsicherheit liegt in der Implementation begraben, denn durch schlampige Programmierung kann man auf Innereien eines Programmes zugreifen, die eigentlich verborgen bleiben sollten. Damit kann man Programme entweder zum Absturz bringen (die Grenze Instabilität/Unsicherheit ist also fließend) oder zu unvorhergesehenen Aktionen treiben (a.k.a. Daten klauen, Rechte kriegen, Daten bewusst zerstören).
(Nahezu) fehlerfreie Software läuft meist stabil und ist sicher, sofern der Unterbau (Bibliotheken, OS) entsprechend ausgerüstet ist. Windows 2000 ist in der Hinsicht schon ganz gut dabei. Allerdings gibt es auch da noch Probleme. Wenn ich einen TV-Kartentreiber installiere, friert mir gelegentlich das System ein - auch unter Windows 2000.
Die WinAPI ist eine binäre Programmierschnittstelle (also eher ein ABI) zu den Systemfunktionen und damit eine Architekturschwäche (bzw. je nach Auslegung auch eine Stärke): Einerseits weiß man, dass das Interface stabil bleibt und man es damit auch benutzen kann, ohne Gewissensbisse zu haben, andererseits ist es nicht erweiterungsfähig, ohne die Kompatiblität zu gefährden. Aus diesem Grund ist die Winapi auch so furchtbar komplex - und sei es nur, um Win16api-Programme auszuführen. Somit ist jede damalige Funktion vorhanden und die neue auch. Dann gibt es immer verschiedene Versionen für ANSI (1-Bit-Strings), DBCS (2-Bit-Strings unter Win16) und Unicode (2-Bit-Strings unter Win32). Dazu kommen dann noch die API-Funktionen für Win64, was an und für sich zu einer enormen Masse an Funktionen geführt hat, die man unterstützen muss.
Praktisch ist sie dagegen schon - man weiß, wie man sie aufruft und weiß damit alles, was man wissen muss. Wie sie funktioniert, bleibt verborgen. Ob das nun gut oder schlecht ist, muss jeder für sich entscheiden.
Ich schweife ab, aber wir sind ja hier im OT... :p
Gruß,
Svenska
-
Jetzt weiß ich wenigstens, was du meinst. Na gut, lass ich die Originalposter eben weg, wenn die Forensoftware zu blöd dazu ist ...
Probier mal [quote author=xyz]...[/xyz].
Edit: Doofe Forensoftware, hast recht. Nichtmal das klassische Escapen von BBCode funktioniert richtig...
-
@maumo: Ich meinte damit auch nicht Windows. ^^ loooool
@taljeth: Nein, auch mit Knoppix, SuSE, Ubuntu bekommen die nicht mal eine Installation hin (nicht das OS installieren sonder ein Programm dafür).
Aber gut, dann meinst du also Benutzerfreundlichkeit der GUI.
Nein, ich meine nicht nur die GUI.
Gut, ich muss dir zustimmen, Hochsprachen sind einfacher und vermeiden Fehler. Aber für einen guten Progger der alles gut durchdenkt, alles gut testet und gut in ASM ist dürfte das nicht viel ausmachen.
@Svenska: Mit dem vollgepumpten Windows gebe ich dir recht. Die haben das wohl nicht mehr unter Kontrolle. ^^ Aber mit ASM lassen sich bessere Ergebnisse erzielen. Das kann keiner leugnen. Ob jemand das kann ist was anderes.
lol
text
geht doch, also die " nicht vergessen ^^
bitmaster
-
@taljeth: Nein, auch mit Knoppix, SuSE, Ubuntu bekommen die nicht mal eine Installation hin (nicht das OS installieren sonder ein Programm dafür).
Da habe ich bisher aber immer das Gegenteil gehört. Synaptic (bei Ubuntu) wird eigentlich bei Linux-Neulingen immer sehr gut aufgenommen.
Nein, ich meine nicht nur die GUI.
Was dann?
Gut, ich muss dir zustimmen, Hochsprachen sind einfacher und vermeiden Fehler. Aber für einen guten Progger der alles gut durchdenkt, alles gut testet und gut in ASM ist dürfte das nicht viel ausmachen.
Du gehst davon aus, daß jemand, der Fehler macht, diese macht, weil er nicht schlau genug ist. Das ist Blödsinn. Der Großteil aller Fehler sind Flüchtigkeitsfehler, die jedem passieren - egal wie gut er die Sprache beherrscht oder wie intelligent er ist.
Und selbst wenn er so gut testet, daß er jeden Fehler findet und beheben kann, hat es ihn Zeit gekostet. In der Wirtschaft hast du nicht viel Zeit, da muß alles möglichst bis vorgestern fertig sein.
Dazu kommt mir übrigens auch folgendes Zitat in den Sinn: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
-
@taljeth: Hmm... genau das sagt man von Mathe ja auch immer. Aber wieso habe ich in den letzten 3 Jahren nie schlechter als 2+ eine Arbeit geschrieben? Weil ich unter Zeitdruck stehe und nicht alles ganz gründlich nachschauen kann. Sonst wären meine viele einsen noch mehr und keine zweien mehr. Dies ist kein schwäzen. Ich will nur verdeutlichen das man wenn man gut ist und alles genaustens testet so gut wie keine Fehler macht.
Ich gebe dir recht das die meisten Progger heute unter Zeitdruck stehen und deswegen Fehler zu finden sind. Aber ich stehe nicht unter Zeitdruck und lasse mich auch nicht vom wachsenden Markt unter diesen bringen. Dann mag es sein das ASM in diesem "alles schnell aber nicht genug getestet Markt" nicht mithalten kann. Aber genau dazu möchte ich nicht zählen. Egal ob mein OS dann nie in diesem Markt landen wird. Ich werde doch nicht Schnelligkeit auf Kosten von Stabilität setzen.
bitmaster
-
@taljeth: Hmm... genau das sagt man von Mathe ja auch immer. Aber wieso habe ich in den letzten 3 Jahren nie schlechter als 2+ eine Arbeit geschrieben? Weil ich unter Zeitdruck stehe und nicht alles ganz gründlich nachschauen kann. [...] Ich will nur verdeutlichen das man wenn man gut ist und alles genaustens testet so gut wie keine Fehler macht.
Schon richtig, Qualität kostet Zeit. Aber das ist hier nicht der Punkt. Du kannst dieselbe Qualität je nach Sprache in kürzerer oder längerer Zeit erreichen.
Übertragen auf dein Mathe-Beispiel: Wenn du alles im Binärsystem oder vielleicht besser noch in römischen Zahlen rechnen müßtest, würdest du bei gleichem Zeitaufwand auch mehr Fehler machen. Das hätte nichts damit zu tun, daß du plötzlich dümmer wärst, sondern damit, daß es römische Zahlen umständlicher machen als es nötig ist.
Bei konstantem Zeitaufwand und konstanter Intelligenz des Programmierers wird die Qualität von Software mit der zunehmenden Abstraktion der Programmiersprache steigen.
-
@taljeth: Wenn die Ausgabe von einer Hochsprache genauso klein und schnell wäre ja. Aber wie gesagt mischt der Compiler immer was unnötiges dabei.
bitmaster
-
Im Zweifelsfall ist mir Korrektheit wichtiger als das letzte Prozent Geschwindigkeit oder Dateigröße.
(An dieser Stelle sage ich normal auch immer, daß mein Assembler-Code von der Geschwindigkeit her sicher auch dann nicht an die Compilerausgabe mit -O3 rankommt, wenn ich überflüssiges weglasse, aber du kannst es ja offenbar so gut, daß dieses Argument für dich nicht gilt)
-
Eine Frage: Wenn ihr so richtige Programmierer seid - und natuerlich in einem (explizit: ein (1)) Assembler programmiert -, was weiss ich wie intelligent seid und nie Fehler macht.. wie kommts, dass C scheinbar gar nicht verstanden wird? C ist ein dicker fetter Makroassembler. Immer schon gewesen, und wird auch immer so bleiben. Nur weil man mit einer flexiblen Schreibweise nicht zurechtkommt, und meint alles besser machen zu koennen als Jahrzehnte alte Compiler, die wirklich gut optimieren koennen, heisst das noch lange nicht, dass Hochsprachen keine "richtigen" Programmiersprachen sind. Ganz im Gegenteil: es geht darum ein Problem auf moeglichst einfachem und effizienten Weg zu loesen, nicht sich damit herumzuschlagen wie zum Geier man jetzt eine verkettete Liste auf einer spezifischen Architektur mit Opcodes implementiert.
Und um nochmal ganz klar und persoenlich Stellung zu nehmen bezueglich deiner Aussage, bitmaster:
Für richtige Progger wie mich ist das aber so besser. Wenn euch Register nicht passen dann proggt nicht lowlevel sondern Fenster für Vista oder was weiß ich, am besten noch in Delphi. ^^
Ich wuerde deine Arroganz ablegen und ein wenig reflektieren. Vielleicht kommst du ja dann auf ein klitzekleines Detail - ja genau, der riesige Zaunpfahl mit dem ich in meinem vorigen Post schon gewinkt habe, und mit welchem ich jetzt wieder winke. Es ist ein Unterschied zwischen loesungsorientiertem Entwickeln, und Entwickeln um des Entwickeln Willens. Was du hier versuchst, ist den Oberchecker raushaengen zu lassen, weil du ein Betriebssystem in Assembler programmierst. Ich frage mich nur.. "Ja.. und?" - das haben schon einige vor dir geschafft, nur war das vor 20 oder mehr Jahren aktuell :) . Abgesehen davon: Ich nehme nicht an, dass du mit deinen Qualifikationen versuchst einen Job als Programmierer zu bekommen, oder? Wenn doch: mutig, mutig. Ich wuerd' mich gar nicht mal trauen eine Bewerbung loszuschicken.
Svenska: Intelligentes (System)Design ist natuerlich die Voraussetzung fuer Portierbarkeit. Aber ich denke, das sollte dir bewusst sein.
Abschliessend moechte ich noch anmerken.. oder besser ersuchen.. bitte, bitte erfuellt nicht immer die Stereotypen von engstirnigen und dummen Informatikern - es gibt schon viel zu viele. Danke.
-
@taljeth: Hmm... genau das sagt man von Mathe ja auch immer. Aber wieso habe ich in den letzten 3 Jahren nie schlechter als 2+ eine Arbeit geschrieben?
Du wirst es nicht glauben, aber so habe ich auch einmal gedacht. Bis zur 10. hatte ich grundsätzlich einen Schnitt von 1,0-1,2 in Mathe.
Dann kam pünktlich zur 12.Klasse (ich bin jetzt 13.) ein Lehrerwechsel. Seitdem freue ich mich über jede 2. Das hat, finde ich, nichts mit Dummheit zu tun, sondern mit der Art und Weise, in der ich bisher gearbeitet habe und mit dem Stoff an sich, der sich sehr geändert hat.
Weil ich unter Zeitdruck stehe und nicht alles ganz gründlich nachschauen kann. Sonst wären meine viele einsen noch mehr und keine zweien mehr. Dies ist kein schwäzen. Ich will nur verdeutlichen das man wenn man gut ist und alles genaustens testet so gut wie keine Fehler macht.
Wenn ich fies bin, weise ich dich mal darauf hin, dass man schwätzen mit "t" in der Mitte schreibt... so viel zu Zeitdruck und Gründlichkeit. Aber das ist hier egal.
Du gehst grundsätzlich davon aus, dass der Programmierer "gut" ist. Aber das ist kein Argument. Ein "guter" Programmierer kann, nach deiner Definition, auch in Binärcode programmieren und dabei immernoch korrekte, hochoptimierte, funktionierende Programme schreiben. So ist das aber nicht.
Ich gebe dir recht das die meisten Progger heute unter Zeitdruck stehen und deswegen Fehler zu finden sind.
Zeitdruck würde ich persönlich noch als untertrieben bezeichnen. Was ich gelegentlich höre, ist da schon ein bisschen extremer. "Morgen muss das funktionieren, denn um 15oo wird das vorgeführt!" - "Aber da ist noch gar nichts vorhanden" - "Egal, du hast noch 10 Stunden, dann geht es. Punkt."
So in der Art etwa.
Aber ich stehe nicht unter Zeitdruck und lasse mich auch nicht vom wachsenden Markt unter diesen bringen.
Ich will diese Aussage sehen, wenn du damit Geld verdienen und durch Unpünktlichkeit potentielle Käufer (= Geld) abschrecken würdest.
Ich werde doch nicht Schnelligkeit auf Kosten von Stabilität setzen.
Wenn du anfängst, in deinem OS Features zu implementieren, dann wirst du wahrscheinlich auch ein bisschen anfangen zu schlampen. Vermute ich einfach mal. Denn z.B. TCP/IP ist eine Sammlung von rekursiven Abhängigkeiten. Ohne Hardwaretreiber kannst du kein IP testen, ohne IP wiederum kannst du keinen Hardwaretreiber testen. So geschieht es an vielen Stellen. Auch glaube ich nicht, dass du auf Anhieb eine komplett ausreichende API erschaffst. Wenn du z.B. einen Taschenrechner erzeugst, fehlt dir vielleicht in deiner Mathematik-Bibliothek ein bisschen was, dann passt du das dort an und möglicherweise brennt dir dann ein anderes Programm, was die alte Bibliothek brauchte, durch. Unter Umständen merkst du es nichtmal ... und released. Dann hast du deine Stabilität schon gebrochen.
Je komplexer dein Projekt wird, umso weniger kannst du alles testen. Vielleicht merkst du später, dass dein jetzt guter Ansatz irgendwann total fehl am Platze ist - oder du sogar jetzt schon Fehler einprogrammiert hast? Wer sagt dir, dass z.B. deine GDT auch beim allerletzten Eintrag korrekt bleibt und nicht mit verhunzten Grenzen abraucht?
Oftmals sind -das- die Fehler, mit denen man Probleme hat und nicht das Eintippen in die entsprechende Sprache. Denn dann fängt man notgedrungen an zu pfuschen, um nicht alles neu aufarbeiten zu müssen.
Bei konstantem Zeitaufwand und konstanter Intelligenz des Programmierers wird die Qualität von Software mit der zunehmenden Abstraktion der Programmiersprache steigen.
Der Spruch ist klasse! Den muss ich mir merken. :-)
Svenska: Intelligentes (System)Design ist natuerlich die Voraussetzung fuer Portierbarkeit. Aber ich denke, das sollte dir bewusst sein.
Das ist wahr. Aber nachdem ich etwas in den Minix-Code reingeschaut habe, finde ich #ifdef und #define einfach grausam. So kann man nicht vernünftig für verschiedene Plattformen entwickeln... mich überrascht es dabei, dass es doch getan wird (siehe Linux, Minix).
Gruß,
Svenska
-
Um das Ganze mal abzukürzen. Das ich Schwätzen mit d geschrieben habe liegt ebend daran das ich beim schreiben hier nciht alles gründlich anschaue. Ich habe schon so viele verschiedene Mathe lehrer gehabt.
Zeitdruck würde ich persönlich noch als untertrieben bezeichnen. Was ich gelegentlich höre, ist da schon ein bisschen extremer. "Morgen muss das funktionieren, denn um 15oo wird das vorgeführt!" - "Aber da ist noch gar nichts vorhanden" - "Egal, du hast noch 10 Stunden, dann geht es. Punkt."
So in der Art etwa.
Meine Antwort: Dann machen Sie es bitte selber.
Ja, ich will in keiner zurzeit vorhandenen Softwarefirma arbeiten. Da fehlen mir die Hochsprachenkenntnisse bzw. den Firmen das Assembler (je nachdem wie man es sieht).
Ich werde Assembler irgendwann so gut wie meine Muttersprache können (nicht von der Rechtschreibung her ^^).
Bitte versteht mich nicht falsch. Ich sage nicht das man mit Hochsprachen keine saubere Sachen hinbekommt. Nur es liegt einmal am Compiler und einmal am Progger. Aber leider wird es nie so sauber wie es in ASM gemacht sein kann.
sehr sehr gut ASM = wesentlich besser als sehr sehr gut C
schlecht ASM = vielleicht sogar schlechter als sehr sehr gut C
bitmaster
-
Ich werde Assembler irgendwann so gut wie meine Muttersprache können (nicht von der Rechtschreibung her ^^).
Bitte versteht mich nicht falsch. Ich sage nicht das man mit Hochsprachen keine saubere Sachen hinbekommt. Nur es liegt einmal am Compiler und einmal am Progger. Aber leider wird es nie so sauber wie es in ASM gemacht sein kann.
sehr sehr gut ASM = wesentlich besser als sehr sehr gut C
schlecht ASM = vielleicht sogar schlechter als sehr sehr gut C
Falsch. Der C Compiler erzeugt Assembler - optimierten Assembler -, und du baust per Hand Hochsprachenkonstrukte nach, die dein Assembler gar nicht mal optimieren kann. Ich hoffe du begreifst irgendwann mal, dass Compiler sehr sehr sehr viel besser optimieren koennen, als du. Aber hoechstwahrscheinlich wirst du dem wieder widersprechen und auf deine Genauigkeit hinweisen, die natuerlich jedes automatisierte, getestete und vor allem durch Erfahrung gepraegte Optimierungsprogramm uebertrifft - natuerlich!
Ich will wirklich nicht unhoeflich erscheinen, aber komm doch bitte mal auf den Boden der Tatsachen zurueck. Wie alt bist du? 40? 50? Hast du Computer Science studiert und schon mehrere Hochsprachencompiler gebaut und bist zu dem Schluss gekommen, dass sie einfach unsauber arbeiten? Ja? Sollte das der Fall sein, dann bitte ich um Verzeihung fuer meine ueberaus kurzsichtige Sichtweise und gebe mich geschlagen.... Halt! So wie du hier schreibst bist du keine 16 Jahre alt, insofern: Nein.
Zu guter Letzt, moechte ich noch hinzufuegen, dass C tatsaechlich sehr sonderbar sein kann unter Umstaenden, aber trotzdem in den letzten Jahren gute Dienste geleistet hat. Es gibt mittlerweile sogar einige maechtige Nachfolger, die teilweise in die gleiche Richtung zielen, teilweise eher in andere Bereiche, aber immer noch im Kern von C abstammen. C hat gute Pionierarbeit geleistet, die ich nicht missen will. :)
-
@hannibal: Also 40 bin ich nicht, aber auch nicht jünger als 16. Das was du sagst ist einfach falsch. Schau dir gcc compilierten Code an und frage dich warum da so viel Unsinn drin ist (jetzt bitte nicht nur was kleines, da könnte es sein das der compiler das noch hinbekommt.
Vergleich:
Fenster mit Button:
ASM ca. 8 KByte, C ca. 64 KByte (Borland sogar evt. noch mehr)
Ja, ich weiß ist ein schlechtes Beispiel wegen den zusatzsachen für die Fenster etc. (kenn jetzt nicht so die Ausdrücke). Aber ich habe noch keinen Compiler gesehen der kleineren und/oder schnelleren Code erzeugt als ein ASM. Beweis mir das Gegenteil. Ja, ich bin ASM-Freak!!! Bist du 40 oder 50 und hast Compiler gebaut um sagen zu können das diese so gut optimieren?
bitmaster
-
Der Fenster mit Button Code ist mit Assembler auch 64 KB groß, wenn du die gleichen statischen Libs einbindest.
Assembler ist gut, wenn du direkt auf Register etc. zugreifen musst. Das muss man nur sehr wenig und für diesen wenigen Teil kann man auch mit Inline-Assembler arbeiten. Ich behaupte auch, dass der GCC Code, wenn man ihn richtig optimiert (durch setzen von -O3 und diversen anderen Flags und normal strukturierten Code) schneller ist als dein handgeschriebener Assemblercode. Dein Assembler kann nicht Inlinen, zumindest solange du es nicht per Hand machst. Er reagiert nicht auf die speziellen Eigenschaften einer Maschine (Optimierung für eine bestimmte Pipeline (Instruction scheduling) und Caching etc.). Selbst die Ausrichtung von Loops auf Pages musst du selbst machen, wenn du an das Ergebniss von GCC rankommen willst. Ich glaube nicht, dass du in der Lage bist solchen Code zu erstellen, niemand ist in der Lage das zu tun. Hinzu kommt die Portierbarkeit. Assembler Code ist nicht portierbar und selbst wenn dein Code für eine CPU-Generation perfekt ist, sieht es bei der nächsten ganz anders aus, da durch unterschiedliche Caches, Instructions und Pipelines der Code wieder ineffektiver wird. C Code ist dagegen sehr gut portierbar.
-
Ich glaube nicht, dass du in der Lage bist solchen Code zu erstellen, niemand ist in der Lage das zu tun.
Um bitmaster den Wind aus den Segeln zu nehmen: Freilich geht das. Es geht nur nicht mit vernünftigem Aufwand.
Schau dir gcc compilierten Code an und frage dich warum da so viel Unsinn drin ist (jetzt bitte nicht nur was kleines, da könnte es sein das der compiler das noch hinbekommt.
Ich hätte ja gesagt, bei was kleinerem kommst _du_ vielleicht noch hin. Der Compiler spielt seine Stärke erst aus, wenn es mal ein bißchen ernsthafter wird. Dann blickst du von Hand nämlich nicht mehr durch.
-
Dann blickst du von Hand nämlich nicht mehr durch.
Und da sind wir wieder bei dem was ich meine. Aber ersetze das "du" durch "die meisten". GCC optimiert nicht perfekt. Sowie kein Compiler.
bitmaster
-
Um das Ganze hier mal zu beenden. Ich interessiere mich einzig und allein für die x86-64 Architektur und deswegen spielt für mich portierbarkeit keine Rolle. Und Hochsprachen passen nicht zu mir. Die klauen mir den ganzen nervenkitzel. Ich finde die x86-64 Architektur klasse, und die bekomme ich in vollen Zügen nur mit ASM. ^^
bitmaster
-
Dann blickst du von Hand nämlich nicht mehr durch.
Und da sind wir wieder bei dem was ich meine. Aber ersetze das "du" durch "die meisten". GCC optimiert nicht perfekt. Sowie kein Compiler.
Und du auch nicht. So what?
Und Hochsprachen passen nicht zu mir. Die klauen mir den ganzen nervenkitzel.
Na endlich. Das erste akzeptable Argument deinerseits in diesem Thread. ;)
-
Und du auch nicht. So what?
na, also ob das so stimmt
Na endlich. Das erste akzeptable Argument deinerseits in diesem Thread.
Nee, also so kann man das nicht sehen.
bitmaster
-
sehr sehr gut ASM = wesentlich besser als sehr sehr gut C
schlecht ASM = vielleicht sogar schlechter als sehr sehr gut C
Ich habe mal einen Vergleich in einer Zeitschrift gelesen, in dem (auf 16 Mhz 386SX) Assembler mit QuickBasic (kompiliert) verglichen wurde.
Am Ende kam raus, dass der nichtoptimierte Assemblercode genausoschnell war wie der hochoptimierte Basiccode. Es handelte sich um einen Vergleichsalgorithmus. Daraus lässt sich schließen, dass Assembler zwar schnell sein kann, aber nicht muss. Eine solche Optimierung erfordert einen entsprechend guten Programmierer. Solcher Code ist dazu meist nicht mehr vernünftig von anderen versteh- oder lesbar.
Dazu vergisst du in deiner Betrachtung den Prozentsatz an I/O. In der heutigen Zeit ist es meistens viel wahrscheinlicher, dass du auf die Festplatte wartest, als ständig was rechnest. D.h. die maximale CPU-Geschwindigkeit spielt eh keine große Rolle, da du ja auf Komponenten wartest, deren Geschwindigkeit per Definition um Größenordnungen geringer ist.
Gruß,
Svenska
-
@Svenska: Genau das meinte ich. Danke!!!!!!!
bitmaster
-
Ok. Wir sind soeben auf ein sehr sonderbares Niveau... eh.. gesunken, wuerde ich mal sagen. Du kannst keinen QBasic Compiler mit GCC, ICC, oder sonstigen C Compilern vergleichen. Da steckt weitaus mehr dahinter bei einem C Compiler, vor allem bei den ganz Grossen.
*Kopf schuettel*
-
Ich wollte damit nur zeigen, dass QB (welches per Definition um mind. Faktor 10 langsamer ist) durchaus die Geschwindigkeit von Assembler erreichen kann. Zudem muss man da auch weiterdenken - QB optimiert nicht von allein. Assembler auch nicht. C schon.
Ich gebe dir recht, dass Assembler die Möglichkeit zur optimalen Geschwindigkeit bietet. Aber: Ich bezweifle, dass du in der Lage bist, diese Möglichkeit zu nutzen. Eher schon ein C-Compiler wie gcc, der von Leuten programmiert wurde, die erheblich mehr von den Innereien der CPU verstehen als du. Die wissen dann auch, wie man das letzte Prozent aus der Hardware rauskitzelt.
Sofern du also nicht in der Lage bist, richtig guten / perfekten Assembler zu schreiben, bist du mit einer Hochsprache besser bedient. Denn da schaffst du es, in kürzerer Zeit (Zeit=Geld) mehr vom Programm fertigzustellen, als in Assembler. Zudem hast du mehr Zeit fürs Optimieren, die dir bei gegebener Zeit fehlt und die dann dafür sorgt, dass dein Assemblerprogramm langsamer läuft als das vergleichbare Hochsprachenprodukt.
In diesem Beispiel war die Entwicklungszeit für das Programm in QB+Optimierung genauso groß wie die Entwicklung in Assembler ohne Optimierung. Die Ausführungszeit war fast gleich. Überträgst du das Problem auf C, welches ja an sich schon bedeutend schneller ist als Assembler, hast du vielleicht eine Vorstellung, welchen Verlust die Entwicklung in Assembler eigentlich bedeutet.
Außerdem - und das ist viel wichtiger - hast du trotzdem deine I/O-Last. Der Geschwindigkeitsunterschied, den du mit deiner Sprache erreichst, spielt ohnehin keine Rolle, da ein moderner Prozessor >90% seiner Zeit eh im Leerlauf ruht. Da ist Optimierung nicht das große Thema, sondern eher die Programmierung in gegebener Zeit. Ich glaube nicht, dass du die Zeit (wie du schriebst) vernachlässigen kannst. Ein Treiber muss auf dem Markt sein, bevor die Konkurrenz entsprechende Produkte liefert. Da kommt es dann auf schnelle Entwicklung bei guter Funktionalität an.
Du kannst auf keinem Markt mit deiner Philosophie bestehen. Und ohne Markt wirst du nie etwas erreichen.
Gruß,
Svenska
-
@Svenska: Danke, aber erstens habe ich keine Lust mehr aus diese Schwachsinnige Diskussion. Und zweitens, wie blöd muss man ASM programmieren um nur die Geschindigkeit von QB zu erreichen. *kopfschüttel*
bitmaster
-
Und zweitens, wie blöd muss man ASM programmieren um nur die Geschindigkeit von QB zu erreichen. *kopfschüttel*
Das hat nichts mit Blödheit zu tun, sondern mit elementarer Logik. Einerseits ist die Sprache an sich schon in der Lage, gewisse Sachen zu tun, andererseits ist sie nicht zwingend sehr gut dabei. Es ist ein Unterschied, ob ich den Bildschirm pixelweise oder blockweise beschreibe - schon allein dadurch komme ich auf einen Geschwindigkeitsunterschied, der bedeutend größer ist als der Unterschied, ob ich das nun mit C oder ASM mache. Zweitens darfst du auch Programmlogiken und Algorithmen nicht vergessen. Du brauchst nur einen nicht-optimalen Algorithmus benutzen und bist schon weit drunter. Gegen solche Entscheidungen hilft übrigens auch gcc nicht mehr. Mit Bubblesort haben wir in der Schule 2 Minuten auf unser Ergebnis gewartet, Quicksort erreichte das in unter 2 Sekunden. Trotzdem werde ich für kleine Datenmengen Bubblesort implementieren - einfach, weil der relativ schnell zu implementieren und zu verstehen ist und weil Geschwindigkeit nicht so wichtig ist, dass man sich da ewig mit Optimierungen beschäftigen muss.
Bin ich darum blöd?
Dafür habe ich in QB bedeutend mehr Entwicklungskomfort, ich kriege viele Fehler gleich mitgeteilt. Logische Fehler wie z.B. Indexüberschreitungen werden gleich festgestellt, während mir in Assembler u.U. der gesamte Adressraum um die Ohren fliegt. Diese Entscheidung ist oft wichtiger als die Implementation selbst.
-
Wenn ich mit QBasic natürlich Blockweise Pixel setzte und mit ASM
mov rdi,dawopixelhinsoll
mov rcx,yanzahl*xanzahl
.1:
push rcx
mov eax,color
stosd
mov rcx,0FFFFFFFFFFFFFFFFh
loop $
pop rcx
loop .1
schreibe, dann ist der Basic code sicher schneller. Ich gebe dir da ja recht. Das einzige was ich bis jetzt sage ist:
Mit ASM kann man die volle schnelligkeit rausholen und mit anderen nicht. Ob das der Mensch kann, ist was anderes. Ich progge ASM ja nicht unbedingt wegen der Schnelligkeit sondern wegen dem spaß am x86 und x86-64 der mir bei den Hochsprachen verloren geht.
bitmaster
-
Mit ASM kann man die volle schnelligkeit rausholen und mit anderen nicht.
Würde ich so allgemein nicht sagen, weil das Verhältnis Programm<->Wartezeit bei weitem nicht optimal ist.
Ich progge ASM ja nicht unbedingt wegen der Schnelligkeit sondern wegen dem spaß am x86 und x86-64 der mir bei den Hochsprachen verloren geht.
Damit sehe ich die Diskussion als beendet an.
Gruß,
Svenska
-
Damit sehe ich die Diskussion als beendet an.
Schön das zu hören.
bitmaster