On 01/03/2019 05:08, J.F. wrote:
>> Nie była liniowa. Była podzielona na okna po 64kB przemieszczane
>> rejestrami segmentowymi. Niewielikie usprawnienie względem Atari czy
>> Commodore które miały to zrobione w hardware. Atari obsługiwało 1MB po
>> kilku przeróbkach i kod wyglądał tylko troche bardziej strasznie niż x86.
> Bez przesady ... 1MB na 8 bit procesorze i stronnicowany 8 czy 4K ...
> to musialo byc straszne :-)

No było straszne na 8086. 8-bit procesor wsadzony w udawane 16 bitów z
adresacją prawie z Atari :D

Ultimate 1MB w Atari jest używane głównie przez demoscene, ale takie np.
Atari 130XE miało własnie przepinany dodatkowy RAM i było to niejako
wbudowane w hardware. Taka segmentacja, prawie jak w 8086 :D

>> A kto im probił zrobić rejestry adresowe 20 bitowe? Reglamentacje mieli
>> w korpo? Jakoś 68k nie miał problemu z byciem 16 bitowym hardwareowo,
>> ale model programistyczny miał 32 bity.
> te 16 bit to chyba tylko szyna zewnetrzna i multiplikator.
> Reszta byla 32-bit.

Model programistyczny był 32 i to się liczyło. Jak już zaczynać jakąś
architekturę to wydaje się że idiotyzmem jest to robić od 8 bitów a tu
się okazuje że Intel dał radę ...

> 20-bitowe rejestry bylyby raczej trudne w obsludze.

12 bitów na górze mogło by być fake. Nie widzę problemu.

>>> Najdurniejszym pomysłem było to, że strony były zrobione po 16B, zamiast po
prostu po 64kB.
>> Nic by to nie dało. Segmentacja bez względu na szerokość to idiotyzm w
>> czystej postaci.
> No, tak w ogolnosci ma pare zalet.
> Np. pozwala zmniejszyc fragmentacje przestrzenii adresowej.
> Wyobraz sobie, ze uzywasz w programie kilku duzych tablic,
> o zmiennym rozmiarze. Czyz nie byloby wygodnie, gdyby kazda z nich
> byla w osobnym segmencie, adresowanym od zera ?

Nie ponieważ powoduje to powstawanie dziur na końcach obszarów i nic nie
daje bo procesory od wieków potrafią indeksować od dowolnego adresu. No,
oczywiście poza 8086 który niewiele potrafi w temacie liniowego dostępu.

Innymi słowy segmentacja nie ma żadnej zalety. Ma za to absurdalny
overheat w kodzie i absurdalny wpływ na języki programowania takie jak
farptr i inne debilizmy wypływające w kodzie źrodłowym.

> Czy np problem C i innych podobnych jezykowi i unixow/innych systemow.
> Program ma swoj kod.
> I wymaga pamieci danych, stosu na adresy powrotow i zmienne funkcji,
> oraz sterty pamieci do alokacji.
> Gdzie je ustawic, jesli wstepnie nie wiadomo ile tego stosu i sterty
> trzeba ?

Segmentacja tego problemu nie rozwiąże, to jest fragmentacja typowa dla
nawet współczesnych procesorów tylko mniej bolesna z powodu warstwy
abstrakcji na pamięć. Jak mówie każdy procesor potrafi adresować
względnie, względem byleczego i liniowo. Poza 8086. 8086 jak zwykle
dzielnie rozwiązywał problemy niespotykane nigdzie indziej.

> A do tego program uzywa kilku bibliotek, ktorych pewnie beda uzywac
> tez inne programy/procesy.
> Gdzie je zaladowac do pamieci, jesli procesor nie pozwala na kod w
> pelni relokowalny ?

A czemu nie pozwala? Przypomne że 8086 to taki g... że aby napisać
program z fetchem względnym trzeba robić wygibasy rodem z hackingu aby
odczytać PC. Znowu walczymy z debilizmami architektury która
najzwyczajniej była jedną z najgorszych w historii informatyki. I
segmenty tego nie rozwiązują.