On Mon, 6 Jun 2022 12:52:07 +0200, heby wrote:
> On 06/06/2022 12:17, J.F wrote:
>>> Stosy w typowych systemach operacyjnych są śmiesznie małe. Tak około
>>> 1000x mniej niż dostepna pamięć i raczej mało kto narzeka.
>> Cos mi chodzi po glowie, ze na starych Unixach bylo 8kB.
>> Mozliwe do zmiany jakimis parametrami (ulimit?).
>
> Jak masz uprawnienia.
>
>> Teraz widze, ze linux ma cos kolo 2MB ... ale co zrobic, jak
>> zabraknie?
>
> Napisać lepszy kod. Przkroczenie 2MB/8MB na stosie jest oznaką bardzo
> źle napisanego kodu.
>
>>> Nie stanowią problemu, choć nie mogę wykluczyć, że bardzo źle napisany
>>> program może marudzić. Shit happens.
>> Widziales gdzies wytyczne dla programistow - jak dbac o rozmiar stosu?
>
> Wytyczne? To się ma we krwi ;)
>
> Jeśli rekurencja, to tylko ogonowa. Zwykłymi wywołaniami bez rekurencji
> bardzo trudno przekroczyć stos w normalnym programie.
>
> Naprawdę duże apliakcja, takie DUŻE DUŻE nie maja problemu z działaniem
> na stosie kilku MB. Są najzwyczajniej poprawnie napisane.
>
>>>> W dodatku Unix to system wielozadaniowy, wiec mamy wiele procesów,
>>>> kazdy z apetytem na pamiec. I z pożądaną wzajemną ochroną.
>>> To nie ma związku z segmentacją. Segmentacja to tylko dziadowski system
>>> przełączania banków pamięci z 8-bit maszyn, zaszyty w procesorze.
>> pojawila sie np 80286, a to juz 16-bit.
>
> Segmentacja miała za zadanie ułatwić widzialnosc większego obszaru RAMu
> dla procesora 8086, który tak naprawdę jest lekko odpicowanym 8-bit
> 8080. Jak że można by to było zrobić lepiej, niż za pomocą śmierdzocego
> workaroundu z segmentami? No jak?

Ale nie mowie o 8086, tylko o 80286. Tryb "protected".
Rozwineli skrzydla w segmentacji, i to juz byla konstrukcja 16-bit.
Ktore zreszta przestalo wystarczac, wiec na smietnik :-)

>>> Tak,
>>> troche przesadzam, ale prawdę mówiąc niewiele. Jak zerkniesz na to jakie
>>> machnizmy były popluarne na Z80 i 6502 do ogarniania pamięcu >64k to
>>> niebezpiecznie blisko koncepcji segmentacji wylądujesz.
>> Ale to bylo stronnicowanie, a nie segmentacja.
>> Cos, co dzisiaj chwalisz :-)
>
> Nie, segmentacja. Dodanie dodatkowego "offsetu adresu" do normalnych
> adresów.

Ale tam nie miales "offsetu adresu", tylko przełączanie stron pamieci.

Z uwagi na niedorozwoj MMU tylko zgrubne, np jedna wymiena strona
16KB, ale ciagle przelaczanie stron.

Jakiegos "offsetu adresu" mozna by sie dopatrzec w Keil C na 8051.

I moze cos bylo w 80251 - tego nie znam.


> Potem dorobiono do tego ideologię i workaroundy (że niby
> pozwala na pracę wielu maszyn wirtualnych, ochrania dostep, itp
> śmiesznosci). Pierwotnie jedyne co chcieli osiągnąc to przekroczyć 64kB
> bez zrywania z 8-bit.

Tak.
Ale tryb protected 286 dzialal inaczej - zawartosc rejestru
segmentowego nie byla sumowana do adresu jak 86, tylko stanowila
indeks po tablicy (deskryptorow) segmentow. Kazdy segment mial swoj
poczatek w pamieci, dlugosc, flagi protekcji.
Nie wiem, czy nawet jakiejs namiastki pamieci wirtualnej nie dalo sie
na tym zrobic.

> Co im się udało w prześmieszny sposób (A20).
> Reszta to paniczne szukanie jak to jeszcze bardziej popsuć.

Ale to chyba cos piszesz o trybie rzeczywistym.
Bo tryb protected nie byl stososowany z uwagi na niekompatybilnosc
z programami na MS-DOS.

A tryb protected 286 ... niby fajny, niby ma mozliwosci, ale segmenty
tylko 64KB, i setki problemow z tym zwiazane, jak danych jest wiecej
niz te 64KB.

>>> x86 zrobił to
>>> tylko "lepiej" czyli skrajnie skomplikował proste zagadnienie adresacji
>> Mial byc nastepcą 8080 :-)
>
> To był 8080 z doszytymi segmentami, z punktu widzenia programisty.
> Róznica taka, zę mój Atari 65XE przełączenie banków miał w hardware na
> płycie, a 8086 w procesorze. Ot, postęp i profesjonalizm.

No wlasnie - atari mialo ubogie stronnicowanie na plycie, wraz ze
zwiazanymi z tym klopotami, 86 mialo w miare wygodne ofsety w adresie.

286 to byla nowa jakosc ... tylko o 10 lat spozniona :-)

>> No ale widzisz - to -64. Znow hardware przegonil potrzeby i mozliwosci
>> :-)
> MC68000 nie potrzebuje segmentacji. Pojawił się na rynku chwile po 8086.

68k, podobnie jak 386 nie potrzebowal segmentacji w czasach, gdy
pamieci RAM mialy np 4MB. Czy nawet 128GB.
Czy nawet 3GB
Segmentacja mogla jednak pomoc na fragmentacje przestrzeni adresowej.

A potem pamieci bylo w komputerze pojawilo sie 4GB pamieci,
zaczal sie problem dla procesorow :-)

Zrobilismy procesory 64 bit i znow nie trzeba segmentacji :-)
I to raczej na długo :-)

> Z jakiejś przyczyny ludzie do dzisiaj dorabiają idiotyczne ideologie
> jaka ta segmentacja jest super i potrzebna do czegoś.
>
> Niewiarygodne. Czasami wcinam popkorn oglądając takie dysputy, to lepsze
> niż kabaret.

Jesli mowimy o 286/386, to miala pewne zalety.
Tylko 286 - za pozno, 386 - prawie niepotrzebne, a tez w praktyce - zc
czasem ograniczajace.

>>> Co zabawne, współdzielenie biblitek jest znacznie łatwiejsze w systemach
>>> bez ochrony pamieci (Amiga OS). I było powszechne w latach 80 w
>>> systemach bez MMU, co nie oznacza, że było rozsądne (fragmentacja była
>>> problemem).
>> A tu widzisz - segmentacja typu 286 by problem rozwiazala.
>
> Nie. Do prawidłowej pracy biblotek współdzielonych przy separacji
> procesów wymagana jest translacja adresów i to dość swobodnie, w różnych
> miejscach pamieci wirtualnej w różne miejsca pamieci fizycznej.
> Segmentacja nic to nie pomoże, a tylko przeszkadza.

Ale taka segmentacja
https://en.wikipedia.org/wiki/X86_memory_segmentatio
n#Protected_mode
https://en.wikipedia.org/wiki/Protected_mode#286

J.