Thema: Ist C und Unix nur ein Joke?

[Biehler Productions2]

bin mir aber ziemlich sicher, dass das nicht geht

Geht das denn in ASM?

bitmaster

Nicht ganz genauso, aber das hab ich nie behauptet
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"
 
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 

Edit: Eigentlich wollte ich aber garnicht so eine Diskussion lostreten!  sad

Ach, schadet doch nix.
So hat man wenigstens mal wieder ne ordentliche Diskussionsrunde 

[Korona]

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.

[bluecode]

@bitmaster: Ich hätt gern eine Antwort auf meine Frage 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

[Biehler Productions2]

@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?

[bitmaster]

@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

[Korona]

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.

[kevin]

@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.

[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?

bitmaster

[Svenska]

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

[bitmaster]

@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

[kevin]

@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.

[hannibal]

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

[Biehler Productions2]

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. 

[bitmaster]

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

[Biehler Productions2]

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* 

[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* 

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

[Biehler Productions2]

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* 

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.

[bitmaster]

@Biehler Productions2: Jo, und darauf sagte ich: Schau dir meine API-Funktionen an.

bitmaster

[kevin]

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.

[Svenska]

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