Thema: Farcall vs. Interrupt

[GhostCoder]

Hi,

ich habe schon überall gesucht, aber nichts gefunden:
Was ist schneller, ein Farcall in einen anderen Selektor oder ein Interrupt? Alles ohne Wechsel der Privilegstufe...

Oder allgemein, was ist der schnellste Weg eine Funktion in einem anderen Selektor aufzurufen?

Gruß GhostCoder

[TeeJay]

Ein Farcall müsste schneller sein. Bei einem Int wird das FLAG-Register zusätzlich auf den Stack gepusht. Dies entfällt beim Farcall. Von daher sollte dieser "marginal" schneller sein.

Aber ob sich das letztendlich spürbar bemerkbar macht ist eine andere Sache.

[Roshl]

Kommt drauf an wie oft der Int/Farcall benutzt werden soll denke ich. Für Systemroutinen wird man um Int kaum herrumkommen. (von Callgates abgesehen)

[n3Ro]

Um Systemroutinen schneller zu bekommen benutzt man einfach SYSCALL / SYSRET, ist zig mal schneller.

[GhostCoder]

Danke für die Antworten,

bin jetzt aber auf den Gedanken gekommen, weder Segmente noch VM für jeden Prozess zu nutzen. Setze mal auf Geschwindigkeit, auch wenn jeder fehlerhafte Prozess dann das System zerschießen kann, war ja unter DOS nicht anders...

Gruß GhostCoder

[SSJ7Gohan]

Du brauchst ja auch garnicht für jeden Prozess Segmente, du brauchst 6 Segmente insgesammt, falls du Software Multitasking benutzt.
1. NULL Descriptor
2. Kernel Code
3. Kernel Data
4. Process Code
5. Process Data
6. TSS

Für Hardware Multitasking brauchst du natürlich mehr Descriptoren, für jeden Task halt einen mehr.

Dank Paging können die Prozesse ja nichmal die Addressen des anderen Programms addressieren, also brauchst du nicht mehr Segmente.

[DDR-RAM]

Für Hardware Multitasking brauchst du natürlich mehr Descriptoren, für jeden Task halt einen mehr.

nope, brauchen nicht ^^
man kann die descriptoren auch dynamisch laden, das heißt man braucht für software tasking mindestens 2.
Für weitere task gates braucht man dann mehr als 2 ^^

MfG
DDR-RAM

[GhostCoder]

Dank Paging können die Prozesse ja nichmal die Addressen des anderen Programms addressieren, also brauchst du nicht mehr Segmente.

Schon klar, aber mit geht es nur um Geschwindigkeit, also willl ich nen Wechsel von CR3 vermeiden, jetzt habe ich zwar keinen Speicherschutz mehr, aber darauf kann ich verzichten...
Und Segmente pushen/poppen beim Taskwechsel fällt auch weg...

Vielleicht baue ich später doch noch Segmentierung ein, aber erstmal geht es um andere Sachen...

Gruß GhostCoder

[SSJ7Gohan]

Das heißt, du lässt das Multitasking ganz weg?
Ich halte es nicht für sinnvoll, das System so auf Geschwindigkeit zu trimmen, für höchstens 2-5% mehr Geschwindigkeit hast du keinen Speicherschutz, kein Multitasking, keinen Virtullen Addressraum und alle Treiber und Dienste auf die ein Process zugreifen kann müssen in den Kernel kompiliert werden, da man ja nur einen Prozess gleichzeitig starten kann.

[Legend]

Du kannst auch ohne virtuelle Addressräume Multitasking machen. Du hättest das sogar auf nem 8086 machen können (Software Tasking natürlich nur, ohne verschiedene Ringe braucht das auch keine TSS). Aber wie schon von GhostCoder gesagt ohne hardwareseitigen Speicherschutz.

[GhostCoder]

Jo, Multitasking funktioniert natürlich noch.
Ich nutze auch Paging, aber halt nur für den ganzen Addressraum und nicht für jeden Prozess einen persönlichen.

Ich halte es nicht für sinnvoll, das System so auf Geschwindigkeit zu trimmen, für höchstens 2-5% mehr Geschwindigkeit hast du keinen Speicherschutz, kein ...

Klar kriegt man auf diese Weise kein "richtiges" markreifes OS hin, aber warum sollte ich?
Ich kann jetzt versuchen einen Linuxklon zu schreiben, würde aber natürlich dabei scheitern. Also suche ich mir eine Nische, in der ich mir ein Ziel setzen kann und Spass daran habe, etwas "neues", ungewöhnliches zu machen.

Außerdem glaube ich das ich damit mehr als 2-5% rausholen kann.

Gruß GhostCoder

[GhostCoder]

Noch was:

Ich sitz grad an meiner Linuxbox, und die Summe des gesamt benötigten VM Speichers aller Prozesse liegt grad mal bei rund 400mb, also selbst wenn ich jetzt noch Doom3 spiele, würde ein(!) Addressraum von 4GB locker reichen, und sogar noch viel mehr. Klar, auf nem Server kann das vielleicht knapp werden...

Also kann man sich doch die ganzen cr3 switches sparen, und stattdessen lieber mit Segmenten arbeiten...

Gruß

[SSJ7Gohan]

Naja, aber auf normaler Weise kompilierte Programme gehen davon aus, das sie einen virtuellen Addressraum haben. Wenn das Textsegment von zwei Programmen übereinander liegt, würden sie ja nicht richtig funktionieren. Deshalb _muss_ man eigentlich Paging einbauen, um Multitasking zu verwenden, da das ja mit Segmenten nicht möglich ist, oder?

