On 03/03/2019 22:34, J.F. wrote:
> A jak mamy 1MB RAM, to znow znacznie latwiej sie to obrabia na 8086 w
> malych kawalkach, niz na 6502 z dodatkowym stronnicowaniem.

I tu i tu musisz przestawiać segmenty. W przypadku 8086 masz tylko tą
zaletę że robisz to w cpu.

> O co innego chodzi. Masz np obrazek 24b/pixel.
> Obliczasz adres trzech bajtow pixela w pamieci seg:offset,
> i masz w trzech kolejnych bajtach dane. I nie zastanawiasz sie czy
> przypadkiem drugi lub trzeci bajt nie leza na innej stronie, i trzeba
> ja zmienic.

Zależy jaki duży masz ten obrazek. A jak nie wiesz jaki masz duży to i
tak musisz sprawdzać za każdym razem. Znowu dupa z tyłu.

> Albo np szukasz slowa w tekscie, i sie nie zastanawiasz czy
> przypadkiem "owo" nie jest na nastepnej stronie.

Bo teksty z definicji nie przekraczają 64kB ...

> Oczywiscie, przy rozsadnym zalozeniu ze normalizujesz wskaznik np co
> linie, a linia nie ma ponad 64KB.

Oczywiście przy założeniu że nie będzie padać a i wiać też nie będzie to
jakoś ta prowizorka wytrzyma ...

>> Kompaktacja pamięci pojawił się dopiero w językach w których nie ma
>> pointerów (z popularnych Java C# i inne). Wiedza o tym że ktoś
>> przemieszcza mi pointery w programie musi istnieć, program musi być na
>> to gotowy.
> Ale jak wychodzimy z CP/M i zaczynamy robic wielozadaniowy system
> operacyjny, to problem wraca.

Jesli procesor ma MMU to nie wraca. Każdy proces ma własną przestrzeń
wirtualną i nic nie wie o innych allokacjach.

Jak nie ma MMU to problem co najwyżej nie jest procesu tylko procesów.
Tak jak w Amidze.

> Zadania przychodza, koncza sie ...

I pamięc się fragmentuje. Podobnie w ramach procesu allokacje
przychodza, odchodzą a pamiec w kawałkach. Sorry, taki mamy podstawowy
model programowania do dzisiaj.

>> A jak? Żeby program nie wiedział i żebyś nie pomylił segmentacji z
>> translacją wirtualna->fizyczna MMU.
> Bo program ma uzywac dla tej pamieci segmentu nr 3 np.

Para segment:offest to jest dokłądnie to samo co pointer. dokładnością
do kłopotów w relacjach. Nie ma tam nic "leszego" albo rozwiązującego
problemy lepiej niż liniowy adres. Nic. Dorabianie filozofii do tego
konceptu jest naprawdę bolesne dla logiki.

>> Bo to problem segmentacji pamięci i jest obecy w każdej współczesnej
>> sytuacji kiedy nie ma kompaktacji pamięci. Segmenty nic nie zmieniają
>> ani nie ułatwiają.
>>> Z segmentami (ale nie takimi jak w 86) by sie dalo.

Nie dało. Program musi wiedzieć że mu pamięc kompaktujesz i wskaźnik
jest iwalidowany. To się da zrobić i robią to niektóre maszyny wirtualne
specjalizowane do poganiania Javi i C# w embedded. Ale tam jezyki nie
mają pointerów.

> No wlasnie uzyc segmentow ... tylko w stylu 2/386.
> Prosisz o duzo, to dostajesz dodatkowy nr segmentu,
> a procesor ma gdzies tam zapisane gdzie sie segment zaczyna.

Mylisz segmentacje z wirtualizacją pamięci.

> Nawiasem mowiac - chcieli lepiej
> https://en.wikipedia.org/wiki/Intel_iAPX_432

Nie było zgodne z CP/M i w dodatku potem okazało się że było na tyle
kiepsko zaprojektowane że nie było też wydajne.

>> żąłosną architekturą było nawet to 386 z kilkoma specjalizowanymi
>> rejestrami, praktycznie zerową ortogonalnością itd itp.
> Ta ortogonalnosc nie jest tak znow niezbedna.

Powiedz to kompilatorom. Obecnie tworzy się kod na procesor wirtualny z
masą rejestrów a nastepnie kolejna warstwa stara się to translować na
żałosną przestrzeń rejestrów x86. No, ale Turing-complete, więc o co chodzi.

>> Nie musi tego wiedzieć, skoro podałeś adres to pod nim spodziewadz się
>> danych. Mówisz o offsecie. Ale nawet wtedy nie o to chodzi. Kod
>> relokowalny ma TAKIE SAME pointery jak nierelokowalny. Róznica jest
>> tylko w tym że KOD może być dowolnie umieszczony w RAM.
> A tu jest kod i dane.
> Np procedura rysowania znakow na ekranie, i dane z fontami.
> Font moze byc dowolny, ale jest kilka predefiniowanych w bibliotece.

Ich dane są gdzieś załadowane fizycznie w pamięć. Kod obsługujący albo
ma na stałe offset i w gotowości relokator jak by trzeba było przenosić
albo jest całkowicie relokowalny.

kod x86 ma na tyle duży narzut na całkowitą relokowalność że szbciej
jest kod przerelokować automatycznie niż dodawać masę instrukcji
wydłubujących z żywego kodu PC.

> I całosc dynamicznie linkowana i nie wiadomo pod jakim adresem sie
> znajdzie po załadowaniu.

I dlatego Windows 32 bit zazwyczaj DLLki relokuje po każdym załadowaniu.
Na Win 64 dllki mogą być już za darmo pisane względnie.