🚀 go-pugleaf

Michał napisał(a):
> teraz musze napisac prosta aplikacje, jednak z kilkoma watkami -
> porozumiewajacymi sie przez wspolna paniec danych. Niestety, moj
> program ma NIE chodzic w srodowisku Win32, tylko DOSopodobnym, 
> czy ktos z Was zatem moglby mnie pokierowac do materialow ktore by mi
> wyjasnily jak sie robi wielowatkowasc w ASMie, bez uzycia WinAPI? 
> WinAPI jakos to robi, to moze i zwykly czlowiek moze?

Zaalokuj osobne stosy dla każdego nowego wątku i próbuj z setjmp/longjmp.

Michał napisał(a):
> hej, 
> 
> programuje troche w asmie i HLA, ale - jak do tej pory - byly to
> aplikacyjki jednowatkowe, po 10-20 kb kazda, ale spelnialy swoje
> zadanie. 
> 
> teraz musze napisac prosta aplikacje, jednak z kilkoma watkami -
> porozumiewajacymi sie przez wspolna paniec danych. Niestety, moj
> program ma NIE chodzic w srodowisku Win32, tylko DOSopodobnym, 
> czy ktos z Was zatem moglby mnie pokierowac do materialow ktore by mi
> wyjasnily jak sie robi wielowatkowasc w ASMie, bez uzycia WinAPI? 
> WinAPI jakos to robi, to moze i zwykly czlowiek moze?

 Możesz przejąć przerwanie zegara i za każdym tyknięciem (18 razy na
sekundę) zachowywać rejestry bieżącego procesu i przełączać się do
innego zadania, przywracając rejestry tamtego, łącznie ze stosem.
Przyda się zmienna mówiąca, który proces się skończył lub zaczyna i
obszar pamięci, który zdoła zmieścić wszystkie rejestry każdego procesu.
 Wspólny obszar danych zmusza też do implementacji jakiegoś sposobu
informowania o dostępności tego obszaru (flaga globalna, mutex,
semafor). Wszystko jest w AoA.

-- 
Pozdrawiam, Bogdan                                  (Linux i FreeDOS)
Kurs assemblera x86 (DOS i Linuks): http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
Forum o programowaniu:                     http://programista.xorg.pl

> Możesz przejąć przerwanie zegara i za każdym tyknięciem (18 razy na
> sekundę) zachowywać rejestry bieżącego procesu i przełączać się do
> innego zadania, przywracając rejestry tamtego, łącznie ze stosem.

Nawet nie trzeba ręcznie zachowywać wszystkich rejestrów, wystarczy skok do 
furtki zadania... o ile mamy odpowiedni poziom uprawnień do grzebania przy 
trybie chronionym. (nieoceniona lektura to dokumentacja architektury AMD i 
Intela... pdf-y są do ściągnięcia)

Jednak przełączanie zadań tylko co 1/18 sekundy to za mało. Robiłem niedawno 
coś podobnego, system był przełączany na następne zadanie przy wielu 
okazjach, np. podczas czekania na klawisz:

call readkey

a tam coś tego typu:

petla:
  call next_task
  call czy_nacisnieto_klawisz
  jz petla
ret

gdzie next_task przełącza procesor na następne zadanie. po iluś 
przełączeniach wrócimy z powrotem do tego, i next_task się zakończy jakby 
nigdy nic.

W ten sposób zadanie nic nie robiące a tylko czekające na klawisz nie 
zajmuje czasu procesora.


-- 
Azarien

Wiktor S. napisał(a):
>> Możesz przejąć przerwanie zegara i za każdym tyknięciem (18 razy na
>> sekundę) zachowywać rejestry bieżącego procesu i przełączać się do
>> innego zadania, przywracając rejestry tamtego, łącznie ze stosem.
> 
> Nawet nie trzeba ręcznie zachowywać wszystkich rejestrów, wystarczy skok
> do furtki zadania... o ile mamy odpowiedni poziom uprawnień do grzebania
> przy trybie chronionym. (nieoceniona lektura to dokumentacja
> architektury AMD i Intela... pdf-y są do ściągnięcia)

 Można i tak, ale program ma działać w systemie "DOSopodobnym", co
