Dnia Thu, 28 Feb 2019 21:05:17 +0100, Sebastian Biały napisał(a):
> On 28/02/2019 14:56, d...@w...pl wrote:
>> Przesadzasz z tymi 64kB liniowej przestrzeni.
>> Było jej w 8086/88 1024kB
>
> 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 :-)

>> A że nie można było sobie adresować jednym rejestrem, tylko parą - no cóż w tym
dziwnego, skoro rejestry były 16-bitowe?
>
> 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.

20-bitowe rejestry bylyby raczej trudne w obsludze.

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

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 ?

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 ?

J.