🚀 go-pugleaf

onegdaj ‟TheVoid” rzecze:
> Czy zdarzały się dawniej 16-bitowe systemy operacyjne działające w
> trybie rzeczywistym, które miały zaimplementowany (nawet najprostszy)
> algorytm szeregowania zapewniający wielozadaniowość? Jeśli tak, to
> proszę o wymienienie nazwy choćby jednego. Jeśli nie, to proszę o
> podanie przyczyny, z powodu której taki OS nie powstał lub nie mógł
> powstać (np. 1 MB pamięci nie wystarczyło na realizację takiego pomysłu
> lub brakowało wsparcia ze strony procesora w postaci odpowiednich
> instrukcji).
    nie  znam  historii, ale  istniały rozszerzenia —chyba dzisiaj można
by  je  nazwać ‚bibliotecznymi’— ‟dosa”, a pominąwszy  to co najbardziej
reklamowane, gdy  historia  zanika, to  nie  wiem, czy ‟uniksopodobne”
;-) były pisane na początku do tego trybu.
    ale  tzw. ‘schedulera’ nie nazwałbym planistą, bo nie każdy ‘schedu-
ler’ mógłby  być  nazwany  planistą, a co najwyżej ‛zmieniarką’ (kojarzy
się ze śmieciarką, ale ta ostatnia nazwa potocznie jest używana w infor-
matyce ;-) ).   planista  to  ktoś  kto  układa  plan  czegoś  naprzód,
a nie tylko podejmuje decyzje na bieżąco.
-- 
 qo   |)      CPL: cs[0..1] (ss[0..1]) p lvl of curr code!
    _x/ ,     RPL: seg_sel[0..1] privilege lvl of seg_sel!
    |    ng  __ -- __ -- __ -- __ -- __ -- __ -- __ -x86-,