oznacza, że PM trzeba byłoby ustawić samemu od nowa i uważać na
extendery, które same chyba też włączają tryb chroniony (emm386? himem?).

> Jednak przełączanie zadań tylko co 1/18 sekundy to za mało. Robiłem
> niedawno coś podobnego, system był przełączany na następne zadanie przy
> wielu okazjach, np. podczas czekania na klawisz:
[...]
 Niezły pomysł. Ja takich rzeczy nie robiłem, więc podpowiedziałem
sposób, który pierwszy nasunął mi się na myśl.

-- 
Pozdrawiam, Bogdan                                  (Linux i FreeDOS)
Kurs assemblera x86 (DOS i Linuks): http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
Forum o programowaniu:                     http://programista.xorg.pl

>> Nawet nie trzeba ręcznie zachowywać wszystkich rejestrów, wystarczy
>> skok do furtki zadania... o ile mamy odpowiedni poziom uprawnień do
>> grzebania przy trybie chronionym. (nieoceniona lektura to
>> dokumentacja architektury AMD i Intela... pdf-y są do ściągnięcia)
>
> Można i tak, ale program ma działać w systemie "DOSopodobnym", co
> oznacza, że PM trzeba byłoby ustawić samemu od nowa i uważać na
> extendery, które same chyba też włączają tryb chroniony (emm386?
> himem?).

Oznacza to napisanie własnego mini-systemu operacyjnego, tylko że kolega 
Michał nie powiedział, co to jest za środowisko DOSopodobne. DOS czy tylko 
"podobne"? To może mieć duże znaczenie.

>> Jednak przełączanie zadań tylko co 1/18 sekundy to za mało. Robiłem
>> niedawno coś podobnego, system był przełączany na następne zadanie
>> przy wielu okazjach, np. podczas czekania na klawisz:

> Niezły pomysł. Ja takich rzeczy nie robiłem, więc podpowiedziałem
> sposób, który pierwszy nasunął mi się na myśl.

Jeśli przełączasz _tylko_ na zegarze, każdy wątek zajmie tyle samo czasu 
procesora. Jeśli są cztery wątki, to przy zupełnym braku priorytetów każdy 
dostanie dokładnie 1/4 czasu, niezależnie jakie by operacje wykonywał. Już 
przy kilku wątkach taki system zacznie się strasznie mulić.

Najłatwiej na pewno będzie znaleźć jakiś darmowy, mały system operacyjny 
(albo nawet maksymalnie okroić Linuksa) i na niego przenieść program.

-- 
Azarien

On Sun, 5 Mar 2006 11:35:03 +0100, "Wiktor S." <wswiktorSP@Mpoczta.fm>
wrote:

>Oznacza to napisanie własnego mini-systemu operacyjnego, tylko że kolega 
>Michał nie powiedział, co to jest za środowisko DOSopodobne. DOS czy tylko 
>"podobne"? To może mieć duże znaczenie.

Dziekuje wszystkim za pomysly, na pewno z nich skorzystam. System w
zasadzie moge wybrac sam, choc profgram ma dzialac nawet na 386, i byl
wolny (w sensie free). Poniewaz nie programowalem w Linuxie zbyt
wiele, zwlaszcza w ASMie, wiec sklaniam sie ku FreeDOS'owi, gdyz DOSa
i jego przerwania (zwlaszcza 21h :) ) dosc dobrze znam. 

AoA mam nawet wydrukowane, choc przyznam ze nie czytalem calego
jeszcze - to dosc skomplikowana lektura. Ale obiecuje ze sie poprawie.

