Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: KtmnjjpfjsFvzG am 22. January 2013, 19:52
-
Hier (http://www.lowlevel.eu/wiki/Textausgabe) ist beim Cursor-Verschieben-Beispiel eine Funktion "outb" angegeben, die ich 1. nicht verstehe und die 2. nicht vorhanden ist...
Woher bekomme ich die? :)
mfg! :-P
-
So schaut das bei mir aus damit kannst du die IOPorts von deinem Prozessor ansteuern. Das inline ASM werde ich aber wahrscheinlich in der HAL "makrotisieren"
Cursor verschieben geht bei mir aber auch so nicht :-(.
#include<stdint.h>
#include<drv/io/ioport.h>
/* writes a byte into an I/O-Port */
void outb(uint16_t port, uint8_t data)
{
asm volatile ("outb %0, %1" : : "a" (data), "Nd" (port));
}
/* reads a Byte from an I/O-Port */
uint8_t inb(uint16_t port){
uint8_t result;
asm ("inb %1, %0" : "=a" (result) : "Nd" (port));
return result;
}
-
Okay erstmal eine andere Frage: Du kanns stdint benutzen? Gut! Das würde einige meiner Probleme lösen! Allerdings kommt bei mir "no include path in which to search for stdint.h" :?
-
Du kannst das auch vom beispielkernel_repo src code "inspirieren lassen"(http://git.tyndur.org/?p=tutorial.git;a=summary)
stdint.h:
#ifndef STDINT_H
#define STDINT_H
typedef unsigned long long uint64_t;
typedef unsigned int uint32_t;
typedef unsigned short uint16_t;
typedef unsigned char uint8_t;
typedef signed long long int64_t;
typedef signed int int32_t;
typedef signed short int16_t;
typedef signed char int8_t;
// size
typedef unsigned int size_t;
// Signed pointer-sized integer
typedef long intptr_t;
// Unsigned pointer-sized integer
typedef unsigned long uintptr_t;
#endif
-
Achso nagut, dann erstelle ich mir einfach eine stdint.h und schreibe das da rein^^ :D
Mit outb beschäftige ich mich dann später, jetzt auf jeden Fall erstmal danke, hat mir echt geholfen! :) :)
-
Die outb-Funktion kannst du als "inline" markieren, dann sparst du dir Call/Return und die Parameterübergabe. Das mit der stdint.h ist der Unterschied zwischen "-ffreestanding" und "-noinclude"; im ersten Fall darfst du die betriebssystem-unabhängigen, vom Compiler bereitgestellten Header benutzen.
-
inline funktioniert übrigens nur, wenn du die Funktion in den Header verschiebst (und dann muss gleich static inline draus werden).
-
Inline Deklaration ist das nicht auch iwie performanter in der Ausführung aber erzeugt mehr Opcode ähnlich wie bei Makros??
-
Ja. Nur, dass im Fall von in/out wohl eher weniger Opcodes erzeugt werden. :wink:
push ARG1
push ARG2
call outb
add esp, 8vs.
mov al, ARG1
outb ARG2, al
-
Achso Ich habe aber auch gesehen dass memset im BeispielKernel als inline deklariert wurde bei so einer größeren funktion die auch aus mehreren hundert src files aufgerufen wird ist das vllt nicht so sinnvoll.
-
Hallo,
also "static inline" hat bei mir auch in C-Dateien funktioniert. Ich schreibe grundsätzlich keinen Code in Header - oder gibt es Gründe dafür?
Inline-Funktionen sind dann nützlich, wenn der Overhead von CALL/RET gegenüber der eigentlichen Ausführung wichtig wird und sonst nichts dagegen spricht. Der Compiler darf übrigens selbst entscheiden, ob er eine als "static" markierte Funktion nun inlined oder nicht - egal ob das inline nun da steht oder nicht.
Gruß,
Svenska
-
also "static inline" hat bei mir auch in C-Dateien funktioniert.
Aber das ist dann keine C-Datei, die per #include in eine andere C-Datei eingebunden wird, oder?
Ich schreibe grundsätzlich keinen Code in Header - oder gibt es Gründe dafür?
Ein gutes Beispiel für einen Grund Inline-Funktionen in Header zu tun, sind inb/outb-Funktionen: Mehrere Übersetzungseinheiten (z.B. Timerfunktionen, Tastaturtreiber, PIC, CMOS, ...) können diese Funktionen verwenden und um Code-Duplikation zu vermeiden wird die Funktion in dem gemeinsam genutzten Header definiert.
-
also "static inline" hat bei mir auch in C-Dateien funktioniert.
Aber das ist dann keine C-Datei, die per #include in eine andere C-Datei eingebunden wird, oder?
Ist es nicht. Gibt es sonst noch gute Gründe, Code in Headern zu haben (also abgesehen von "static inline")?
-
nicht in Form von Funktionen. Weil die würdest du dann ja mehrfach haben, und Probleme beim Linken bekommen.
wenn du aber so Makros wie FOR_EACH_foobar(LIST) haben willst, dann könnten die auch in Headern Sinn machen.
-
Ist es nicht. Gibt es sonst noch gute Gründe, Code in Headern zu haben (also abgesehen von "static inline")?
Mir fallen auch keine anderen Sachen mehr ein, außer die von MNemo genannten.