[Svenska]

Du muesstest ein Binärformat basteln, in welches du beim Laden die Speicheradresse "einblendest". Dann muesste jedes Programm immer davon aus hinrechnen, um seine Labels etc zu finden. Da du die Programme nicht an eine feste Adresse lädst, sondern an eine jedesmal neu zu bestimmende, hast du also in jeder Anwendung Performanceverluste durch die ganzen Adressumrechnungen.
Ob das nun das Betriebssystem oder die Anwendung ist... ich bezweifle, dass du dadurch grosses Tempo rausholst.

Andererseits ist es ein interessanter Ansatz, der fuer Embeddedsysteme nuetzlich sein könnte - dort ist Speicherschutz nicht lebensnotwendig.

Svenska

[Golum]

hast du also in jeder Anwendung Performanceverluste durch die ganzen Adressumrechnungen.

Unter Linux und Windows hat man aufgrund der dynamischen Bibliotheken auch viele Adressumrechnungen so groß ist der Performanceverlust nicht.

Und wenn einmal alle Adressen richtiggestellt worden sind beeinflusst das die Geschwindigkeit des Programms garnicht mehr.

[n3Ro]

Man braucht eigentlich nur ein Executable-Format zu benutzen, welches Relocations unterstütz (z.B. ELF) und "linkt" dann einfach sein Programm erst direkt vor dem starten direkt an die richtige Speicheraddresse, oder man benutzt einfach PIC (Position Independent Code), was aber leichte Performanceeinbußen einbringt.
Zum Thema eine Nische finden: es gibt so gut wie kein Hobby OS für AMD64, das wär doch mal was. Dann ist man der OS - God und hat keine Konkurrenz.

[Svenska]

Dummerweise ist mein einziger AMD64-tauglicher PC eine bochs.exe
und wie es scheint, geht es einigen so - auch werden die 32-Bitter einem teilweise hinterhergeschmissen und viele schlagen zu. Da ich immer die alten PCs von meinem Vater kriege... werde ich noch bestimmt 5-8 Jahre auf 32 Bit rumkrepeln (sofern ich mir nicht selbst einen PC kaufe).

Mit der Performance... das kann sein. Die heutigen PCs sind eh zu schnell, als dass man das merken wuerde Aber du musst halt bei jedem Zugriff die Adresse entweder neu berechnen (oder aus dem Speicher auslesen). Wobei das natuerlich auch der Compiler erledigen kann (der aber erstmal geschrieben werden muss) und das jedesmal mit Asm per Hand machen (>JMP label:< wird zu >JMP $+55< *g*) ist auch schon ziemlich was.

Trotzdem finde ich den Ansatz sehr gut, wichtig ist er halt fuer Embeddedsysteme mit begrenzten Möglichkeiten, wo es auf Protecting auch nicht so ankommt. Wobei auch hier wieder das Problem kommt, dass selbst solche Teile extrem schnell sind...schneller als vor einigen Jahren noch, wo man auf Taktzyklen optimieren konnte. Bei ner 400 Mhz-CPU merkt man da nichts mehr... und ne PS ist auch nur ein Prozessor Typ 486/33...

Ist halt mal was anderes - und dafuer viel Erfolg und einen einfachen Kernel

Svenska

[Legend]

Also kann man sich doch die ganzen cr3 switches sparen, und stattdessen lieber mit Segmenten arbeiten...

Na ja, abgesehen davon das wohl auf jeden Fall komplizierter wird (zumindestens meiner Meinung nach), bringt die intensive Verwendung von Segmenten auch Performance-Nachteile an mancher Stelle, Stichwort Far-Call halt.
Evtl. lässt sich das heutzutage gut umgehen, seit dem es 4GB Segmente gibt, aber zur Zeit vom 80286 hättest du ein Problem gehabt!

[GhostCoder]

Hi,


@Svenska:
na klar gibt es ohne private Addressräume Probleme, aber daran arbeite ich ja im Moment.
Btw, danke für die positive Unterstützung

@n3Ro:
An PIC+ELF habe ich auch gedacht, wäre in gcc ja nicht mal ein Umstand (-fPIC oder so?). Muss ich mal schauen wie die Performanceeinbußen sind. die idee mit dem Linken find ich gut, Danke!

@Legend:
Klar bedeuten Segmente einen Performanceverlust, aber ein FARCALL ist immer noch schneller als ein Interrupt (Ohne Wechsel der Privilegstufe).

@SSJ7Gohan:
Ich weiß, aber ich will meinen Kernel ja auch nicht Binärkompatibel mit Linux halten. Natürlich lege ich keine 2 Codesegmente übereinander, man hat ja 4GB die frei zu verteilen. Btw, nein man brauch Paging nicht für Multitasking, es ist nur hilfreich! Denk doch mal daran, 2 Programme liegen an 2 unterschiedlichen Addressen(Meinetwegen 0x1000 und 0x2000), wenn ich jetzt bei jedem Interrupt den Stack änder und die Register poppe, was hat das mit Paging zu tun? Multitasking kann man auch auf einem Z80 laufen lassen, und für den is MMU nen Fremdwort

Gruß GhostCoder

[SSJ7Gohan]

Ja, mir ist das schon klar, das man ein Programm so linken kann, das die Addressen bei 0x1000 beginnen, ein anderes wo sie bei 0x2000 beginnen usw.
Aber dann kann man nicht mehrere Instanzen eines Programms gleichzeitig laufen lassen und alle Programme müssen auf einander abgestimmt sein.

An einem dynamischen Linken wärend der Laufzeit wirst du also kaum vorbeikommen.