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.
: Diese C-vs.-Assembler-Diskussion gab es mehr als einmal und Assembler hat immer den kürzeren gezogen (weil zeitaufwendig und fehleranfällig). Wenn du ernsthaft daran interessiert bist, such dir im Forum die passenden Threads raus und lies sie. Wenn nicht, troll bitte woanders weiter. Dein Beispiel habe ich mal ausprobiert, siehe unten... --[[Benutzer:Taljeth|Taljeth]] 11:54, 20. Apr. 2011 (CEST)
kwolf@dhcp-5-188:/tmp/c$ cat cmos.c
static inline void outportb(short port, char value)
{
asm volatile("outb %0, %1" : : "a" (value), "Nd" (port));
}
static inline char inportb(short port)
{
char value;
asm volatile("inb %1, %0" : "=a" (value) : "Nd" (port));
return value;
}
unsigned char readCMOS (unsigned char a)
{
outportb(0x70,a);
return inportb(0x71);
}
kwolf@dhcp-5-188:/tmp/c$ gcc -O2 -c cmos.c
kwolf@dhcp-5-188:/tmp/c$ objdump -d cmos.o
cmos.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 :
0: 89 f8 mov %edi,%eax
2: e6 70 out %al,$0x70
4: e4 71 in $0x71,%al
6: c3 retq
:''Nächster Beitrag:'' Ich weiß nicht, wieso ich antworte. Vermutlich bin ich sehr anfällig für Flamewars. Vielleicht möchte ich auch nur ein paar Sachen klarstellen, falls irgendein unglücklicher Anfänger das hier zufälligerweise liest und für bare Münze nimmt. Hast du den C-Code mal kompiliert? Vermutlich nicht. Ich schon. Leider hat taljeth das auch gemacht. Also lasse ich die erste Hälfte von meinem Beitrag einfach mal weg. Hinzuzufügen wäre noch, dass man bei neueren GCCs ja auch -flto benutzen kann, dann wird die Funktion readCMOS sogar dann direkt eingebunden, wenn sie sich in einer anderen Datei befindet. Aus
int _start(void)
{
return readCMOS(42);
}
:wird dann
00000000 <_start>:
_start():
0000000: b8 2a 00 00 00 mov eax,0x2a
0000005: e6 70 out 0x70,al
0000007: e4 71 in al,0x71
0000009: 0f b6 c0 movzx eax,al
000000c: c3 ret
:Ich sehe da rein gar keinen Geschwindigkeitsnachteil zu deinem handoptimierten Assembler. Im Gegenteil, der gcc spart sich sogar den Funktionsaufruf und macht alles über Register.
:Zu dem OS-Kommentar sag ich einfach mal nichts, das ist wirklich Geschmackssache. Und wenn vielleicht irgendwann alle Rechner mit ARM laufen, braucht man IN und OUT ja sowieso nicht mehr (braucht man bei moderner Hardware außerdem überhaupt kaum noch, vielleicht mal zum Initialisieren, aber die ganzen Datenstrukturen liegen im Speicher und werden mit PCI-DMA abgearbeitet). —[[Benutzer:XanClic|Clici McXan]] 12:10, 20. Apr. 2011 (CEST)