NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Jakie materiały edukacyjne polecacie do projektowania płytek PCB pod układy SoC?
Goto page Previous 1, 2, 3, 4, 5
J.F
Guest
Guest
Mon Jun 06, 2022 10:17 am
On Sat, 4 Jun 2022 15:41:58 +0200, heby wrote:
Quote:
On 02/06/2022 14:28, J.F wrote:
A po co te segmenty i w czym są lepsze w porównaiu gdy proces ma
najzwyczajniej pamięc RAM dla siebie, jak chce?
Sprawa jest taka, ze program unixowy ma swój kod, powiedzmy ze stały,
ma dane w pamieci, ktorych ilosc moze rosnac i ma stos, ktory tez moze
rosnąc.
Stosy w typowych systemach operacyjnych są śmiesznie małe. Tak około
1000x mniej niż dostepna pamięć i raczej mało kto narzeka.
A po co te segmenty i w czym są lepsze w porównaiu gdy proces ma
najzwyczajniej pamięc RAM dla siebie, jak chce?
Sprawa jest taka, ze program unixowy ma swój kod, powiedzmy ze stały,
ma dane w pamieci, ktorych ilosc moze rosnac i ma stos, ktory tez moze
rosnąc.
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?).
Teraz widze, ze linux ma cos kolo 2MB ... ale co zrobic, jak
zabraknie?
Quote:
I te dwa rosnące obszary stanowią problem, bo trzeba je jakos umiescic
w pamieci.
Nie stanowią problemu, choć nie mogę wykluczyć, że bardzo źle napisany
program może marudzić. Shit happens.
w pamieci.
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?
Quote:
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.
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.
Quote:
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.
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 :-)
Quote:
x86 zrobił to
tylko "lepiej" czyli skrajnie skomplikował proste zagadnienie adresacji
tylko "lepiej" czyli skrajnie skomplikował proste zagadnienie adresacji
Mial byc nastepcą 8080 :-)
Quote:
pamięci a potem dodawał w kolejnych wersjach procesorów coraz to nowsze
"usprawnienia w odpowiedzi na potrzeby rynku" które zakończyły się tym,
że obecnie z tego nikt nie korzysta, bo to guano, zaprojaktowanie
skrajnie bezmyślnie i psute iteracyjnie przez dziesięciolecia.
"usprawnienia w odpowiedzi na potrzeby rynku" które zakończyły się tym,
że obecnie z tego nikt nie korzysta, bo to guano, zaprojaktowanie
skrajnie bezmyślnie i psute iteracyjnie przez dziesięciolecia.
Nie do konca bym tak to nazwal, ale jakos ta wyszlo.
286 byl przestarzaly od poczatku, w 386 segmentacja w zasadzie
niepotrzebna.
Quote:
https://en.wikipedia.org/wiki/Memory_segmentation
[...]In a x86-64 architecture it is considered legacy and most
x86-64-based modern system software don't use memory segmentation.
Instead they handle programs and their data by utilizing memory-paging
which also serves as a way of memory protection.[...]
Czyli wyszło jak wykle, u Intela.
[...]In a x86-64 architecture it is considered legacy and most
x86-64-based modern system software don't use memory segmentation.
Instead they handle programs and their data by utilizing memory-paging
which also serves as a way of memory protection.[...]
Czyli wyszło jak wykle, u Intela.
No ale widzisz - to -64. Znow hardware przegonil potrzeby i mozliwosci
:-)
Quote:
Nowsze programy ładują jeszcze dynamicznie biblioteki, wiec trzeba
wiecej nowego miejsca.
Bibliteki shared sa zazwyczaj kompilowane z kodem position independent
(sprawdzić, czy to nie zabawkowy Windows) i znowu, to nie ma związu z
segmentacją. Procesory bez segmentacji też ładuja te bibliteki w trybie
współdzielenia i też je dzielą. x86 się do tego nie nadaje z powodu
żałosnych problemów z kodem PI, ale już AMD64 tak.
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).
wiecej nowego miejsca.
Bibliteki shared sa zazwyczaj kompilowane z kodem position independent
(sprawdzić, czy to nie zabawkowy Windows) i znowu, to nie ma związu z
segmentacją. Procesory bez segmentacji też ładuja te bibliteki w trybie
współdzielenia i też je dzielą. x86 się do tego nie nadaje z powodu
żałosnych problemów z kodem PI, ale już AMD64 tak.
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.
J.
J.F
Guest
Guest
Mon Jun 06, 2022 10:22 am
On Wed, 1 Jun 2022 07:17:33 +0200, heby wrote:
Quote:
On 01/06/2022 07:03, J.F wrote:
Nie. Jesli masz dużo ramu, to po co coś gdzieś mapować. Masa OSów
działała bez tego.
Chocby dlatego, ze procesy maja te same adresy dla roznych pamieci.
forka zrobisz i co?
Masa OSów nie ma forka
Zerknij choćby na eCos.
Nie. Jesli masz dużo ramu, to po co coś gdzieś mapować. Masa OSów
działała bez tego.
Chocby dlatego, ze procesy maja te same adresy dla roznych pamieci.
forka zrobisz i co?
Masa OSów nie ma forka
Zerknij choćby na eCos.
Ale w Unixie to podstawa :-)
Quote:
, protekcje
Jeśli ma być "bezpieczny". Ale nie musi.
Wielozadaniowy to w zasadzie musi :-)
Mało który *mały* system embedded jest w ogóle preemptive. Za to pełno
cooperative/event.
Ogólnie to nie tak, że poważne rzeczy da się robić tylko na poważnych
systemach z grep i apt-get. Małe kontrolery, nie obciązone masą
skomplikowanych detali, bywają łatwiejsze w ogarnięciu przy formalnej
weryfikacji/certyfikacji niż Unix-like.
PS. Amiga była preemptive i nie miała protekcji pamięci. A to nie był
system embedded tylko bardzo duzy i skomplikowany OS, choć w czasach
przedinternetowych.
Jeśli ma być "bezpieczny". Ale nie musi.
Wielozadaniowy to w zasadzie musi :-)
Mało który *mały* system embedded jest w ogóle preemptive. Za to pełno
cooperative/event.
Ogólnie to nie tak, że poważne rzeczy da się robić tylko na poważnych
systemach z grep i apt-get. Małe kontrolery, nie obciązone masą
skomplikowanych detali, bywają łatwiejsze w ogarnięciu przy formalnej
weryfikacji/certyfikacji niż Unix-like.
PS. Amiga była preemptive i nie miała protekcji pamięci. A to nie był
system embedded tylko bardzo duzy i skomplikowany OS, choć w czasach
przedinternetowych.
Preemptive byl tez wczesny Windows :-)
Quote:
Nie naciskałbym, że "musi mieć protekcję".
Jak masz komputer ogolnego przeznaczenia, na ktorym maja dzialac rozne
programy z roznych zrodel, a nawet i produkcja wlasna uzytkownikow,
to musi
A teraz jeszcze wirusy, internet, szpiegowanie :-)
Quote:
Protekcja/separacja procesów jest raczej zagadnieniem bezpieczeństwa a
nie funkcjonalności, ale jeśli jesteś juz w zakresie, gdzie uzywa się
fork, to w zasadzie to już nie jest embedded tylko normalny unix...
nie funkcjonalności, ale jeśli jesteś juz w zakresie, gdzie uzywa się
fork, to w zasadzie to już nie jest embedded tylko normalny unix...
Mowa o li/unixie.
J.
heby
Guest
Guest
Mon Jun 06, 2022 10:52 am
On 06/06/2022 12:17, J.F wrote:
Quote:
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?).
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.
Quote:
Teraz widze, ze linux ma cos kolo 2MB ... ale co zrobic, jak
zabraknie?
zabraknie?
Napisać lepszy kod. Przkroczenie 2MB/8MB na stosie jest oznaką bardzo
źle napisanego kodu.
Quote:
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?
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.
Quote:
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.
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?
Quote:
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
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ć.
Quote:
x86 zrobił to
tylko "lepiej" czyli skrajnie skomplikował proste zagadnienie adresacji
Mial byc nastepcą 8080
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.
Quote:
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.
Quote:
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.
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.
heby
Guest
Guest
Mon Jun 06, 2022 10:55 am
On 06/06/2022 12:22, J.F wrote:
Quote:
Masa OSów nie ma forka Zerknij choćby na eCos.
Ale w Unixie to podstawa
Zerknij choćby na eCos.
Ale w Unixie to podstawa
Można ją zrealizować bez MMU, tylko mało wydajnie.
Quote:
PS. Amiga była preemptive i nie miała protekcji pamięci. A to nie był
system embedded tylko bardzo duzy i skomplikowany OS, choć w czasach
przedinternetowych.
Preemptive byl tez wczesny Windows
system embedded tylko bardzo duzy i skomplikowany OS, choć w czasach
przedinternetowych.
Preemptive byl tez wczesny Windows
Win do 3.11 był cooperative. Pierwszy domowy Win z preemptive to 95.
Dokładnie 10 lat po Amidzie i Sinclair Ql.
Quote:
Nie naciskałbym, że "musi mieć protekcję".
Jak masz komputer ogolnego przeznaczenia, na ktorym maja dzialac rozne
programy z roznych zrodel, a nawet i produkcja wlasna uzytkownikow,
to musi
Jak masz komputer ogolnego przeznaczenia, na ktorym maja dzialac rozne
programy z roznych zrodel, a nawet i produkcja wlasna uzytkownikow,
to musi
Nie. To kwestia bezpieczeństwa. Nie mueisz go mieć aby dalej mieć
użyteczny system.
Quote:
A teraz jeszcze wirusy, internet, szpiegowanie
*TERAZ* tak. Wtedy nie.
Quote:
Protekcja/separacja procesów jest raczej zagadnieniem bezpieczeństwa a
nie funkcjonalności, ale jeśli jesteś juz w zakresie, gdzie uzywa się
fork, to w zasadzie to już nie jest embedded tylko normalny unix...
Mowa o li/unixie.
nie funkcjonalności, ale jeśli jesteś juz w zakresie, gdzie uzywa się
fork, to w zasadzie to już nie jest embedded tylko normalny unix...
Mowa o li/unixie.
uCLinux to nie Linux
? Wystarczy że zgodny z POSIX. To czy masz w nim
paging czy nie, w sumie nie musi być wiadome dla aplikacji. Nie ma to
znaczenia.
J.F
Guest
Guest
Mon Jun 06, 2022 11:08 am
On Mon, 6 Jun 2022 12:55:31 +0200, heby wrote:
Quote:
On 06/06/2022 12:22, J.F wrote:
Masa OSów nie ma forka Zerknij choćby na eCos.
Ale w Unixie to podstawa :-)
Można ją zrealizować bez MMU, tylko mało wydajnie.
Masa OSów nie ma forka
Zerknij choćby na eCos.
Ale w Unixie to podstawa :-)
Można ją zrealizować bez MMU, tylko mało wydajnie.
Nie bardzo czuje jak.
Jest program, ma kod, ma dane, ma gdzies zapamietane adresy tych
danych, i nagle to trzeba zduplikowac.
Kod moglby zostac ten sam, ale co z adresami w pamieci?
Quote:
PS. Amiga była preemptive i nie miała protekcji pamięci. A to nie był
system embedded tylko bardzo duzy i skomplikowany OS, choć w czasach
przedinternetowych.
Preemptive byl tez wczesny Windows :-)
Win do 3.11 był cooperative. Pierwszy domowy Win z preemptive to 95.
Dokładnie 10 lat po Amidzie i Sinclair Ql.
system embedded tylko bardzo duzy i skomplikowany OS, choć w czasach
przedinternetowych.
Preemptive byl tez wczesny Windows :-)
Win do 3.11 był cooperative. Pierwszy domowy Win z preemptive to 95.
Dokładnie 10 lat po Amidzie i Sinclair Ql.
A, ok, pomylilo mi sie.
Ale preemptive byly tez chyba widowsy 3.x, o ile uruchamiane na 386.
Quote:
Nie naciskałbym, że "musi mieć protekcję".
Jak masz komputer ogolnego przeznaczenia, na ktorym maja dzialac rozne
programy z roznych zrodel, a nawet i produkcja wlasna uzytkownikow,
to musi
Nie. To kwestia bezpieczeństwa. Nie mueisz go mieć aby dalej mieć
użyteczny system.
Jak masz komputer ogolnego przeznaczenia, na ktorym maja dzialac rozne
programy z roznych zrodel, a nawet i produkcja wlasna uzytkownikow,
to musi
Nie. To kwestia bezpieczeństwa. Nie mueisz go mieć aby dalej mieć
użyteczny system.
A co to za uzyteczny system, ktory nie wiadomo kiedy wyleci, z winy
jednego programu :-)
Quote:
A teraz jeszcze wirusy, internet, szpiegowanie
*TERAZ* tak. Wtedy nie.
*TERAZ* tak. Wtedy nie.
Wirusy sa stare :-)
Quote:
Protekcja/separacja procesów jest raczej zagadnieniem bezpieczeństwa a
nie funkcjonalności, ale jeśli jesteś juz w zakresie, gdzie uzywa się
fork, to w zasadzie to już nie jest embedded tylko normalny unix...
Mowa o li/unixie.
uCLinux to nie Linux? Wystarczy że zgodny z POSIX. To czy masz w nim
paging czy nie, w sumie nie musi być wiadome dla aplikacji. Nie ma to
znaczenia.
nie funkcjonalności, ale jeśli jesteś juz w zakresie, gdzie uzywa się
fork, to w zasadzie to już nie jest embedded tylko normalny unix...
Mowa o li/unixie.
uCLinux to nie Linux
? Wystarczy że zgodny z POSIX. To czy masz w nim
paging czy nie, w sumie nie musi być wiadome dla aplikacji. Nie ma to
znaczenia.
J.
J.F
Guest
Guest
Mon Jun 06, 2022 11:39 am
On Mon, 6 Jun 2022 12:52:07 +0200, heby wrote:
Quote:
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?
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 :-)
Quote:
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.
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.
Quote:
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.
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.
Quote:
Co im się udało w prześmieszny sposób (A20).
Reszta to paniczne szukanie jak to jeszcze bardziej popsuć.
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.
Quote:
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.
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 :-)
Quote:
No ale widzisz - to -64. Znow hardware przegonil potrzeby i mozliwosci
MC68000 nie potrzebuje segmentacji. Pojawił się na rynku chwile po 8086.
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 :-)
Quote:
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.
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.
Quote:
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.
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_segmentation#Protected_mode
https://en.wikipedia.org/wiki/Protected_mode#286
J.
heby
Guest
Guest
Mon Jun 06, 2022 3:04 pm
On 06/06/2022 13:08, J.F wrote:
Quote:
Można ją zrealizować bez MMU, tylko mało wydajnie.
Nie bardzo czuje jak.
Jest program, ma kod, ma dane, ma gdzies zapamietane adresy tych
danych, i nagle to trzeba zduplikowac.
Kod moglby zostac ten sam, ale co z adresami w pamieci?
Nie bardzo czuje jak.
Jest program, ma kod, ma dane, ma gdzies zapamietane adresy tych
danych, i nagle to trzeba zduplikowac.
Kod moglby zostac ten sam, ale co z adresami w pamieci?
Dwie rzeczy:
1) tak, for jest trudny w systemach bez pamięci wirtualnej i wymaga masy
roboty (i w wielu sytuacjach może sie nie powieść). Na pewno jest to
skrajnie kosztowne i bez sensu.
ale
2) for prawie nigdy nie jest uzywany w małych systemach w taki sposób
jak "watki". Na 99% fork zakończy się execv, co oznacza, że cała ta
ciężka robota z potencjalnym forkowaniem zazwyczaj to tylko wymówka aby
odpalic inny proces. O, to już można mieć protezę forka. Gdzieś taką
implementację widziałem nawet, nie wiem czy nie w jednym z tych małych
Linuxów bez mmu - robiło "forka" i czekało na execv i to wystarczyło aby
ogarnąć 99% programów Linuxowych.
Quote:
Win do 3.11 był cooperative. Pierwszy domowy Win z preemptive to 95.
Dokładnie 10 lat po Amidzie i Sinclair Ql.
A, ok, pomylilo mi sie.
Ale preemptive byly tez chyba widowsy 3.x, o ile uruchamiane na 386.
Dokładnie 10 lat po Amidzie i Sinclair Ql.
A, ok, pomylilo mi sie.
Ale preemptive byly tez chyba widowsy 3.x, o ile uruchamiane na 386.
Win3.11 jest cooperative, co nie było niczym specjalnie dziwnym, jabłka
też były, jakoś przeoczyli rewolucje siedząc dalej w nakładce na DOSa.
Być może były jakies protezy pod spodem, któe pozwalały odpalać kilka
Win na raz (gdzieś to widziałem) i byc może były preemptive, ale nie
natywnie w Win.
Quote:
Nie. To kwestia bezpieczeństwa. Nie mueisz go mieć aby dalej mieć
użyteczny system.
A co to za uzyteczny system, ktory nie wiadomo kiedy wyleci, z winy
jednego programu
użyteczny system.
A co to za uzyteczny system, ktory nie wiadomo kiedy wyleci, z winy
jednego programu
To nie ma znaczenia. To czy Ci wyleci sterowanik silnika respiratora w
procesorze z MMU czy bez MMU jest mało istotne bo w obu wypadkach jesteś
w d... To tylko może nieco zmniejszych poziom katastrofy, ale nie
zapobiega jej. Zaryzykuje, że ważniejsza jest jakośc kodu niż to, czy
jest chroniony w systemie *zamkniętym*.
Tak naprawdę ochrona ma sens dopiero w czasach malware. Wczesniej była
fajnym ficzerem, ale niekoniecznie krytycznym, a przez dziesięciolecia
olewanym na wszelkie sposoby przez twórców OSów.
Quote:
A teraz jeszcze wirusy, internet, szpiegowanie
*TERAZ* tak. Wtedy nie.
Wirusy sa stare
*TERAZ* tak. Wtedy nie.
Wirusy sa stare
Wirusy które robią coś uzytecznego, online, są w miarę nowe.
A w dawnych czasach, posiadanie "protected MMU win95" oznaczało tylko,
że trzeba było zawołać ze 3 wywołania WinAPI więcej, żeby uzyskac
admina. To żałosny system był, protekcja pamieci to pic na wodę w
tamtych czasach. W zasadzie jako taką uwagę przyłożono dopiero w lini
NT, a linia 9x była robiona na odpiernicz się.
Dalej, są miejsca (embedded) gdzie protekcja/stronicowanie pamieci nie
ma wielkiego znaczenia i gdzie można stosować systemy które wyglądają
jak Unix, jesli ktoś potrzebuje. Wymaga to poświęcenia kilku detali, ale
one nie są krytyczne.
Atlantis
Guest
Guest
Fri Jun 17, 2022 9:23 am
On 31.05.2022 21:12, Cezar wrote:
Quote:
Uświadomiłem sobie, że gdybym jednak miał się bawić z uCLinux, to jest
jeszcze jedna opcja sprzętowa, stojąca gdzieś na pograniczu retro i
współczesności. Procesory DragonBall, stosowane m.in. w Palmach (zanim
ten producent przeszedł na ARMy od TI i Intela). Z jednej strony
klasyczny rdzeń 68k, z drugiej obudowa TQFP oraz trochę zintegrowanych
peryferiów.
elektroda NewsGroups Forum Index - Elektronika Polska - Jakie materiały edukacyjne polecacie do projektowania płytek PCB pod układy SoC?