,__ -- __ -- DPL: 2._word_of_seg_desc[13..14]:`f seg_desc ,

> Jeśli nie, to proszę o podanie przyczyny, z powodu której taki OS nie
> powstał lub nie mógł powstać (np. 1 MB pamięci nie wystarczyło na
> realizację takiego pomysłu lub brakowało wsparcia ze strony procesora
> w postaci odpowiednich instrukcji).

Nie musi być żadnych "odpowiednich instrukcji". Co prawda, takie są w 16- i 
32-bitowym trybie chronionym, ale w praktyce dzisiejsze systemy operacyjne z 
nich nie korzystają. Z tego powodu z architektury x86-64 nawet USUNIĘTO 
sprzętową obsługę wielozadaniowości.

-- 
Azarien

> Nie musi być żadnych "odpowiednich instrukcji". Co prawda, takie są w 16- i
> 32-bitowym trybie chronionym, ale w praktyce dzisiejsze systemy operacyjne z
> nich nie korzystają. Z tego powodu z architektury x86-64 nawet USUNIĘTO
> sprzętową obsługę wielozadaniowości.
>
> --
> Azarien

Zatem wnioskuję, że jest możliwe napisanie OS w trybie rzeczywistym,
który miałby prostą obsługę wielozadaniowości. Domyślam się, że w
takim wypadku wystarczy skorzystać z przewania zagara i robić
software'owe context/task switch'e.

TheVoid pisze:
> 
> Zatem wnioskuję, że jest możliwe napisanie OS w trybie rzeczywistym,
> który miałby prostą obsługę wielozadaniowości. Domyślam się, że w
> takim wypadku wystarczy skorzystać z przewania zagara i robić
> software'owe context/task switch'e.
TSR pod dosem tak działały - pisałeś position-independent code ładowałeś 
wskaźnik pod przerwanie zegarowe i już - wszystkie TSR'y uruchamiały się 
w fifo co takt.

"Prawdziwe" niezależne zadania da się uzyskać dopiero gdy procesor 
oferuje tryb chroniony. Bez tego ktoś może nadpisać wektor przerwań i po 
wielozadaniowości.

-- 
Pozdrawiam
Michoo

> "Prawdziwe" niezależne zadania da się uzyskać dopiero gdy procesor
> oferuje tryb chroniony. Bez tego ktoś może nadpisać wektor przerwań i
> po wielozadaniowości.

Wiesz, w 32-bitowym Windows, jak się bardzo uprzesz, też możesz nadpisać 
wszystko z tablica GDT włącznie.


-- 
Azarien

"Wiktor S." <wswiktor&poczta,fm@no.spam> wrote:

> > "Prawdziwe" niezależne zadania da się uzyskać dopiero gdy procesor
> > oferuje tryb chroniony. Bez tego ktoś może nadpisać wektor przerwań i
> > po wielozadaniowości.
> 
> Wiesz, w 32-bitowym Windows, jak się bardzo uprzesz, też możesz nadpisać 
> wszystko z tablica GDT włącznie.

Ale nie zrobisz tego przypadkiem i z poziomu zwykłej aplikacji.

w.

> Jak ktoś się uprze to często i tak może coś zrobić. A na procesory bez
> żadnego trybu chronionego jak najbardziej były tworzone systemy
> wielozadaniowe i to z wydziedziczaniem -- choćby Minix (na PCty) albo
> (starszy) Amiga OS.

Dzięki.
Minix będzie zatem obiektem moich badań.

Jescze pytanko.
Czy ktokolwiek z Was, kto używał Minixa uważa ten system za wolny (w
sensie prędkości)?

Michoo wrote:
> TheVoid pisze:
>>
>> Zatem wnioskuję, że jest możliwe napisanie OS w trybie rzeczywistym,
>> który miałby prostą obsługę wielozadaniowości. Domyślam się, że w
>> takim wypadku wystarczy skorzystać z przewania zagara i robić
>> software'owe context/task switch'e.
> TSR pod dosem tak działały - pisałeś position-independent code ładowałeś 
> wskaźnik pod przerwanie zegarowe i już - wszystkie TSR'y uruchamiały się 
> w fifo co takt.
> 
> "Prawdziwe" niezależne zadania da się uzyskać dopiero gdy procesor 
> oferuje tryb chroniony. Bez tego ktoś może nadpisać wektor przerwań i po 
> wielozadaniowości.

Jak ktoś się uprze to często i tak może coś zrobić. A na procesory bez 
żadnego trybu chronionego jak najbardziej były tworzone systemy 
wielozadaniowe i to z wydziedziczaniem -- choćby Minix (na PCty) albo 
(starszy) Amiga OS.

Bez wydziedziczania (kooperatywny multitasking) to w trybie rzeczywistym 
choćby Windows 3.0 działały.

\SK
-- 
"Never underestimate the power of human stupidity" -- L. Lang
-- 
http://www.tajga.org -- (some photos from my travels)

Sebastian Kaliszewski wrote:

> Jak ktoś się uprze to często i tak może coś zrobić. A na procesory bez 
> żadnego trybu chronionego jak najbardziej były tworzone systemy 
> wielozadaniowe i to z wydziedziczaniem -- choćby Minix (na PCty) albo 
> (starszy) Amiga OS.

Jak i chyba większość starszych komórek. :-)

    Pozdrawiam
    Piotr Wyderski

Wiktor S. wrote:

> Wiesz, w 32-bitowym Windows, jak się bardzo uprzesz, też możesz nadpisać 
> wszystko z tablica GDT włącznie.

To było możliwe tylko w serii 9x.

    Pozdrawiam
    Piotr Wyderski

>> Wiesz, w 32-bitowym Windows, jak się bardzo uprzesz, też możesz
>> nadpisać wszystko z tablica GDT włącznie.
>
> To było możliwe tylko w serii 9x.

Nie?
Sterowniki trybu jądra działają w ring 0.


-- 
Azarien

TheVoid <lasmar@o2.pl> wrote:
: Witam.
: Czy zdarzały się dawniej 16-bitowe systemy operacyjne działające w
: trybie rzeczywistym, które miały zaimplementowany (nawet najprostszy)
: algorytm szeregowania zapewniający wielozadaniowość?
: Jeśli tak, to proszę o wymienienie nazwy choćby jednego.
: Jeśli nie, to proszę o podanie przyczyny, z powodu której taki OS nie
: powstał lub nie mógł powstać (np. 1 MB pamięci nie wystarczyło na
: realizację takiego pomysłu lub brakowało wsparcia ze strony procesora
: w postaci odpowiednich instrukcji).

Lata 90-te XX w. Multi-T. Pelna wielozadaniowosc - napisany w Australii.
Uzywany w Polsce, bardzo jak na te czasy ciekawa "konstrukcja".

Pozdrawiam
j.Karas

TheVoid pisze:
> Witam.
> Czy zdarzały się dawniej 16-bitowe systemy operacyjne działające w
> trybie rzeczywistym, które miały zaimplementowany (nawet najprostszy)
> algorytm szeregowania zapewniający wielozadaniowość?
> Jeśli tak, to proszę o wymienienie nazwy choćby jednego.
> Jeśli nie, to proszę o podanie przyczyny, z powodu której taki OS nie
> powstał lub nie mógł powstać (np. 1 MB pamięci nie wystarczyło na
> realizację takiego pomysłu lub brakowało wsparcia ze strony procesora
> w postaci odpowiednich instrukcji).
> 
> Pozdrawiam.
Podstawowa przyczyna,dla której taki system nie powstał: program 
działający w Realmode mógłby bardzo łatwo (nawet wbrew intencji autora) 
sparaliżować działanie planisty, np. blokując przerwania (CLI), 
mieszając po ekranie itd. A skoro program mogł zmonopolizować 
zarządzanie komputerem, to lepiej było pozwolić mu zrobić co chce, bez 
wywłaszczania sterowania i właśnie dlatego wymyślono wielozadaniowość 
kooperatywną.

On 13 Mar, 17:04, Andrzej Grażyński <grazy...@petex.com.pl> wrote:
> Podstawowa przyczyna,dla której taki system nie powstał: program
> działający w Realmode mógłby bardzo łatwo (nawet wbrew intencji autora)
> sparaliżować działanie planisty, np. blokując przerwania (CLI),
> mieszając po ekranie itd. A skoro program mogł zmonopolizować
> zarządzanie komputerem, to lepiej było pozwolić mu zrobić co chce, bez
> wywłaszczania sterowania i właśnie dlatego wymyślono wielozadaniowość
> kooperatywną.

Można by wtedy stworzyć kod, który przejąłby przerwanie INT 3, włączył
tryb pracy TRAP, czyli krokowy i analizował każdą następną instrukcję,
którą chce wykonać program (czywiście z pewnymi wyjątkami).
Prawdopodobnie wydajność takiego systemu byłaby totalnie niska, bo na
każdą jedną instrukcję programu mogłoby przypadać dziesiątki lub setki
instrukcji weryfikujących jej poprawność, ale mógłby to być całkiem
bezpieczny system - taki Master Control Program :D