Program bedzie obliczeniowy, wraz z prezentacja wynikow obliczen
graficznie (zwykla VGA, ewentualnie jakis tryb VESA), i do tego sa mi
potrzebne watki - jeden bedzie liczyc, drugi wyswietlac, a trzeci
"interaktowac" z uzytkownikiem, gdyz liczenie i wyswietlanie maja byc
niezalezne od wprowadzania nowych danych. 

Jeszcze raz dziekuje wszystkim za wskazowki. 

Michal

Użytkownik "Michał" napisał w wiadomości...
On Sun, 5 Mar 2006 11:35:03 +0100, "Wiktor S."
wrote:

Program bedzie obliczeniowy, wraz z prezentacja wynikow obliczen
graficznie (zwykla VGA, ewentualnie jakis tryb VESA), i do tego sa mi
potrzebne watki - jeden bedzie liczyc, drugi wyswietlac, a trzeci
"interaktowac" z uzytkownikiem, gdyz liczenie i wyswietlanie maja byc
niezalezne od wprowadzania nowych danych.

A slyszales o czyms takim jak TSR?
Jezeli bedzie to w DOS'ie to moznaby polaczyc obliczenia
z wyswietlaniem i przerywac ich dzialanie na czas wprowadzania
danych. Nie jest to o co sie pytales, ale bedzie na pewno prostsze
od implementacji watkow, a efekt ten sam.

-- 
Pozdrawiam
Lopez

>> Oznacza to napisanie własnego mini-systemu operacyjnego, tylko że
>> kolega Michał nie powiedział, co to jest za środowisko DOSopodobne.
>> DOS czy tylko "podobne"? To może mieć duże znaczenie.

> Dziekuje wszystkim za pomysly, na pewno z nich skorzystam. System w
> zasadzie moge wybrac sam, choc profgram ma dzialac nawet na 386, i byl
> wolny (w sensie free). Poniewaz nie programowalem w Linuxie zbyt
> wiele, zwlaszcza w ASMie, wiec sklaniam sie ku FreeDOS'owi, gdyz DOSa
> i jego przerwania (zwlaszcza 21h :) ) dosc dobrze znam.

No to pora na uczenie się linuksowego 80h :-)

> Program bedzie obliczeniowy, wraz z prezentacja wynikow obliczen
> graficznie (zwykla VGA, ewentualnie jakis tryb VESA), i do tego sa mi
> potrzebne watki - jeden bedzie liczyc, drugi wyswietlac, a trzeci
> "interaktowac" z uzytkownikiem, gdyz liczenie i wyswietlanie maja byc
> niezalezne od wprowadzania nowych danych.

W takim razie można zrobić przełączanie na zegarze (niech będzie nawet 
"software'owe", czyli ręcznie): na zegarze przełączamy do kolejnego zadania 
(czyli trzy przełączają się w kółko).

Wątek interfejsu powinien sprawdzać, czy np. naciśnięto klawisz - jeśli nie, 
od razu niech się przełączy do następnego zadania.

Wątek wyświetlający niech wyświetli co tam ma, jak skończy - następne 
zadanie.

Wątek liczący sam z siebie nie będzie oddawał procesora, zostanie 
wywłaszczony dopiero na zegarze.

W ten sposób liczenie dostaje prawie cały czas procesora, a jednocześnie 18 
razy na sekundę będzie sprawdzane, czy użytkownik czegoś nie nacisnął, a 
ekran zostanie odświeżony (można też zrobić rysowanie np. co sekundę, jeśli 
tyle to za często).

Co do samego przełączania...

załóżmy, że jesteśmy w przerwaniu. Trzeba by zapisać wszystkie rejestry i 
flagi (najlepiej 32-bitowe, nawet w trybie rzeczywistym) do struktury 
bieżącego zadania. CS:(E)IP pobierz z adresu powrotu z przerwania. Wczytaj 
teraz rejestry ze struktury nowego zadania, zamieszaj na stosie (stosy też 
oddzielne) aby powrót był do nowego zadania, i zrób IRET.

-- 
Azarien