Thema: Ist C und Unix nur ein Joke?

[bitmaster]

@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

[kevin]

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

[bitmaster]

@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

[bitmaster]

@Svenska: Du beantwortest mit dem unteren Teil deine oberen Fragen.

bitmaster

[kevin]

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.

[bitmaster]

@taljeth: Schau dir die neuen Buttonfunktionen an. Da ist es wieder anders.

bitmaster

[kevin]

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.

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

Das müssen sie ja sowieso. Oder meinst du das OS ratet wo jetzt der Button zum klicken ist? *nicht bös gemeint*

bitmaster

[kevin]

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?

[bitmaster]

@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

[kevin]

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

[bitmaster]

@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

[bbl]

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.

[Svenska]

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

[bitmaster]

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

bitmaster

[kevin]

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.

[Biehler Productions2]

Und nein, auch du bist nicht so gut, daß du vollkommen fehlerfreien Code schreibst.

So gut ist wohl niemand 

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.

[bitmaster]

@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

[maumo]

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.

[kevin]

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.