Diskussion:OS-Dev für Einsteiger — Änderungen 7921 → 9689

Zeile 56: Zeile 56:
 
:Soweit ich das gestern im IRC mit DickHuuhn verstanden habe, haben wir uns darauf geeinigt, dass es wohl ganz gut wäre, wenn man die [[Literatur]]-Seite um ein paar Links/Bücher für Programmieranfänger erweitert und dann in diesem Artikel darauf verweist (Einspruch, wenn dem nicht so ist ;-)). —[[Benutzer:XanClic|Clici McXan]] 12:32, 15. Jul. 2010 (CEST)
 
:Soweit ich das gestern im IRC mit DickHuuhn verstanden habe, haben wir uns darauf geeinigt, dass es wohl ganz gut wäre, wenn man die [[Literatur]]-Seite um ein paar Links/Bücher für Programmieranfänger erweitert und dann in diesem Artikel darauf verweist (Einspruch, wenn dem nicht so ist ;-)). —[[Benutzer:XanClic|Clici McXan]] 12:32, 15. Jul. 2010 (CEST)
 
::Das mit einer Literatur-Liste für Anfänger ist meiner Meinung nach eine recht gute Idee. Trotzdem muss noch geklärt werden wie viel "Programmieranfängerhilfe" wir hier überhaupt geben können/wollen. Erst dann können wir den betreffenden Satz auch passend formulieren. --[[Benutzer:Erik.vikinger|Erik.vikinger]] 13:06, 15. Jul. 2010 (CEST)
 
::Das mit einer Literatur-Liste für Anfänger ist meiner Meinung nach eine recht gute Idee. Trotzdem muss noch geklärt werden wie viel "Programmieranfängerhilfe" wir hier überhaupt geben können/wollen. Erst dann können wir den betreffenden Satz auch passend formulieren. --[[Benutzer:Erik.vikinger|Erik.vikinger]] 13:06, 15. Jul. 2010 (CEST)
 +
 +
== Was soll das mit C und UNIX ? ==
 +
 +
Ich will ja niemand beleidigen, aber Betriebssystem schreibt mann wohl kaum in einer Hochsprache, und UNIX bzw. Linux oder Windows, haben wohl kaum etwas mit der Realität (also Hardware) zu tun. Für die Essenziellen Teile eines Betriebssystems, ist eigentlich Assembler die einzige vernünftige Programmiersprache, wobei auch gute Kenntnisse in Maschinensprache nötig sind um es wirklich gut zu machen. Mal davon abgesehen dass die (häufig unnötigen) Stackoperationen größeren Code erzeugen, und den Prozessor ausbremsen, kann ein Compiler - so modern er auch ist - nunmal kein Kontextwissen haben und somit keinen wirklich guten Code erzeugen. Und bei Systemaufrufen, die massenhaft im Hintergrund aufgerufen werden, können ein paar unnötige Befehle die Geschwindigkeit enorm verzögern. Dazu kommen noch die Sicherheitsrisiken, dadurch das man nicht weis wie das Programm letztendlich aussschaut.
 +
 +
Beispiel:
 +
 +
Folgende C-Prozedur ....
 +
 +
include <dos.h>
 +
unsigned char readCMOS (unsigned char a)
 +
{
 +
  outportb(0x70,a);
 +
  return inportb(0x71);
 +
}
 +
 +
... würde etwa folgenden Code (in Assembler) erzeugen ...
 +
 +
_READCMOS proc near
 +
  push bp        ; 1 byte
 +
  mov bp,sp      ; 2  "
 +
  mov ax,[bp+4]  ; 3  "
 +
  push ax        ; 1  "
 +
  mov ax,70h    ; 3  "
 +
  push ax        ; 1  "
 +
  call _OUTPORTB ; 3  "
 +
  pop cx        ; 1  "
 +
  pop cx        ; 1  "
 +
  mov ax,71h    ; 3  "
 +
  push ax        ; 1  "
 +
  call _INPORTB  ; 3  "
 +
  pop cx        ; 1  "
 +
  pop bp        ; 1  "
 +
  ret            ; 1  "
 +
_READCMOS endp  ; Summe:  26 byte
 +
 +
ziemlich umständlich oder ?
 +
 +
vergleichbare Prozedur für reines Assembler Programm :
 +
 +
READCMOS proc near ; Parameterübergabe in AL ; Rückgabewert in AL
 +
  out 70h,al    ; 2 byte
 +
  in al,71h      ; 2  "
 +
  ret            ; 1  "
 +
READCMOS endp    ; Summe: 5 byte
 +
 +
Die Code und Zeitersparnis ist deutlich zu erkennen.
 +
 +
Zum Thema UNIX ist zu bemerken, das ein Gerät nunmal keine Datei ist, also ein Linux/Windows Programmierer sich nicht zwangsweise mit Hardware- und BIOS-zugriff auskennt. (Ich habe - im Ernst - mal in einem Linux forum gelesen, dass einer nicht weis wofür die Befehle IN und OUT sind). Viel wichtiger ist es sich mit DOS auszukennen, denn da arbeitet man ständig mit BIOS und Hardwarezugriffen, und weis auch wie man zum Beispiel erkennt ob und was für Geräte angeschlossen sind. Und das ist genau dass, was die Klicki-Bunti-Objekti-Hochsprachi-Programmierer eben nicht können.