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?

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

>> 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 ale widzisz - to -64. Znow hardware przegonil potrzeby i mozliwosci
> :-)

MC68000 nie potrzebuje segmentacji. Pojawił się na rynku chwile po 8086.

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.

>> 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.